Two agents update one record. Why approval alone is not enough

Two agents read the same record and propose reasonable changes. An editor finds both acceptable in isolation. One proposal merges first; the other still depends on the older record.

The remaining question is which version the proposal was based on. Review assesses whether a change is acceptable. Version checking assesses whether it can still be applied as originally proposed. A shared business table needs both.

The read version belongs with the proposal

Busabase ChangeRequests preserve changes and immutable commit history. Merging advances the record pointer. While a proposal waits, another authorized writer can change the canonical record.

Save the version with the read. The current record-change endpoint accepts baseCommitId to identify the starting commit; verify the live API contract during integration. Keeping only a record ID loses part of the context used to generate the proposal.

A reviewer or client should be able to compare the original value, proposed change, and current value. Showing only the desired final value hides stale assumptions.

Separate field collisions from related changes

When both proposals modify the same field, decide which value is supported or whether new evidence requires a fresh proposal. Later submission and earlier approval do not establish correctness.

Different fields can still depend on the same decision. A summary and body, or a stage and next action, may be structurally separate but semantically connected. A clean field-level combination does not prove business consistency.

Submit only the required field delta. Sending the entire previously read record expands the scope and can carry old values into unrelated fields. A sparse patch reduces that risk without resolving semantic dependencies automatically.

Make the update chain recoverable

Reuse the business Base. Put field responsibility and conflict policy in a Doc, and preserve the agent’s repeatable update method in a Skill. Separate “official” copies for each agent create another reconciliation problem.

Read the current record and version, check evidence, propose the necessary fields, compare again when the baseline changes, then read back after merging. Configure API permissions for the desired review behavior. A writer with write may merge immediately; manual review is not implicit in every ChangeRequest.

The current request shape can be:

{
  "operation": "update",
  "baseCommitId": "<headCommitId just read>",
  "fields": {"<actual field slug>": "<proposed value>"},
  "autoMerge": false,
  "message": "Explain the change and supporting evidence"
}

Send it to /api/v1/records/{recordId}/change-requests, using actual values and the live schema. These placeholders describe an integration pattern, not a runnable test result. Inspect the returned state. Do not assume automatic semantic reconciliation or cross-system transactions.

Recover the original proposal after a timeout

A timeout means the caller lacks a definite response. The server may already have saved the change. Creating another proposal can produce duplicates.

Use the saved proposal identifier or stable business key to inspect the original ChangeRequest and canonical record. If merged, continue from readback. If pending, resume that proposal. Retry creation only after establishing that it did not succeed. Where an endpoint supports idempotency keys, preserve the original key across retries.

The client must retain run context and distinguish a sent request, an unknown result, and a confirmed merge. Busabase history provides objects to inspect; the integration still needs a recovery method.

Verify the fields that matter

After merging, read the canonical record. Check requested values and important fields outside the update scope. If a later change exists, distinguish the accepted commit from the current version rather than treating every subsequent change as a failed write.

An agent instruction can say:

Read the record and current version. Propose only necessary fields. If evidence or the baseline changes, show original, proposed, and current values for the responsible owner. Recover the original proposal after timeouts and read back after merge. Do not recreate records or report approval as a completed merge.

Can agents share one table?

Yes, with record or field responsibilities, version checks, minimal patches, and recovery information. Related business decisions benefit from a clear acceptance owner. These are workflow choices, not meanings the table infers automatically.

Does approval require another complete review?

An unchanged baseline normally calls for merging and readback. A changed baseline requires revisiting the affected reasoning and differences. Keep renewed review scoped to the actual dependency.

Authoritative writes need evidence and accountability. Parallel work also needs the starting point of each change. Establish those rules on one shared table before extending agent concurrency.