Multi-agent orchestration, handoff design, and routing
Coordinating several agents or steps into one reliable system: routing, handoff contracts, shared state, retries, and knowing when a single agent is the better design.
Agent orchestration is the coordination layer above individual agents: routing work to the right handler, defining what gets passed at each handoff, holding shared state, and recovering when a step fails. It matters once a workflow has genuinely distinct stages that need different tools or different judgment. It is for teams whose first agent worked and whose second and third are now stepping on each other.
The problem
Multi-agent architectures are the most over-applied idea in this field. Splitting one agent into five usually multiplies the failure modes without improving the output. But some workflows genuinely have separate stages, and running those through one prompt produces an agent that does everything slightly badly.
- One agent has twenty tools and picks the wrong one regularly.
- The prompt has grown to several pages covering every case, and editing it breaks unrelated behaviour.
- Two agents both write to the same record and the last one wins.
- A failure halfway through leaves the work in an unclear state that nobody can resume.
- Nobody can say which step made a given decision, because there is no trace across the whole run.
What we build
An honest architecture decision
Whether this needs multiple agents at all. Frequently the answer is one agent with better tools, and that is a cheaper system to run and debug.
Routing
Classifying incoming work and sending it to the right handler, with an explicit path for the cases that match nothing.
Handoff contracts
A defined, validated shape for what passes between steps. Handoffs as free-form text are where multi-agent systems quietly lose information.
Shared state
One durable record of the run that each step reads and updates, so a failure can resume rather than restart.
Failure and retry policy
Per-step decisions about what retries, what escalates, and what rolls back, so a partial failure does not leave a half-finished record.
End-to-end tracing
One trace covering the whole run across every step, because debugging a multi-agent system without it is guesswork.
What you get at handoff
- Orchestration code and step definitions in your repository.
- The handoff schemas, documented, so a new step can be added safely.
- A runbook covering partial failure and how to resume a stuck run.
- Traces spanning the full workflow, not per-step fragments.
- A written record of why the architecture is shaped this way.
Stack
Models
Claude, OpenAI, Smaller models for routing and classification
Language
Python, TypeScript
State and queues
Postgres, DynamoDB, Redis, SQS
Coordination
Step functions, Airflow, Durable workflow patterns
Observability
Distributed tracing, Per-step metrics, Cost attribution
Related services
FAQ
Do we need multiple agents?
Probably not yet. Multi-agent designs are worth it when stages need genuinely different tools, different models, or different approval rules. If you are splitting an agent up because its prompt got long, better tool design usually fixes that with far less operational complexity.
What is a handoff contract?
A defined schema for what one step passes to the next, validated at the boundary. The alternative is passing prose between agents, which loses information silently and makes failures nearly impossible to trace.
How do you keep costs from multiplying?
By using small models for routing and classification, passing structured state rather than resending full history at each step, and attributing cost per step so the expensive one is identifiable. Naive multi-agent designs re-send the entire conversation to every agent, which is where budgets disappear.
What happens when one step fails?
The run holds its state, the failure is classified as retryable or terminal, and the workflow either retries that step or escalates with everything completed so far preserved. Partial completion is a state the system understands rather than a mess someone has to unpick.
Can this coordinate with our existing pipelines?
Yes, and it usually should. Agent steps often sit alongside ordinary data work, and Airflow or your existing scheduler is frequently the right coordinator rather than introducing a separate agent framework.
Ready to scope Agent Orchestration?
Send the workflow, tool stack, or reporting problem. We will tell you what should be automated, what should stay manual, and what is worth building first.