Everyone wants to build a team of AI agents. The demos look irresistible. One agent researches, another writes code, and a third runs tests. But most of these systems share a dirty secret: they are fragile. They work beautifully during a five-minute demo and fall apart during a real investigation. The failure point is rarely the language model's reasoning ability or the number of agents in the swarm. It is the space between them. Multi-agent systems break at the collaboration plane.
The Supervisor Trap
The default architecture is seductively simple. A supervisor agent receives a goal, slices it into subtasks, and delegates to worker agents. The workers execute, return results, and the supervisor stitches everything together into a final answer. This pattern is fine if you are summarizing ten articles, transcribing audio files, or extracting data from a hundred uniform web pages. The tasks are independent. They do not talk back.
Complex investigations are different. When an agent uncovers a surprising finding, the entire direction of the work might need to shift. If the system has no structured way to broadcast that shift, other agents keep marching in the wrong direction. You end up with a collection of parallel monologues instead of a conversation. The supervisor becomes a bottleneck, not a coordinator.
What Disappears When Coordination Fails
When an investigation gets deep, you need to know far more than the final answer. You need to know who knew what and when. You need to trace what finding drove the direction of the work. You need to understand why an agent changed its plan two hours ago. Without a collaboration plane, none of this is visible. You have logs. Logs are chronological noise. They record that Agent C suddenly started analyzing database transactions instead of API calls, but they do not explain why. You can watch it happen and guess.
Picture a security incident response. Agent A pores over server logs and concludes the breach did not start there. It returns its output to the supervisor. Agent B, assigned to analyze network traffic, never sees that conclusion framed as a rejected hypothesis. Because its original task description still treats the server as the primary suspect, Agent B wastes another cycle looking for fingerprints in the same logs. The system pays for the same work twice and learns nothing from the first run.
The Collaboration Plane Is Not Memory
A collaboration plane is not just a memory bucket for facts. Memory stores information. Collaboration state stores work in progress. A vector database full of documents gives an agent reference material. It does not tell the agent that Agent X is currently testing a hypothesis that would make Agent Y’s current task redundant. Memory is static context. Collaboration state is the live map of the operation.
If you confuse the two, you build systems that can retrieve every paragraph of your company handbook but cannot tell you whether another agent just proved your current task irrelevant.
The Five Buckets of Shared State
A real collaboration plane needs five specific buckets.
Claims. These are the active hypotheses an agent is testing. In a fraud investigation, a claim might be "the anomaly correlates with weekend batch jobs." Every agent should be able to see which claims are open, which are being tested, and who owns them. Without