An agent’s wrong value was merged. Correct it without erasing the history

An agent that organizes business information and updates shared records saves other people from reopening every source document. But a value can still turn out to be wrong after review and merge: a source was misread, a detail escaped review, or stronger evidence became available later.

Simply replacing the value makes the immediate correction, but can leave the next person unsure why it changed. Restoring the whole record to an older version may overwrite valid updates made afterward. And if the wrong value already reached a report or export, fixing one field may leave those copies unresolved.

Busabase keeps the current record and its history, while ChangeRequests preserve changes and their review process. A correction can follow that trail: locate the change that introduced the error, propose a focused fix supported by reliable evidence, then check the formal record and known downstream uses. The result gives the team both a corrected value and a basis for trusting it next time.

Contain the mistake before repairing it

Identify who and what still uses the incorrect value. Pause the affected automated step where you have authority and ask the record owner to suspend decisions that depend on it. Keep the scope specific: a faulty field does not make the entire knowledge base unusable.

Save the record link, current version, affected field, and evidence that raised the concern. Do not immediately restore a familiar old value. Legitimate changes may have happened since the faulty edit. The goal is an accurate current record with an explanation someone else can inspect.

Locate the change that introduced the problem

Busabase records expose current content and history. A ChangeRequest carries changes and review state; merging advances the record’s commit pointer while preserving commits. Treat a correction as a new auditable change.

Open the record’s detail and history, locate the relevant change, and inspect its before-and-after values, attribution, and review. Compare them with authoritative business evidence, such as a contract, system receipt, or confirmation from the data owner. An agent admitting a mistake is a lead, not sufficient evidence for the replacement value. Use the source-and-attachment evidence pattern when the supporting material needs its own traceable location.

Propose a bounded correction

Reuse the business Base. When a case needs coordination, add a suggested Corrections Base with a readable title, relation to affected records, field, current and proposed values, evidence location, original and corrective ChangeRequest links, owner, state, and downstream verification. Adapt this starter design to the actual schema.

An agent instruction can be: “Read the latest version and the specified evidence. Identify only the fields needing correction, preserve other confirmed fields, and explain the relationship to the original change. Show the diff before proposing under your permitted access. Do not delete history or undo unrelated updates.”

For a REST integration, obtain the applicable version from a fresh read before submitting a field patch. If the record changed, read again and reconcile it. Concurrent updates address stale proposals before merge; factual correction addresses what happens after a wrong value became current.

Make the review about specific facts

The reviewer needs the affected field, proposed replacement, reason, supporting evidence, and fields that must remain unchanged. Explain the business reason in the change message and link the original change and correction case. “Restore normal” is not an adequate explanation.

API key permissions affect whether a proposal waits. A changeRequest-level key can read and propose but cannot merge its proposals. Write-level access can merge immediately. When a person must review, enforce that requirement through the credential and explicit review settings rather than a conversational promise alone.

Verify the record and its known consumers

After merge, read the canonical record again. Check corrected values and preserved fields, then confirm that the current record, original change, and correction remain traceable. Save the result in the correction case and obtain the owner’s acceptance.

The old value may already appear in reports, exports, or another agent’s context. List known consumers, artifacts to regenerate, owners, and verification outcomes. Existing integrations, scripts, or human notifications must perform those external steps. Saving a correction does not automatically refresh every consumer.

This distinguishes correction from rollback. An earlier version explains history; restoring the whole record can undo later valid work. A new patch against current state makes the scope explicit. Inspectable history does not establish a one-click rollback across every downstream system.

Close with evidence another person can use

The owner should be able to identify the correct value, its evidence, the history, and the status of known downstream repairs. Keep unknown consumers as an explicit remaining risk. Complete one real correction through proposal, merge, and readback before putting the repeatable checks in a Doc or Skill. The next agent can then use both accurate current data and guidance retained from the incident.