The third agent is where it stops being fun
Two agents talking to each other is a demo. Three is a distributed system, and nobody told the team that built it. The arithmetic is unkind: two agents give you one handoff boundary, three give you three, five give you ten, eight give you twenty eight. Every boundary is somewhere context gets truncated, a tool call gets retried against stale state, or an agent acts confidently on a summary of a summary. The failure almost never looks like a bad model. It looks like a workflow that ran forty times cleanly and then issued a refund nobody can explain. When the postmortem starts, the question is always the same, and the answer is usually no. Can you replay it?
What a handoff actually has to carry
An agent handoff isn't a function call, even when your framework makes it look like one. A function call passes arguments. A handoff passes intent, partial state, a budget, and an authority level, and most frameworks give you only the first one for free. Intent means what the receiving agent is being asked to achieve, stated so it can verify it got there. State means the facts it needs passed as structured data rather than prose, because prose is lossy and a summary of a summary is how a wrong customer ID survives three hops. Budget means how many tool calls, how many tokens, how much wall clock, so a retry loop between two agents can't quietly bill you for a weekend. Authority is the one teams skip. Permissions get granted per agent at design time, then ride through a chain nobody modelled. The planning agent has read access to the warehouse. It delegates to a writer agent. The writer inherits the session. Now something with a much looser objective is holding your warehouse credentials, and no reviewer ever approved that combination because on the architecture diagram it was two separate boxes.
Build the run record before you build the second agent
Here's the recommendation most teams push back on. Don't add a second agent until a single agent produces a run record you can read six weeks later without the engineer who wrote it sitting next to you. That record needs a run identifier that survives every hop, the inputs and outputs of each tool call with arguments intact, the handoff payloads themselves, the identity that authorised each action, and the version of every prompt and model in play. Prompt version matters more than people expect. A one line edit to a planner prompt changes routing behaviour across the whole graph, and if your log records only the model name you'll spend a day proving which change caused the drift. Teams that skip this debug by re-running the chain and hoping it misbehaves again. That isn't debugging. That's fishing.
Where the regulators land in the same place
The EU AI Act reaches this conclusion from a different direction. Article 12 requires high risk AI systems to automatically record events across their lifetime. Article 14 requires human oversight a person can actually exercise, which means an operator has to be able to see what the system did and step in. Article 26 puts matching duties on the deployer rather than only the provider, so adopting someone else's orchestration framework doesn't move the obligation off your desk. Article 99 sets the ceiling for the most serious breaches at EUR 35 million or 7 percent of worldwide annual turnover. ISO/IEC 42001, published in December 2023, asks for the same discipline in management system language. Annex A control A.6 covers the AI system lifecycle, and auditors read it as evidence you can account for what a system did once it was live. Neither is the reason to build the run record. The reason is that you can't operate the system without one. What's useful is that the work making a multi agent system debuggable is the same work that makes it defensible, which is a rare case of the engineering ask and the audit ask pointing the same direction.
A sequence that survives contact with production
Start with one agent and a tight set of tools. Measure it against the outcome you actually care about, not against a vibe check. When it fails, the fix is usually a better tool boundary or a narrower objective, not a colleague for it. When you do split, split on a real seam. A different data domain, a different authority level, a different cost of being wrong. Splitting into a research agent and a writing agent is a seam in a blog post, not in a system. Splitting into one path that reads customer data and one that writes to the ledger is a seam, because those two need different permissions and different review. Give the graph a supervisor that owns the budget and the stop condition. Keep the graph shallow. Put human review where a silent error costs the most, rather than where the team feels least confident, and note that those are different places more often than you'd guess. Ship the first version with one seam. Add the second only after you've run the first for a month and can state what it costs per completed outcome.
When not to build this at all
A lot of what gets pitched as multi agent orchestration is a state machine with a language model in two of the states. If the routing logic is deterministic, write the routing logic. You get something you can test, a control flow you can draw on a whiteboard, and a bill you can forecast. Roughly 720 people a month search for multi agent orchestration, and the term is competitive enough that most of what they find is framework marketing. The frameworks are mostly fine. The question they don't answer is whether your problem has more than one seam in it. Most don't, yet. We partner with regulated teams to get AI into production that delivers real business value and that they stay in control of. The pattern we run into most is a team three agents deep on a problem that had one seam, with no run record and a stalled rollout. Operators who have taken AI to production at 300,000 organization scale learn to make the second agent earn its place.