Multi-Agent Systems Break at the Collaboration Plane

Multi-agent systems break where agents coordinate.

This investigation begins much as the last investigation began: with a run that looks workable and a seemingly adequate summary for the supervisor from three individual specialists. The trace looks busy but largely as intended, with a nice stack of model calls as specialists work individually to develop focused answers to well-specified questions from the supervisor. Then there is a human query that changes everything: who knew what when, what did they find out when, and which thing found along the way actually drove the investigation in a particular direction.

Silence.

That silence is the collaboration plane missing from the architecture.

A common architecture for multi-agent systems has a Supervisor issuing requests to Workers, each of which performs a focused task. The results are returned to the Supervisor, which synthesizes the output from all the workers into a final answer for the Human. LangChain describes this as a subagent architecture, where the main agent calls subagents as tools, keeps track of the conversation memory, and uses stateless Worker calls as a way to isolate context and run in parallel (LangChain multi-agent subagents).

Coordination is where things start producing strange results.

This operating surface, the surface of a system that is used for work or investigation, stores the information needed by a cooperative system to function: the claims made by participants, the current work of every agent, the findings so far, summaries created for other users, and event queues that store the coordination of a team of workers across turns of a conversation. Without preserving evidence of those human-visible parts of the collaboration, the system quickly devolves into vibes tracked with logs rather than cooperative problem solving.

The supervisor pattern tops out

AWS Prescriptive Guidance makes the distinction that matters. Workflow agents run through a centralized coordinator. Multi-agent collaboration uses decentralized or role-based peers that negotiate, share information, adapt, and communicate through shared memory, messaging queues, or prompt chains (AWS Prescriptive Guidance on multi-agent collaboration).

That collaboration contract looks different. Tracking a workflow means caring about the point where the coordinator delegated a task. Tracking a cooperative investigation means caring about the point where each participant made a locally reasonable move given the evidence available to that participant.

I have recently come across a clean architecture for collaboration over investigation in Honeycomb's Canvas. In their architecture each investigation is modeled as an AWS AgentCore Runtime session. Instead of each user on the investigation having an isolated chat session with a single model in that session, all the agents on the investigation can read and write to a collaboration plane, and each user has an LLM session inside that investigation session (Honeycomb's shared-canvas architecture).

First, this surface is straightforward to manage. Every person can follow a lead. Their agents can follow completely different leads and still work together. In the multi-user case, each user has an LLM session, and the agents for all of the users run within the collaboration plane for that investigation.

That is the boundary I care about.

The idea we have long pursued is making agents as manageable as apps, by considering them runtime products made of model calls, tooling, sandboxes, policy, traces, evals, credentials, and audit receipts (enterprise AI agents are runtime products). Multi-agent systems add another critical boundary inside that space: the shared state surface that exists across agents collaborating to complete work.

Shared memory is too blunt

A shared memory bucket hides the actual boundary.

Memory is for facts and information. Collaboration state is for work in progress. Facts can help an agent recover from confusion. Work in progress decides whether the rest of the team gets confused with it.

When an investigation is shared with other people, the collaboration plane for that investigation contains five buckets: who claimed what hypothesis, what the current actions of the agents and humans are, what has been found, a summary of what each peer found and told their human, and a set of private event queues to coordinate the next moves of the agents and humans (Honeycomb's collaboration-plane details).

Claims prevent others from duplicating work that has already begun. Current activity shows other agents currently active within the investigation and provides situational awareness, no need for each agent to re-read the entire history of conversation for a topic. Findings allow negative results to travel across an investigation. A hypothesis that has been ruled out by one agent should shrink the search space for other agents investigating similar issues. Peer summaries allow humans to coordinate without forcing each human to read the entire conversation that another human had with an agent. An event queue coordinates turns within a collaboration and prevents work from becoming polling.

Tiny data model. Large operational consequence.

The shape is also familiar. Incident teams create a shared record out of the conversations that occur during an incident. Each person claims a thread of work, pins evidence, rules things in or out, and posts a note when context changes. I wrote about the same pattern in AI incident management breaks without a shared record, because the work is shared evidence under time pressure.

Agents become manageable only when their shared working space becomes the critical boundary that gets managed.

The runtime session is an architecture choice

AWS AgentCore Runtime makes the boundary concrete. The Bedrock AgentCore Runtime docs describe a session as a dedicated microVM with isolated CPU, memory, and filesystem for that session. Runtime sessions of different users are independent. The same runtime supports MCP and A2A communication, long running workloads up to eight hours, filesystem state across stop and restart, and traces for reasoning steps, tool invocations, and model interactions (Amazon Bedrock AgentCore Runtime).

Honeycomb took that approach for Canvas and mapped investigations to runtime sessions, because investigations are the durable units of analysis. User chats are transient. Agents come and go, stall and try again, then hand back context. The runtime reflects the nature of the work.

Generic multi-agent orchestration platforms are easy to demo but difficult to deploy for real work. Counting agents is easy. The state contract is harder: what agents assert to exist, what agents can modify, what gets recorded in trace attributes, what evals check, and what humans have to follow in order to retrace the steps of the agents to a particular conclusion.

No team_of_agents.final_answer field will save that design.

Collaboration bugs do not throw exceptions

MLflow's post about multi-agent observability names three failures that become apparent when multiple agents interact in a shared environment: cascading errors, shared memory pollution, and waiting loops (MLflow on multi-agent observability).

A stale finding is a fact. A specialist can time out while the parent agent waits. A negative result may never reach another agent, so the system spends time and money re-running the same series of tool calls that the first agent already ran. A peer summary can say something misleading, like "payment errors started after the deploy," based on a finding that actually ruled out the deploy in the first place.

The trace has to expose the collaboration plane, not only the LLM calls around it.

This means that instead of simply including the text of a message in a span as the event's description, the trace needs span attributes that track coordination objects: claim.created, claim.released, finding.superseded, peer_summary.read, event_queue.delivered, hypothesis.invalidated. The attribute names are less important than the discipline. The trace can now show which agent changed the shared state of the investigation, what evidence an agent attached to a finding, who read a peer summary, what events were delivered to an event queue, and what hypothesis an agent invalidated.

Awhile back, Focused made the observability point about agentic systems that I am making today about trace semantics: agentic systems need an observable collaboration surface, not a messy tangle of disconnected logs (observability and agentic systems).

The useful version joins them.

The eval should grade the handoff

Final-answer evals are too narrow for cooperative systems. They can report that a correct answer was produced by a multi-agent system, but they will not report the bad coordination path that produced it. The same bad path will, in the end, produce a wrong answer that no one will be able to explain.

I investigated how to measure behavioral structure for cooperative work. The arXiv paper on Entropy-Based Observability for AI Agent Behavior develops trace-derived signals that give insight into agent behavior: action entropy, trajectory entropy, tool entropy, information gain, and outcome entropy. Success, reward, latency, and cost fail to capture behavior that matters. I think these metrics would be useful for getting a handle on the collaboration plane, where such behavioral structure already exists and is now observable (Entropy-Based Observability for AI Agent Behavior).

A collaboration eval should ask boring questions.

Did the agent check active claims for other agents before starting to work on a finding? Was there enough evidence added to a finding to aid agents who may later refer to that finding? Were agents treating summaries from other agents as hints or as facts that led them down a false path? Were stale findings properly superseded by new findings? Did the trace show the key event that caused the second agent to change its work plan?

Those checks belong next to the regular success metrics. They are the difference between "the system answered correctly" and "the system coordinated in a way I would trust again."

This is where conversation IDs earn their keep. A single conversation ID across agents and tools lets the trace preserve the user-facing path. Cooperative investigations also require investigation IDs, claim IDs, finding IDs, and queue-event IDs for the trace to be of any use for the work being done (AI agent observability runs on conversation IDs). The ID model must mirror the collaboration model. Correlating calls is not enough to explain the work done by the system.

Own the collaboration plane

Multi-agent architecture should start with the shared record.

First, determine the durable unit: a case, incident, investigation, branch, or task. Then decide which collaboration objects reside within that record: claims, findings, active work, peer summaries, evidence, event queues, approvals, rejected hypotheses, and rollback notes. Agent handoffs, for example, can be implemented as routing, but that would miss the point of runtime state. Agent handoffs turn routing into runtime state, and LangChain handoffs persist state across turns by updating a state variable and changing behavior based on that state (LangChain multi-agent handoffs).

What is the shared surface of truth while agents work together?

If the durable unit of work is the transcript, then the system is simply a chat app with extra workers. If the durable unit of work is a vector store, then the system can store facts about work, but it cannot do the work. If the durable unit of work is a traceable collaboration plane with explicit objects, owners, mutations, and eval checks, then the system has a shot at real work.

Buyers will specify multi agent AI, multi agent architecture, and multi-agent collaboration because those phrases sound like capability requirements. I would interpret the ask as a collaboration-plane contract which the AI agents execute.

Show the objects. Show the trace. Show the eval. Show how two agents chase a single hypothesis for a while. Show how one agent can go down a wrong path and write a finding that is bad for subsequent work. Show how a human can find that finding and correct it. Show how another agent can then change direction as a result of the new finding.

That is the system.

The agent count is trivia.