I spent three weeks trying to fix a planner-executor pipeline that was failing in a way I couldn't name. The planner produced clean, well-structured plans. The executor followed them step by step. And the system was slower, more expensive, and less accurate than a single agent doing the whole thing in one loop.
I kept tuning prompts. The planner needed more detail. The executor needed clearer instructions. I upgraded the executor to a stronger model. Nothing helped, because I was diagnosing a coupling problem as a communication problem.
The research had already named what I was hitting. A 2026 paper on dynamic agentic RAG calls it the strategic-operational mismatch: when you decouple planning from execution, sophisticated planning strategies fail to materialize because the executors they depend on were never adapted to receive them. The planner learns to operate in a world where executors can handle its plans. The executors learn to handle the plans the planner produces. When you freeze one side and optimize the other, the system produces negative gains despite increased complexity.
I had been treating planning and execution as independent concerns. They are not.
The first place the coupling bites is the handoff itself. My planner and executor communicated through a plain text prompt. The planner did its reasoning, fetched some data, wrote a plan, and handed the executor a polished summary. The executor read the summary, decided what to do, and independently repeated work the planner had already done.
A GitHub issue from a production system documents the exact failure mode with painful specificity. The planner calls web_fetch three times to find a weather page, fails twice, succeeds on the third try, and writes the answer into its handoff text. The executor, receiving only the text, doesn't know the planner already fetched the page. So it calls web_fetch three more times, walks the same wrong paths, and burns the same latency again. The issue's summary is one line: the two sessions don't share tool call history, fetched data, or session state.
The cost isn't just duplicated work. It's duplicated reasoning. The executor can't tell whether the planner's answer is verified or provisional, whether the fetch succeeded or returned a cached fallback, whether the data is fresh or stale. It re-derives everything from a prose summary that was never designed to carry operational state.
The handoff loses more than tool history. It loses binding state.
A 2026 paper titled "When 'Must' Becomes 'Maybe'" studied exactly this in controlled synthetic episodes. Upstream state gets transformed into intermediate language artifacts — summaries, plans, tickets, handoff notes — from which downstream components act. The paper's finding is the one that should be taped to every planner-executor design review: semantic availability does not guarantee operational preservation.
An artifact can mention an unresolved condition while changing its role from something that must be resolved before execution to something that may inform, but no longer determines, the next action. The information is still semantically present. The constraint is gone.
Their numbers are brutal. Across 1,296 controlled episodes, normal handoff compression produced 100% deactivation of binding state and 54.2% forbidden action — meaning the executor took actions that should have been blocked by constraints the upstream state had established. Restoring all four state fields — prerequisite, authority, fallback, and execution consequence — raised preservation to 100% and reduced forbidden action to zero. But downstream verification, even when it caught the forbidden action, left artifact deactivation at 95.3%. The constraint was gone. The check caught the symptom, not the cause.
I had been verifying executor output. I had not been verifying that the executor received the constraints the planner had established.
The second coupling failure runs the other direction. The planner, lacking feedback about what the executor can actually handle, keeps decomposing.
The RWA taxonomy documents this as planning paralysis as goal drift. Planners encounter ambiguity, generate subtasks. Executors report insufficient specificity, triggering replanning into sub-subtasks. Executors report inadequate detail again, triggering additional cycles. After iterations, systems operate on plans with hundreds of steps, consuming resources in preparation rather than action. The paper's diagnosis is precise: planners correctly execute their mandate — the multi-agent structure lacks the feedback mechanism connecting granularity to execution progress. Executors report "cannot execute" without communicating "we spend 90% effort on planning with 10% on action".
The planner interprets failure as insufficient decomposition. It never learns that the problem is excessive overhead. The loop is self-reinforcing because the feedback channel carries the wrong signal.
I had been adding more planning detail every time the executor failed. The research says I was feeding the failure mode.
The reliability limits paper from 2026 gives the cleanest theoretical framing I've found. It models a multi-agent planner-executor architecture as a finite acyclic delegated decision network where stages process shared model-context information and communicate through limited-capacity language interfaces. The paper's central result: without new exogenous signals, any delegated network is decision-theoretically dominated by a centralized Bayes decision maker with access to the same information.
The key phrase is "without new exogenous signals." Adding a planner and an executor doesn't add new information to the system. It transforms and relays the same evidence through more stages, each one compressing it. The added stages mainly transform shared context rather than expanding what's available for the terminal decision.
This is why upgrading my executor didn't help. The executor wasn't information-starved because it was weak. It was information-starved because the handoff had stripped the signal before the executor ever saw it.
The fix is not abandoning the split. The research is clear that a well-designed separation buys attributability, verifiability, and cost efficiency. The fix is making the coupling explicit instead of pretending it doesn't exist.
Contracts, not prompts. The PEVG specification defines four roles — planner, executor, verifier, generator — each with its own declared contract. The planner decomposes into ordered steps with explicit dependencies. The executor performs actions under a capability contract. The verifier checks each result before it is believed. The critical design principle: roles may be co-located, but contracts may not be merged. When planner and executor share a model and a prompt, you lose the ability to attribute a failure to one role. When they share explicit contracts with typed outputs, you can.
Joint optimization, not frozen executors. The JADE paper's approach is co-adaptation. The planner learns to operate within executor capability boundaries while executors evolve to align with strategic intent. The planner learns to choose steps the executors can actually handle, while the executors improve to better support the planner's decisions. You don't freeze one side and optimize the other. You let them train together against outcome-based rewards. The result: well-coordinated smaller components outperform larger, less coordinated models.
Enforced role separation, not prompt-based. The TeamBench benchmark evaluated planner-executor-verifier teams under enforced operating-system-level role separation. Prompt-only and sandbox-enforced teams reached statistically indistinguishable pass rates — but prompt-only runs produced 3.6 times more cases where the verifier attempted to edit the executor's code. The verifier wasn't verifying. It was editing. And verifiers approved 49% of submissions that failed a deterministic grader. Role separation specified by prompts is not role separation. It's role theater.
Structured handoffs with preserved state. The traceability paper studied a Planner → Executor → Critic pipeline and found that adding a structured, accountable handoff between agents markedly improves accuracy and prevents the failures common in simple pipelines. The handoff carries not just the plan, but the raw tool results, the timestamps, the success flags, the constraints. Everything the downstream role needs to decide whether to trust the upstream output or re-derive it.
There's a deeper architectural lesson underneath all of this. The AdaptOrch paper argues that as models converge toward comparable benchmark performance, orchestration topology — the structural composition of how agents are coordinated — now dominates system-level performance over individual model capability. Topology-aware orchestration achieves 12–23% improvement over static single-topology baselines, even when using identical underlying models.
The planner-executor split is a topology. It's a sequential topology with a handoff. When that topology matches the task — genuine sequential dependency, stable decomposition — it works. When the task has parallel components or dynamic branching, the topology fights the work.
I had been using a sequential topology for a task that had parallel sub-questions. The planner decomposed them into a linear plan. The executor ran them one at a time. The handoff between each step lost state. The system was slower than a single agent because the architecture had serialized work that didn't need to be serialized, and the handoff had degraded the signal that survived.
The planner-executor split isn't wrong. The mistake is believing that planning and execution are separable concerns that can be optimized independently.
They are coupled through the handoff. The handoff carries the plan, the constraints, the tool history, the evidence, and the authority. Every one of those can degrade. When they degrade, the executor isn't failing because it's weak. It's failing because it received a plan with the constraints stripped out and a summary with the evidence compressed away.
The fix is not to merge planner and executor back into one agent. It's to make the coupling explicit: contracts instead of prompts, structured state instead of prose, joint optimization instead of frozen roles, enforced separation instead of assumed separation.
The teams that are shipping this successfully aren't choosing between "planner-executor" and "single agent." They're designing the handoff as carefully as they design the agents on either side of it.
So here's my question: When your executor fails a step, can you tell whether the problem was in the execution — or in the handoff that never delivered the state it needed to succeed?
I'd love to hear where you've landed. Frozen contracts, joint co-adaptation, a verifier that actually verifies, or a split you've quietly merged back together — and what finally made you stop tuning prompts and start looking at the coupling?