Most Multi-Agent Systems Should Be One Agent and a State Machine

Where the Handoffs Actually Hurt

An agent handoff is a lossy serialization step. One model compresses its reasoning into a message, and the next model re-interprets it with no shared memory of why. Every arrow in your diagram is a place where the receiving agent confidently acts on a misread. We've traced production failures to exactly this: the planner decided X, phrased it as Y, and the executor did Z.

The cost is the obvious part. Each agent re-reads the accumulated context, so a five-hop chain pays for the same tokens five times over. We've seen this dominate the bill in systems that blew their budget at scale, the reasoning was cheap, the re-passing of state was not.

The quiet killer is evals. A single agent has one input distribution and one output you can grade. Add a handoff and you now need to eval each agent in isolation and the composition, because a sub-agent that scores 95% alone can still tank the pipeline when its output format drifts a little and the next agent silently mishandles it. Grading the whole chain end-to-end tells you it broke, not where. And grading agents that take actions is already the hard part before you multiply it by the number of hops.

An agent handoff is a lossy serialization step — every arrow is a place where intent gets garbled and the next model acts on the misread.

The Pattern We Actually Ship

Strip the metaphor and most of these systems have one genuine reasoning task: decide what to do next given the current state. That's one agent. Everything around it, routing, retries, validation, sequencing, is deterministic code that doesn't need a language model at all.

So the shape is: one planner that reasons, typed tool calls that do the work, and explicit state the orchestrator owns. The planner picks a tool and arguments. Your code validates the arguments against a schema, executes, writes the result into a state object, and loops back. The "agents" you were going to build, researcher, writer, critic, become tools or prompt modes the single planner invokes. They don't each run their own autonomous loop with a separate context window.

The wins are concrete and boring, which is the point:

• →State lives in one place you can log, inspect, and replay, a failed run reconstructs deterministically instead of scattering across five agents' memories.
• →Retries and fallbacks are `if` statements, not another model deciding whether to retry.
• →Cost drops because context is passed once and tools return structured data, not prose the next agent has to re-parse.
• →You eval the one reasoning step in isolation and the deterministic parts don't need eval at all, they need unit tests.

Typed Tool Calls Are the Contract, Not the Fix

Making tool calls typed and validated is the load-bearing move, but don't mistake a passing schema for a correct call. A planner will happily emit an argument that validates cleanly and is still wrong, the same way structured output can be schema-valid and semantically false. The schema catches malformed calls; it does not catch a plausible-looking bad decision.

So the validation layer between planner and tool does real work: bounds-check arguments, reject calls that don't make sense given current state, and refuse actions outside the agent's defined boundary before they execute. In a multi-agent design, this same guarding has to be duplicated at every handoff — or, more commonly, it just isn't, and one agent trusts another agent's output as if it were validated. Centralizing it in one orchestrator is why the single-agent shape is safer, not only cheaper.

This is also where observability gets tractable. One state object plus typed tool spans means a failed run localizes in minutes. Chase the same failure across five agents' loosely-typed message passing and you're reading transcripts for a day.

When Separate Agents Genuinely Earn Their Keep

This isn't a blanket rule. There are three cases where we'll reach for real separate agents, and they're narrower than most diagrams assume.

First, genuine parallelism. If you need to fan out ten independent research queries and merge the results, running them concurrently as isolated agents is legitimately faster, the sub-tasks don't share state and don't need to. That's just parallel workers doing separate jobs. Nobody's holding a conversation.

Second, hard isolation boundaries. When one sub-task must run with different permissions, a different model, or in a sandbox, for example an agent that executes untrusted user-provided code, you want a real process boundary, not a prompt mode. Treat those the way you'd treat any untrusted insider: isolated, least-privilege, auditable.

Third, independent release cadence. If two capabilities are owned by different teams shipping on different schedules with their own evals and rollback, splitting them into separately deployed agents is an org decision that happens to be correct architecturally. That's Conway's law working for you. The reasoning didn't demand it.

• →Real parallelism, independent sub-tasks that don't share state and run concurrently for wall-clock speed.
• →Hard isolation, different permissions, models, or a sandbox for untrusted execution, needing a real process boundary.
• →Independent release cadence, separate teams, separate evals, separate rollback, deployed on their own schedule.

The Test: Can You Eval the Sub-Agent Alone?

Here's the rule we use before splitting anything into its own agent: write the pass/fail eval for that sub-agent in isolation, with a fixed input and an assertable output. Can't do it? If the only way to know whether the "critic" did its job is to run the whole pipeline and look at the final result, then it isn't a separate agent at all. It's a step in one agent's reasoning, and calling it something grander just hides the eval problem behind an architecture diagram.

The corollary: if two "agents" always run in strict sequence and never do anything independently useful, they're one agent. Sequence is orchestration. You don't need a second language model to know that step two follows step one, that's what code is for. This is the same instinct behind choosing a constrained workflow over an agent whenever the task allows it.

Run every proposed agent through those two questions and most five-agent diagrams collapse to one planner and a state machine. That's not a downgrade. It's the version you can actually test, debug at 2am, and put a cost ceiling on.

What's Still Genuinely Hard

Collapsing to a single planner doesn't make the reasoning easy — it concentrates it. One agent doing more decisions means a longer, denser prompt and more room for the planner to lose the thread on a complex state. We manage this with tight tool scoping and by keeping the planner's job to "pick the next action," not "hold the whole plan in its head," but long-horizon tasks still strain it.

And the honest failure mode of the simple pattern is tool-call sprawl: a single planner second-guessing itself, re-querying, looping. That doesn't go away because you have one agent, it just becomes measurable in one place, which is the whole argument. Budget the tool calls, instrument the thrashing, and cap it in code.

The move is to start from one agent and add separation only where the eval-in-isolation test forces you to. Adding agents is easy and always available later. Removing them from a system that already leans on their handoffs is a rewrite.