Claude Opus 4.6 and Agent Teams: Putting Multi-Agent Work Into Production
Single-agent systems have a ceiling, and teams building serious automation hit it sooner than they expect. One agent handling a complex, multi-stage task accumulates too much in its context, loses track of earlier steps, and blurs responsibilities that should stay separate. The natural response is to split the work across several agents, each owning a piece, coordinating toward the outcome. When a model becomes capable enough to make that coordination reliable, multi-agent work moves from a research demonstration into something you can actually operate. What it does not become is simple.
The pitch for agent teams is appealing and easy to oversell. Several specialised agents, each expert at its part, collaborating like a well-operate team, sounds like a clean way past the single-agent ceiling. The reality that arrives in production is that you have traded a single agent’s limitations for a distributed system’s failure modes, and distributed systems fail in ways that are harder to see, harder to reproduce, and harder to govern. The capability is real. The operational burden it introduces is the part worth understanding before you build.
What splitting the work actually buys, and costs
Dividing a complex task across multiple agents solves a genuine problem. Each agent carries a narrower context, holds a clearer responsibility, and can be tuned and evaluated for its specific job. A research agent gathers, an analysis agent reasons over what it gathered, a drafting agent produces the output, and none of them has to hold the entire task in a single overloaded context. For work that exceeds what one agent handles cleanly, this decomposition is the thing that makes it tractable.
The cost arrives with the coordination. The moment work passes between agents, you have handoffs, and handoffs are where distributed systems break. An agent produces an output that the next agent misreads. An error introduced early propagates through the chain, growing as each downstream agent builds on the flawed input, until the final output is confidently wrong in a way no single agent would have produced alone. The agents worked. The coordination between them failed, and the failure is diffuse, spread across a chain rather than located in one place you can point to.
Orchestration is the system, not the agents
Here is the position worth holding. In a multi-agent system, the orchestration layer is where the real engineering lives, and the value and the risk of the whole system are determined more by how the agents are coordinated than by how capable any individual agent is. Teams building agent systems tend to spend their attention on the agents, because the agents are the interesting part, and under-build the orchestration, which is the part that actually decides whether the system works in production.
The orchestration layer owns the questions that determine reliability. How does work pass between agents, and what validates an output before the next agent consumes it? What happens when an agent produces something malformed, or an agent in the chain fails outright? How is the overall task tracked, so that a failure is located rather than merely observed at the end? A production AI system built from multiple agents is really an orchestration system that happens to call agents, and treating it that way, with the orchestration as the primary engineering artifact, is what separates a demo from something you can operate.
Governing a system with no single decision point
Multi-agent systems complicate governance in a specific way that matters for regulated work. In a single-agent system, there is one place where the decision happens, one context to inspect, one output to account for. Distribute the work and the decision is now spread across several agents and their handoffs. Reconstructing why the system produced a particular outcome means tracing a path through the whole chain, and no single interaction holds the answer.
This is a real cost, and it is one the excitement about agent teams routinely skips. A governed AI deployment built from multiple agents needs its accountability engineered deliberately: a record of what each agent received, produced, and passed on, so that an outcome can be traced to the step that shaped it. Without that, a multi-agent system is a black box made of smaller black boxes, and when something goes wrong you can see that it went wrong without being able to say where. For a workload that has to survive audit, that traceability is not an enhancement. It is a precondition for deploying the architecture at all.
Coordination costs more than it appears to
Every agent you add to a system adds capability and adds coordination surface. More agents means more specialisation and more of the handoffs where errors propagate and accountability diffuses. The right number of agents is the smallest number that makes the task tractable, because each one past that adds more failure surface than capability. Teams that reach for an elaborate multi-agent design when a simpler structure would serve are buying complexity they will pay for in operation, in every incident that requires tracing a fault across a chain that did not need to be that long.
The sub-agent that answered a question nobody asked
A team built a multi-agent system for a document-processing workflow, with separate agents for extraction, validation, and summarisation. In testing on clean inputs, it performed well, and the decomposition looked like the right call. Then a production document arrived that the extraction agent read slightly wrong. The validation agent, trusting its input, passed the error through. The summarisation agent built a confident, well-formed summary on the flawed extraction, and the final output looked entirely correct while resting on a mistake introduced three steps earlier.
Nobody could immediately say where it had gone wrong, because there was no record of what each agent had passed to the next. The extraction error was invisible in the polished final output. The fix was to build the orchestration the system had been missing: validation between handoffs so an agent’s output was checked before the next agent consumed it, and a trace of each step so a fault could be located rather than merely detected. The agents had been fine. The system connecting them had been left unbuilt, and that was the real ownership gap.
Agent teams are a genuine step past the single-agent ceiling, and the step comes with a bill that the architecture’s elegance tends to obscure. You are building a distributed system, with all the coordination, propagation, and accountability challenges that phrase has always carried, and the fact that the components are AI agents makes those challenges harder to see rather than easier. The capability is worth having for tasks that genuinely need it. The orchestration is worth building before you trust it.
The teams that operationalise multi-agent work successfully are the ones that treat the orchestration as the primary system and the agents as components it coordinates, engineering the handoffs, the validation, and the traceability with the seriousness the architecture demands. They add agents sparingly and account for every one. If multi-agent architecture is on your roadmap, the question worth settling before you build is whether you are prepared to engineer the coordination as carefully as the agents, because that coordination, and not the intelligence of any single agent, is what will decide whether the system holds up in production.
Related: Data Architecture
Tell us the number you need to move.
…outcomes that survive scrutiny.