Multi-Agent Reliability Is a Context Handoff Problem

October 15, 2026

In April 2026, Cognition's Walden Yan published "Multi-Agents: What's Actually Working." It is worth reading closely, because it comes from the same team that, ten months earlier, published "Don't Build Multi-Agents."

The new conclusion: multi-agent systems now genuinely work, but only in a narrow form — several agents can contribute judgment, while writes stay single-threaded. The post is explicit that the original concerns still hold for designs where several agents write in parallel, and it calls arbitrary networks of agents negotiating with each other "mostly a distraction."

The industry conversation has moved from "should we split?" in 2025 to "how do we split without things breaking?" in 2026. This post walks through the most important public developments of the past year, shows the single problem they all point to, and shares the failures Feimore AI, a multi-agent content system, has run into on that problem and the fixes we found.

1. From a debate to a set of shared conclusions

It started with a debate in June 2025. Cognition argued that when you split a task among subagents, each one only knows the line the lead agent gave it and can't see the others' decisions, so you get parts that are each reasonable but don't fit together. Almost at the same time, Anthropic described its multi-agent research system: a lead agent plans, several subagents search in parallel, and on an internal research eval it beat a single Claude Opus 4 agent by 90.2%, at roughly 15× the tokens of a normal chat. LangChain summed up the disagreement in one line: multi-agent systems that mainly read are much easier than ones that mainly write.

More than a year on, research and hands-on experience have made the answer much clearer.

1. Failures come largely from system design, not only from models being too weak. Berkeley's MAST study first appeared in March 2025; its October 2025 version expanded the data to 1,642 execution traces across seven popular multi-agent frameworks and identified 14 failure modes. The four most frequent: repeating the same step (15.7%), a mismatch between reasoning and the action actually taken (13.2%), not knowing when to stop (12.4%), and not following the task specification (11.8%). The authors' view is that many failures come from organizational design and coordination between agents, and that better base models alone won't fix them all.

2. The patterns that hold up are restrained. Cognition's 2026 post lists three patterns that survive in production:

Separate generation from review. A coding agent and a review agent iterate on each other's work, and the reviewer works best when it does not share the coder's context; starting clean makes problems easier to spot. Their review agent finds about 2 bugs per PR on average, about 58% of them severe.
Escalate to a stronger model. When a cheaper primary model hits something hard, it hands a fork of its full context to a stronger model for judgment.
A manager with children. A manager agent splits the task, spawns subagents and coordinates them.

The same post is frank about what still fails: managers tend to give overly prescriptive instructions; agents assume their children share state that they actually don't have; and communication between agents doesn't happen by default. The author files all the remaining hard problems under one heading: communication.

3. Context is no longer treated as a text box you keep stuffing. Describing the design of its Agent Development Kit (ADK) in December 2025, Google wrote that "context is a compiled view over a richer stateful system." Sessions, memory and artifacts are the source; before each model call, the part needed for that call is compiled from them. The default rule is that every model call and every sub-agent sees the minimum context required. Handovers also need "translation": an earlier agent's messages must be marked as someone else's, or the receiving agent may believe it took those actions itself.

Put together, the conclusion is consistent: whether to split is not the core question. How context gets handed over once you split is.

2. Three typical ways context handover fails

Think of "context" as everything an agent can see when it makes a decision. In a human team, a sloppy handover means rework. In an agent system the damage is quieter, because a model never says "I didn't see that." It gives a perfectly reasonable-looking answer based on whatever it did see.

Each of the three failures below has a counterpart in the public discussion, and each is a problem Feimore ran into itself: the first two in real runs, the third during an end-to-end code trace.

1. Handover loss: the instruction arrives, the rejected work doesn't

The scene. The growth director agent proposes four content directions. The operator replies, in essence, "make them different from before." The system correctly reads this as "redo the directions" and passes the operator's words on to the redo step.

The problem. The four rejected directions were not handed over as required input. They only lived in an "optional context" section that gets trimmed when space is tight. So the redo agent knew it had to be different, but not different from what. Reviewing that run, we also found that the titles of the two rounds shared no wording at all. So even if the new directions were the old ideas in new words, text similarity could not catch it after the fact; the rejected content has to be handed to the model at handover time.

This is exactly the problem Cognition named in its 2026 post: the upstream step assumes the downstream one "should know" something it was never actually given.

The fix. We bind "what the person was shown" and "what the person said" into one inseparable unit, which we call a review turn. Whenever a downstream step reads a person's feedback, it must also read the exact content that feedback was about. Each regenerated direction must also state how it differs from the rejected ones, and a repeat flagged by the reviewer counts as a hard failure. This now covers the approval points of both the growth director and the creative director.

2. Truncation and "context rot": the model doesn't see what you think it sees

Public research. In July 2025 the vector database company Chroma published a study called "Context Rot." Testing 18 models, it found that across all experiments, performance consistently degraded as input grew; even a single similar distractor made results worse, and the effect of distractors grew with input length. A large context window does not mean the model uses all that context well.

Our case. After an operator asks for revisions to a finished video, one agent turns that feedback into concrete edit operations. Its input had a hard cap of 18,000 characters, while the real context ran 30,000 to 35,000. Worse, the content was ordered alphabetically by field name and then cut off, so the operator's feedback, the QA notes and the allowed range for speaking speed — all late in the alphabet — were dropped.

Seeing no feedback, the model correctly answered that nothing needed changing. But the format check treated "the edit list must not be empty" as a rule and sent it back. So the model copied the example from its instructions and invented a set of edits, including a speaking-speed value outside the allowed range, and the revision failed. On the surface it looked like "the model made random edits." The root cause was that the model never saw what it needed, and that "no changes" — a legitimate answer — was treated as an error.

The fix. Three changes together: pass only the materials the video actually uses, not all of them; give each section a budget by priority, shrink sections in a predefined order when space runs out — never chop off the tail — and tell the model explicitly what was left out for space; and accept "nothing to change" as a valid answer instead of forcing the model to produce something.

3. Identity drift: the same thing goes by different names in different steps

The scene. The creative director often produces several concepts for one platform, shown in the interface with labels like "TikTok-1" and "TikTok-2." Operators naturally reply using those labels: "Change the opening of TikTok-2."

The problem. Early on, several downstream steps would fill in a label by the concept's position whenever they couldn't read one, so the same concept could end up with different labels in different steps. After we moved to a central registry, a code trace turned up another hazard: in some cases the registry wasn't shared across steps, each concept got an empty table, and every concept on the same platform would be labeled "TikTok-1." An operator replying with a label would leave the system unable to tell which one was meant.

This is common in multi-agent systems: as long as the identity of one object can be generated in more than one place, sooner or later those places will disagree.

The fix. Identity is minted in one place and only read downstream. A concept's label is set once, when its creative card is created; later steps read it from the registry, then from the saved label, and every fallback that invented a label by position has been removed. Runs already in progress are not relabeled either, because a label a person has already seen must not change.

3. Principles we took from these failures

Read in parallel, write in a single thread. Feimore's market research runs several search lines in parallel, each returning with its original citations — a classic read task. The creative chain, from direction to script to finished video, is a relay: each step's output is the next step's input. We don't let several agents edit the same script at once.

Keep generation and review apart. In Feimore, the creative director writes concepts and the creative reviewer picks them apart one by one; the video producer renders and the quality reviewer scores independently. Reviewers send their findings back, but only the generating agent writes the changes. It is the same shape Cognition validated in 2026: separate generation from review, and keep writes single-threaded.

Hand over the work and its reasoning, not a summary. Summaries lose rejected options, implicit constraints and the reasons behind decisions. Our approach: one shared state serves as the source for the whole cycle, and what gets handed over is the structured output itself, together with its sources and approval records. Each agent's input is then assembled from that state as needed, rather than handing it everything. It is the same idea as Google's "context is a compiled view."

Separate required from optional, and budget for required first. More context is not always better, but not one piece of required information may be missing. What can be trimmed, and in what order, has to be defined in advance, rather than chopping off the tail when the limit is hit.

Identity, approvals and counters belong to code, not the model. A concept's label, who approved what, how many rounds an issue has gone back and forth — these facts must be absolutely reliable. Code maintains them; the model only reads them. Approval fields that appear inside model output are never trusted.

Give agents more information, not more checkpoints. Many "the agent got it wrong" problems come from a missing fact, not from a need for someone to watch over it. Our first choice is to supply the missing information, make the tools easier to use, and have tools explain on the spot why they failed. Only decisions that truly need human judgment, such as creative direction and final publishing, are left to people.

Verify against replays of real runs, not just hand-written test data. We once had a pre-production check that always passed in unit tests and never once worked in a real run: it read a field name different from the one the agent actually produced, and the test data happened to use the name the check expected. Hand-written test data easily makes the same mistakes as the code; the state of a real run exposes the mismatch.

Closing

From the 2025 debate to the 2026 consensus, it all ends up in one place: a system is only as reliable as each step's ability to see what it needs when it decides. Splitting is not a goal in itself. The parallelism and specialization it brings have a price, and that price is the handover.

For a task like content growth, research suits parallel work, creation suits a relay, and human judgment has to stay firmly bound to the content it is about. That is how we build Feimore AI, and where we believe multi-agent systems most deserve engineering effort.

References

Cognition, Multi-Agents: What's Actually Working (April 2026); Don't Build Multi-Agents (June 2025)
Google Developers Blog, Architecting efficient context-aware multi-agent framework for production (December 2025)
Cemri et al., Why Do Multi-Agent LLM Systems Fail? (MAST, first released March 2025, updated October 2025)
Anthropic, How we built our multi-agent research system (June 2025)
LangChain, How and when to build multi-agent systems
Chroma, Context Rot (July 2025)