The second write has lost valid work because it treated its old snapshot as current. I would make the case store reject an update that claims to replace version 7 after version 8 has committed. HTTP If-Match with an entity tag is one standard way to prevent a lost update, as RFC 9110 describes. A conditional version write in a database serves the same purpose. The agent should see a conflict, not a success followed by a vague “latest note” that hides one finding.

But detecting the race is only step one. Do not blindly retry the fraud subagent's entire replacement against version 8. The billing finding might say a refund is eligible while the fraud finding says the refund must be held. Both can be true as observations, but the case decision needs an explicit rule. Store observations as separate entries with source, timestamp, authoring subagent, evidence and confidence or uncertainty where useful. Keep the current case decision in a controlled field. A coordinator or authorized reviewer can combine the findings, decide whether a hold overrides eligibility, and commit one new version with the reason. An LLM-generated merge of two paragraphs does not by itself resolve a business conflict.

If both agents add independent facts, append-only entries with stable operation IDs can avoid overwriting, while a materialized summary is regenerated from those entries. That design still needs validation. Duplicate retries must not create the same finding twice, and an agent must not append facts to the wrong customer or retain access after the case is closed. If the external case system offers only whole-document updates, use compare-and-swap, reread after conflict, make a new proposal against the latest version and require the domain checks again. Bound the retry loop so high contention becomes visible instead of burning tokens forever.

There is also a time boundary. A fraud hold could be lifted by a human between the two agents' reads and their final write. Version checks catch an intervening document change if all writers participate in the same versioned store. If the hold lives in a different system, recheck that authority before any refund action. The case note is evidence and coordination state, not permission to issue money. Record what each subagent proposed, what survived the merge and which actor made the final decision, without leaking one agent's private source to another unauthorized task.

What if the interviewer says the fields do not overlap? Then a structured field-level update might be safe, if the two fields really have independent invariants and the API protects each against stale writes. A refund status and a fraud status can look independent in storage while still jointly deciding payout. Several coding agents edit one repository. What can you safely merge? handles isolated code patches and integration on one repository commit. This is concurrent editing of a live business object, where syntactically mergeable changes can imply a contradictory action.