When Two AI Agents Update the Same Record

At 8:05 on a Tuesday, the intake agent at Maple & Pine Promos, a decorator, changes the requested date on order SO-1042 from the 14th to the 21st, because the customer emailed. Two seconds later, the shipping agent writes a tracking reference to the same order. It had read the record a moment earlier, so it saved the old date right back on top of the new one.

Meanwhile Greg from customer service, who has had one coffee and a lot of confidence, edits the shipping address by hand. By 8:10 the order shows a tracking number for a shipment that has been postponed a week, headed to an address that is Greg's best guess. The customer receives an "on its way" email for a package that does not exist yet. "Three of us worked really hard on this order," Greg says, "and somehow it got worse."

Everyone in this story followed their instructions. Nobody had written down who is allowed to change what, and nothing told a late writer that the record had moved underneath it.

When two agents can update the same record, give each field an owner, use narrow writes, and require a supported version check before applying a change based on earlier state. If the system cannot coordinate competing writers, evaluate a per record queue or retain a reviewed handoff.

This is a recommended design for lost updates and duplicate effects. It has to include employees and other integrations that can edit the same records, because coordination inside one agent platform only covers the writers that participate in it.

Start with field ownership

List every workflow that can change the record and the fields it owns. For example, an approved order intake workflow might create draft line items, a fulfillment integration might populate shipment references, and a finance process might own payment status.

Keep that map explicit. Avoid broad instructions such as "keep the order up to date" when several processes interpret them differently. Define who may change shared fields, which source wins when values disagree, and when a person must decide.

Prefer narrow updates that change only the intended fields where the API supports them. This reduces accidental overwrites, although it does not solve conflicts when two workers legitimately need the same field. Also review business dependencies, because changing an address and approving a shipment may affect each other even when they write different fields.

Check whether the record has changed

Some systems support a record version, an entity tag, or another conditional write mechanism. The worker reads a version and submits its update only if that version still matches. If another writer changed the record in the meantime, the system rejects the stale update so the workflow can reassess.

HTTP defines conditional requests for this purpose. RFC 9110 describes the If-Match header as a way to help prevent lost updates when multiple clients change a resource. The connected API must actually support and enforce the mechanism, and adding an unsupported header is not a concurrency control. See RFC 9110 on If-Match.

After a conflict, reread the record and compare the intended change with the new state. Automatically retry only when the change is still valid under the business rules. A stale approval, price, or shipment instruction may need review instead.

Illustrative collision and recovery sequence

Assume a hypothetical order API that supports and enforces conditional updates using a record version. The version labels below describe the example and do not match any particular ERP's payload format.

1. Both agents read order SO-DEMO at version 7. The shipping agent intends to add a tracking reference, and the order agent intends to change the requested date.
2. The shipping agent writes its permitted field against version 7. The stored record becomes version 8.
3. The order agent submits its narrow date change against version 7. In this test, the service rejects the stale condition, and the workflow keeps the proposed date as unresolved instead of overwriting the record.
4. It rereads version 8 and checks whether the date change is still authorized. If shipment has already begun, a business rule may require a person's decision even though the two agents edited different fields.
5. After any required review, it applies the permitted change against the current version and verifies that the tracking reference is still intact.

The pass condition is preserved valid work plus a visible decision on the conflict. Retrying until a request succeeds would miss the business risk entirely.

Use one writer when coordination is difficult

A queue can collect proposed changes and let one worker apply them in order for a particular record. This is often easier to reason about than letting every agent write directly, and different records can still progress independently if the design supports it.

The queue needs durable records, acknowledgement, retry handling, and a recovery owner. Document what happens when a worker stops after writing but before marking the queue item complete. Without that detail, a single writer design can still repeat actions.

Locks may be useful where the underlying system supports them, but define their scope and failure behavior. A lock in one automation platform does not automatically stop an employee or a second integration from editing the ERP. Expiring locks also need protection against an old worker resuming after a new one has taken over, so ask the implementer to demonstrate those cases instead of treating the word "lock" as sufficient assurance.

Store progress outside the conversation

Conversation history can help an agent understand a job, but it is a poor substitute for a durable record of what the workflow has committed. Keep the job identifier, source record, target record, last confirmed step, relevant version, and unresolved action in a shared state store appropriate to the application.

Define useful states such as received, validated, awaiting approval, submitted, confirmed, and needing repair. A transition should mean something observable: "submitted" means a request was sent, and "confirmed" means the expected result was verified.

Preserve the identifiers returned by external systems. If an order already exists, the next step should use that order's identifier, and it should not depend on an agent remembering a prior tool result after a restarted run.

Prevent duplicated effects during retries

A retry can be technically valid and operationally wrong. Sending a customer another reminder, creating another PO, or appending another charge can all happen when the previous outcome is uncertain.

Use the application's supported idempotency mechanism where available. Otherwise, design a stable business key and a reconciliation check suitable for the operation. Do not assume every create action accepts an idempotency key, or that searching by customer name will reliably identify a prior transaction.

Separate replayable preparation from consequential actions. Rebuilding a proposed update may be harmless, while applying it requires a fresh check of current state and authorization.

Test collisions deliberately

Before expanding to several workflows, run controlled tests in which:

• Two workers read the same version and propose conflicting changes.
• An employee edits the record before an agent saves.
• A write succeeds but its response is lost.
• A queued worker crashes before acknowledging completion.
• A stale worker resumes after ownership has changed.
• A conflict needs a human decision instead of another retry.

Inspect both the final record and the history. Confirm that valid changes survive, duplicates are detected, and unresolved work has an owner.

Checklist for shared records

Run through this list for each record type that more than one writer can touch:

• Every workflow, integration, and employee role that can write the record is listed.
• Each field has one named owner, and shared fields have a stated winner and a person who decides ties.
• Writes change only the intended fields where the API allows it.
• The API's conditional write behavior has been tested, not assumed.
• A rejected stale write is reread and reassessed, not blindly retried.
• Progress, record identifiers, and the version read are stored outside the conversation.
• Retries use a supported idempotency key or a stable business key with a lookup first.
• Every collision test above has been run, with the final record and history inspected.
• Every unresolved conflict has an owner who is notified.

Limits of coordination controls

A local queue does not block an employee editing outside it. A version check detects certain stale writes but does not decide which business change is correct. A deduplication check also needs a reliable key and a concurrency safe implementation, because two workers can otherwise both conclude that no record exists.

FAQ

1What is a lost update when two AI agents edit one record?

A lost update happens when two workers read the same version of a record, each makes a change, and the second save overwrites the first without noticing it. Both writes can return a success code, so the damage often shows up later as a wrong date, address, or status. An enforced version check can reject a stale write. A single writer can serialize participating writers, but other writers still need controls.

2Does a version check pick the right change?

No. A version check only detects that the record changed since the worker read it, and it rejects the stale write. After the rejection, the workflow still has to reread the record and apply business rules, or ask a person, to decide whether the change is still valid.

3When should I use a queue instead of direct writes?

Consider a per record queue when the connected system cannot enforce conditional writes, or when many workers need the same record. One worker applies queued changes in order, which is easier to reason about. The queue still needs durable storage, acknowledgement, retry handling, and an owner for recovery.

4Why not just retry until the write succeeds?

A blind retry can apply a stale change, repeat an action such as a customer email, or create a second PO after a lost response. Retry only after rereading current state and checking the change is still authorized, and use an idempotency key or a stable business key with a lookup where possible.

5Do these controls cover employees editing the same record?

Only if every relevant writer is subject to the control. A queue or lock inside one automation platform does not stop an employee, or another integration, from editing the ERP directly. Include people and every other writer in the field ownership map and in your collision tests.