Multi-Agent in Production
Running multi-agent systems as deployed infrastructure: four runtime topologies compared, the task envelope contract between agents, fleet versioning, distributed tracing across hops, retry-storm math, and a four-agent contract-review pipeline built end to end.
Last updated
After this section you can
- Apply the three-question gate that sends most multi-agent designs back to one agent with more tools
- Choose between in-process subagents, agent-per-service, durable workflow, and event bus topologies
- Design a task envelope carrying trace_id, budget, deadline, and schema version
- Deploy and version agents independently without breaking their peers
- Debug a 40-step distributed run from one trace
- Enforce a per-run token budget and prevent a fan-out retry storm from 9x-ing a bill
Multi-Agent Systems in Production
Not the pattern — the plumbing. What actually changes when agents call each other across a network, and what it costs when it goes wrong.
Hierarchical Delegation covers the pattern: an orchestrator, specialists, and how work is divided. This section covers everything that appears the moment those specialists become separately deployed processes — the wire contract between them, independent versioning, tracing across hops, partial failure, and the arithmetic of how a three-agent retry policy multiplies a bill by nine. As in SD-30, every step is layered: plain English first, then the mechanics with code, then a staff-level callout.
Most multi-agent designs should be one agent with more tools. Multi-agent is not a maturity level — it is a distributed system chosen over a function call, and you pay for it in latency, cost and debugging. Three gates, and the five answers that get you past them: