Guide

Multi-agent shared state: when two agents write one field

Published 23 September 2026

Two agents in the same system write to the same field, and one of them wins. Nothing errors, nothing logs, and the run finishes with a confident answer built on a value that was quietly replaced. This is a common coordination bug in multi-agent systems, and the fix is not more coordination, it is deciding up front how each field merges.

The two shapes the bug takes

The bug takes two shapes. The first is a silent overwrite, where whichever agent finishes second replaces the other's value with no error and no log. The second is a draft read as settled fact, where an agent treats a value that is still being iterated on as final.

The first shape is the silent overwrite. A research agent writes summary. A verification agent, working the same round, writes summary too. Whichever one finishes second is the version every agent downstream reads. There is no conflict, no exception, no diff to inspect. You find out when the final output cites a source the verifier had already thrown out.

The second shape is a draft read as settled fact. Agent B reads a field that agent A is still iterating on and treats it as final. This one is worse, because it is not a race and rerunning does not shake it loose. The value is legitimately there. It is just not finished, and nothing in the state says so.

Both come from the same root: the shared state has fields but no rules. A plain dictionary that any agent can write to already applies one merge strategy, last write wins, uniformly to every field.

Coordination overhead is real, so do not pay for it twice

Multi-agent systems already use many times the tokens of a chat interaction, so adding coordination to catch a silent overwrite pays the overhead twice. The cheaper fix is a merge rule per field, which costs nothing at runtime.

Anthropic's writeup of its multi-agent research system is direct about the cost: "In our data, agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats." Both multipliers are measured against chat interactions, not against a single agent, and Anthropic presents them as figures from its own data rather than an industry measurement. The same post adds: "There is a downside: in practice, these architectures burn through tokens fast."

It is also blunt about how brittle long agent runs are: "One step failing can cause agents to explore entirely different trajectories, leading to unpredictable outcomes." A silent overwrite is exactly that kind of step, minus the failure: nothing catches it, and every agent downstream reasons from the replaced value.

When a run comes back wrong, the reflex is to add coordination: another supervisor turn, a reconciliation agent, another round where everyone checks with everyone. That is a large token bill spent on the symptom. Anthropic's guidance in Building Effective AI Agents points the other way: "you should consider adding complexity only when it demonstrably improves outcomes". A merge rule per field costs nothing at runtime. An extra agent costs a lot.

Three merge strategies, and every field gets one

Every shared-state field gets one of three merge strategies: accumulator, overwrite, or role-attributed, and no field ships without one.

Field kind Merge rule Use when Typical fields
Accumulator append or add you want the whole history findings, errors, sources_checked
Overwrite last write wins you want current state, not history current_stage, active_agent, decision
Role-attributed append, each entry tagged with the agent that wrote it a reader must tell its own prior output from a peer's drafts, proposals, critiques

This is not a hypothetical this article invented. LangGraph, a widely used agent orchestration framework, forces the same decision on every field: its docs state plainly that each key "can have its own independent reducer function, which controls how updates from nodes are applied," and that "if no reducer function is explicitly specified then it is assumed that all updates to the key should override it." The framework even ships an explicit Overwrite type for when you want to reset state rather than merge it. Declaring a strategy per field is not extra ceremony, it is what a production framework already makes you decide, one way or another.

Accumulator fields grow over the run. Two agents writing at the same moment is not a conflict, because both entries survive. The trap is using an accumulator for something you meant to be current. An errors list that grows forever is correct. A status that grows forever is a pile nobody can read.

Overwrite fields are where last write wins is genuinely the right answer. current_stage should hold the current stage, and active_agent whoever is active now. Last write wins is not the bug. Undeclared last write wins is the bug, because it lands by default on the fields that needed history and nobody noticed.

Role-attributed fields are the fix for the second shape. Every entry carries the agent that produced it, so a downstream reader can separate its own prior output from a peer's draft. Strip the tag and an agent reading back its own earlier draft treats it as independent corroboration. It agrees with itself and gains confidence from nothing.

The operational rule is simple: no field ships without a strategy. If a field is obviously last write wins, write that down anyway. That is what converts an accident into a decision, and what makes a reviewer stop and ask whether two agents really both write there.

The second half of the bug: what a handoff actually transfers

A handoff is not a message. It is a write to shared state plus a read grant, and both halves go wrong in opposite directions.

Failure What the handoff passes What it costs
Over-transfer everything: the full transcript, every intermediate step, the whole state object money; it feels safe, but the token bill already weighs heavily on these architectures
Under-transfer the conclusion, with the constraint that produced it dropped correctness

Under-transfer in practice looks like this. A research agent told to exclude paywalled sources hands over a clean list of findings, the writing agent never learns the exclusion existed, and it cites one. Or an agent holds a recommendation pending approval, and the handoff carries the recommendation without the pending flag, so the next agent acts on it.

This is not hypothetical either. The OpenAI Agents SDK's own handoff docs describe the out of the box behaviour plainly: when a handoff happens, the receiving agent "gets to see the entire previous conversation history." Everything, unfiltered, by default. The SDK ships an input_filter option, and ready-made filters for common patterns such as removing every tool call from the history, precisely so that default can be trimmed to what the next agent actually needs.

The fix for both is the same: enumerate the payload instead of shipping a blob. A handoff worth writing down states:

  • the task, as a completion predicate the receiver can actually check
  • the constraints that survive the boundary, restated rather than assumed inherited
  • which state keys the receiver may read
  • which state keys the receiver may write, and under which merge strategy
  • what the receiver returns, and where it writes it

Pay attention to the fourth line. Write bugs are the harder half. An agent given too little to read produces a weak answer that a reviewer can spot. An agent that writes to a field it was never supposed to own corrupts the run for everyone after it, and looks fine on the way past.

Where this fits if you use Bespoke Prompting

Bespoke Prompting's Multi-Agent build type treats SHARED_STATE_SCHEMA as a core section rather than an optional one, and requires a merge strategy for every field. Where conflict risk on a particular field is high, the strategy for that field has to be stated explicitly and justified rather than left to the default.

Sources

Suggested internal links