writing · 2026-07-02
Multi-agent systems don't fail. They drift.
A2A solves how agents talk to each other. It doesn't solve how they stay pointed at the same outcome. Each agent can do its job correctly and the system still produces the wrong result.
The failure mode people worry about in multi-agent systems is an agent doing something wrong. The failure mode that actually happens in production is subtler: every agent does something reasonable, and the result is still wrong.
A2A solves the mechanical problem of agent interoperability: discovery, invocation, response format. That problem was worth solving. But the problem it does not solve is coherence: keeping all agents in a chain oriented toward the same goal, with the same understanding of what has already happened.
Why decomposition is harder than it looks
When you decompose a task across multiple agents, you are making a bet that the pieces add up to the whole. That bet is often wrong in a specific way: each agent optimises locally. It receives an input, does something sensible with it, and returns an output. It has no visibility into what came before it or what comes after. It does not know it is part of a larger task.
The result is a system where each step is defensible and the chain is incoherent. Agent A summarises a case. Agent B classifies it based on the summary. Agent C generates a resolution based on the classification. The resolution is wrong. Not because any agent failed, but because a detail that mattered was already gone by step two.
This is not a new problem. It is the same problem as any pipeline that loses information at each stage. Multi-agent systems make it easier to create these pipelines at scale without noticing.
Context is not automatically shared
A2A defines how agents communicate. It does not define what they share. By default, each agent sees only what it is given. If the orchestrator passes a summary instead of the full record, the downstream agent reasons over the summary. If a relevant signal is in the retrieval results but not in the structured handoff, it disappears.
The practical implication is that context design is the real work in a multi-agent system. Not which agents to use, not which model to call, but what each agent needs to see, in what form, to make a good decision. That design requires understanding the whole chain, not just the individual steps.
A shared execution context, where each step reads from and writes into a common structure that accumulates as the workflow progresses, is one answer. It keeps later agents grounded in the full history of the run, not just the most recent output. It also makes the context inspectable: when something goes wrong, you can see exactly what each agent was given.
The local correctness trap
There is a specific failure mode worth naming: agents that are individually well-prompted but collectively misaligned.
You can tune Agent B to be excellent at classification given a good summary. If Agent A’s summaries are systematically lossy in a way that matters for classification, Agent B’s quality does not help. Evaluating each agent in isolation misses this. The failure only appears when you run the chain end-to-end and compare the final output against ground truth.
This is why end-to-end evaluation is not optional in multi-agent systems. Per-agent benchmarks tell you whether each component is capable. They do not tell you whether the composition works.
What A2A changes and what it doesn’t
A2A makes it easy to add agents to a system. That is genuinely useful: specialised agents, independently developed and deployed, callable by any orchestrator that knows the interface. The ecosystem benefit is real.
But easy composition also means easy over-composition. The right number of agents in a chain is the minimum needed to do the task well. Each additional hop is another place for context to be lossy, another boundary where the goal can drift, another step to debug when the output is wrong.
A2A is a coordination protocol. Coherence is an architecture decision. The spec does not make that decision for you.
Decompose the task. Design the context. Evaluate the chain. In that order.