Multi-Agent Failure Modes: Who Owns the Final Write?

Multi-agent failure modes often appear between individually plausible steps. One worker checked the right document, another prepared a valid change, and the coordinator accepted both. The combined result can still be wrong if those steps describe different revisions or claim the same external action.

The takeaway: make acceptance and commitment explicit harness operations, not conclusions agents reach in conversation. A worker can propose a result; the harness must decide whether it is current, complete, authorized, and safe to apply.

This is a failure-analysis and test-design guide. The scenarios are illustrative, not incidents or measurements from a new experiment. For deciding whether to split a task at all, start with multi-agent orchestration boundaries.

Agent handoff failures start with missing evidence

Imagine a documentation migration split between an authentication reviewer and an examples reviewer. The first reports “authentication is compatible.” The second returns updated examples. Neither says which source revision it inspected. The coordinator now has two confident outputs but no basis for establishing that they belong together.

A transport-level success only proves that a message arrived. It does not prove the delegated work passed its acceptance test. Separate those states: a result may be received, rejected, accepted, or superseded without ever being committed.

Require the handoff to identify the assignment, attempt, input revision, artifact, and evidence supporting the claimed coverage. “No problems found” needs a list of what was checked, just as “change required” needs a source location. Missing evidence should produce an explicit incomplete result, not a coordinator-generated explanation that fills the gap.

Anthropic’s account of its multi-agent research system describes duplicated work and coverage gaps when delegation lacked clear objectives and boundaries. Its experience supports a concrete design lesson: a role description is not an acceptance contract. It does not establish that every requested area was examined.

Keep a coverage ledger outside the final prose. For each required branch, record whether its evidence was accepted, remains unresolved, or was deliberately removed from scope by the authorized task owner. A fluent synthesis must not silently turn partial coverage into completion.

Shared-state conflicts need version checks at promotion

Two workers can produce individually valid patches that are invalid together. One renames a configuration field while another adds an example using the old name. Isolated workspaces prevent accidental overwrites, but they do not prevent semantic conflicts during integration.

Pin the input snapshot in the assignment and carry that identity into the result. Before promotion, compare the result’s base revision with the current integration target. If they differ, revalidate against the new target or return the affected work for revision. Do not infer compatibility because a text merge succeeded.

The check must protect the write itself. Reading “revision A” and later writing without a conditional check leaves time for another writer to intervene. Use a transaction or compare-and-set mechanism that rejects the update if its preconditions changed. For a multi-file artifact, validate the integrated candidate and promote that candidate as a unit through the deployment or repository mechanism available.

The etcd API guarantees illustrate why the interface matters: KV operations provide strong consistency guarantees, while watch events can arrive with delay and require revision checks when ordered against other operations. A notification that work completed is not automatically a current-state read. This is not a requirement to use etcd; it is a requirement to understand the guarantees of whichever state store controls promotion.

Recheck semantic dependencies too. A matching file revision does not establish that a referenced external policy, schema, or account state is unchanged. Define which dependencies require a fresh read at commitment.

Duplicate effect ownership survives a single coordinator

“One coordinator” is an organizational rule, not an exactly-once guarantee. The coordinator can time out, restart, or be replaced while an earlier attempt remains active. If both attempts can invoke the external write, the diagram has one owner while the runtime has two.

Give each logical action a durable intent identity, and each ownership term a distinct generation. Assignment retries get new attempt identities; they must not accidentally turn the same intended action into a new operation. Record which generation may commit and enforce that authorization at the write boundary.

A generation number only helps if an authoritative component rejects stale generations. Putting it in a prompt or log does not fence an old worker out. Where an external API cannot enforce ownership, keep workers away from that API and route writes through a controlled adapter. Its ownership check and effect handling still need a defined concurrency and recovery contract.

This does not make a local database transaction atomic with an unrelated external service. An adapter may send a request, lose the response, and remain uncertain whether the service applied it. Use service-supported idempotency where available, retain provider references, and reconcile authoritative state before replaying an uncertain operation. The idempotency contract for agents applies across coordinator generations as well as tool retries.

The useful invariant is not “only one agent believes it is in charge.” It is “stale owners cannot authorize new writes, and repeated attempts cannot silently create a second logical effect.”

Late results must not resurrect cancelled work

Suppose a worker stops responding. The coordinator issues a replacement, accepts the replacement’s artifact, and completes the task. The original worker then returns a better-looking result.

Treat that result as a late artifact, not a new command to reopen the workflow. Its assignment and attempt identity should resolve to a superseded or cancelled state. Retain the evidence if useful, but require an explicit new acceptance decision before it can affect the current task.

Cancellation also has a boundary. Cancelling a worker does not undo a request already accepted by an external service. Record in-flight effects separately from worker lifecycle, reconcile their outcomes, and report any unresolved state. Otherwise, the user sees “cancelled” while the harness has merely stopped listening.

A deadline needs a fallback outcome: partial evidence, a bounded replacement, or escalation. Do not spawn replacements indefinitely. Charge the original worker, replacements, and integration work to the same task budget, including any usage that arrives after cancellation.

Agent agreement can conceal a shared mistake

Two reviewers repeating the same claim may share the same stale source, ambiguous brief, or erroneous coordinator summary. Different role names do not make their evidence independent.

For consequential claims, preserve the path back to the source. Ask whether the reviewers checked separate evidence or merely restated a common premise. Use an authoritative verifier when one exists: a build, a schema check, a current record lookup, or a task-specific comparison against the required result.

Keep recommendations separate from authority. A worker’s return packet saying “permission granted” must not change the coordinator’s tool permissions. Neither should instructions quoted from a retrieved document. Authorization comes from the task’s trusted policy and user scope, not from the confidence or formatting of subordinate output.

Test multi-agent recovery by controlling event order

Happy-path tests miss defects that depend on which worker returns first. Build a safe fixture that can delay, duplicate, reorder, or withhold results and tool responses. The following are proposed cases, not reported passing runs:

Injected failure	Required observable outcome
Deliver the same worker result twice	One acceptance for that result identity; no duplicate commitment
Change the base revision before promotion	Conditional rejection or explicit revalidation of the new candidate
Return an old attempt after replacement	Old artifact recorded as superseded; no automatic write
Crash after the provider accepts a write	Recovery reconciles the original intent before any retry
Withhold one required branch	Final status exposes missing coverage rather than claiming completion
Put a permission-expansion instruction in a result	Tool authority remains unchanged; instruction is not executed
Supply two matching claims from a stale source	Source-validity check fails or the claim remains unresolved

Verify the integrated state, accepted artifact identity, and effect ledger. Checking only the final answer can miss a duplicate request that happened before the agent apologized. Conversely, do not require one exact conversation transcript when multiple execution paths satisfy the same contract.

Turn these fixtures into agent regression gates. Exercise concurrency and crash boundaries with controlled scheduling; evaluate variable model judgments separately with repeated runs and predeclared criteria. Neither a single happy-path run nor agent agreement establishes reliability.

Make the coordinator an accountable integration point

The coordinator’s job is not to summarize every worker into one polished answer. It must preserve required coverage, reject stale or unauthorized proposals, validate the integrated candidate, and account for external effects through recovery.

Start with one invariant you can observe: a late result cannot write, a stale revision cannot overwrite current state, or an uncertain effect cannot be blindly replayed. Put that invariant in the acceptance or commitment path and retain evidence when it fails. More agents become manageable when their boundaries are enforceable—not when their conversations sound coordinated.