Planner-Executor Meshes vs. Single Agents: A Practitioner's Note

Most agent systems start the same way: a single loop, one model, a tool list, and a prompt that says something like "think step by step, call tools as needed, stop when done." This is the ReAct pattern, and it's the right starting point for almost everything. It's cheap to build, easy to debug, and for a huge share of real workloads — lookups, single-document QA, short multi-step tasks with under a dozen tool calls — it's also the right finishing point. The mistake we see most often isn't choosing a single agent. It's staying there past the point where it stopped being the right choice, because splitting planning from execution looks like premature complexity right up until the day it isn't.

The signal, not the vibe

"This feels complex enough for a planner" is not a signal. Three things are:

Tool surface heterogeneity. A single agent reasoning over 40+ tools with overlapping capabilities degrades in a specific, measurable way — not gracefully, but as a step function. Once the tool count crosses roughly 15–20 (the exact number depends on how distinguishable the tools are), model attention starts collapsing onto tool names rather than tool semantics, and you get calls to the tool with the most plausible-sounding name instead of the correct one. A planner that first decides which subsystem owns the task, then hands off to an executor scoped to a narrow tool set, sidesteps this entirely — each executor sees 3–8 tools, not 40.

Failure isolation requirements. In a single loop, a bad tool call and a bad reasoning step look identical from the outside — both just produce a wrong action. If you need to know which failed (was the plan wrong, or was the execution of a correct plan wrong?), you need two things that can fail independently and be inspected independently. This matters enormously for anything with human review in the loop, because reviewers need to know what to correct.

Cost and latency asymmetry. Planning is a small number of expensive, careful reasoning calls. Execution is a larger number of cheap, narrow calls. Collapsing them into one loop means every tool call pays the planning model's latency and price, even when the tool call itself is trivial (a lookup, a format conversion, a status check). A planner-executor split lets you route the frequent, narrow calls to a smaller/cheaper model — this alone is often the biggest line item in an agent system's runtime cost.

If none of these three apply, stay with a single agent. The mesh is not free.

What the mesh actually costs

Three things, specifically:

1. Coordination state. The planner now has to maintain a model of what each executor has done, what it's waiting on, and what it returned — and that state has to survive across turns, retries, and partial failures. This is the part teams underestimate: it's not the number of agents that adds complexity, it's the state machine that coordinates them.
2. A second failure mode. Executors can now fail silently correct — an executor can complete its assigned subtask perfectly and still contribute to a wrong overall outcome because the plan itself was wrong. You need an explicit verification step after execution, not just after planning, or you'll ship confidently-wrong results.
3. Latency on the critical path. Planning is sequential by construction (you can't dispatch until you've decided what to dispatch), so a planner-executor mesh is not automatically faster end-to-end than a single loop, even though individual tool calls get cheaper. It's faster when executors can run in parallel; it's slower when they can't and you've added a planning round-trip on top.

A minimal pattern that holds up

The version of this that survives production, versus the version that looks good in a demo, has three specific properties:

• The planner's only output is a typed task graph (not free text) — a list of {executor, task, depends_on} tuples. This is the single highest-leverage decision in the whole design: a typed graph is inspectable, retryable per-node, and gives you a natural place to insert human review before dispatch.
• Executors are stateless per invocation. They receive a task and the outputs of their declared dependencies, and nothing else — no shared memory, no implicit context. This is what makes failure isolation real instead of theoretical: an executor that fails can be retried or swapped without touching anything else.
• Verification is a separate step from both planning and execution, and it's allowed to send work back to the planner, not just fail the run. This closes the loop that most planner-executor implementations leave open, where a bad plan just produces a bad final answer instead of triggering a replan.

None of this is exotic. It's closer to a workflow engine with an LLM at two specific decision points (plan, verify) than it is to "multi-agent AI" in the sense the phrase usually gets used. That's not a criticism of the pattern — it's exactly why it's boring enough to put into production and leave there.