I Split One Agent Into Three. The Plan Never Reached the Executor.

A LangGraph subgraph boundary dropped the plan, and the gain came from re-reading the source, not the plan.

I gave a local 8B model a planning step before it did the real work, and modeled the handoff the way a LangGraph subgraph's own state schema actually behaves: a key the parent step produces but the child's schema never declares is simply gone on the other side. The plan never reached the next step intact: on every single task, the part that crossed that boundary was a 60-character fragment of what the planner actually wrote. I expected that to hurt. The three-step pipeline still beat the single-call baseline on accuracy, by a real margin. Those two facts together are the whole reason this is worth reading, because the second one does not mean what it looks like it means.

I wrote this with AI assistance, and I fact-checked and edited every claim myself.

Proof block. Ollama's llama3.1:8b, running locally, zero API cost, temperature 0, fixed seed. 12 synthetic incident-report extraction tasks, one deterministic run per condition (a real, stated limit, not a hidden one). Condition A: one call per task. Condition B: a plain-Python three-step pipeline, planner then executor then reviewer, that models a LangGraph subgraph's state-schema boundary rather than running an actual LangGraph graph, 36 calls total. Every claim below traces to a public, re-runnable repository: github.com/priyansh18/agent-handoff-loss-benchmark.

TL;DR

Four things came out of this run worth stating before any explanation:

• The three-step pipeline scored 91.7% field accuracy against the single call's 83.3%, at 4.4x the tokens and 5.7x the wall-clock time.
• On 12 out of 12 tasks, the planner's own notes (368 to 584 characters each) were truncated to 60 characters before the executor ever saw them, a real state-schema mismatch, not a prompt bug.
• Three individual fields, across three different tasks, flipped from wrong to right. I logged the executor's intermediate answer separately from the reviewer's final one, specifically so I could check which step did the work instead of assuming: the executor alone, reading the full report plus whatever fragment of the hint survived, already reaches 88.9% (32/36) before the reviewer ever runs. The reviewer adds exactly one more field on top of that.
• None of the three fixes trace to the planner's hint carrying something useful across the boundary. Two happened with a hint that was pure boilerplate, no task-specific content at all. The third happened with a hint that did contain a genuinely useful word, by accident of where the planner's sentence break fell, not because the pipeline was designed to protect it.

Multi-agent LangGraph handoff loss, which is the specific failure this run reproduces in miniature, is the same shape of problem Anthropic names in its own multi-agent systems engineering writeup: agents typically use about 4x more tokens than a single chat turn, and a full multi-agent system about 15x, with part of that cost going toward what the piece calls a "game of telephone" when one agent's output gets summarized and re-summarized on its way to the next one. Anthropic's own fix is to have subagents write full output to a shared store instead of passing a compressed summary through conversation. I wanted a number for the failure mode before I believed the fix, not just a paragraph agreeing with it.

The hypothesis

Stated before running anything, so the result can actually fail it: splitting a single extraction call into a planner-then-executor-then-reviewer pipeline, with the executor's state schema narrower than what the planner produces, will measurably lose information at the handoff, and that loss will show up as no better (or worse) accuracy than the single-call baseline, not as an improvement. The first half of that held. The second half was wrong, for a reason worth sitting with.

Method: the subgraph handoff

Twelve short, fictional incident reports, written as test fixtures, each describing one bug: a Redis connection pool exhausted by a feature-flag rollout, a stale model artifact overwriting a cached file, a password-reset link truncated by a URL shortener, and nine more in the same shape. Each has a ground truth of required keywords for three fields: root_cause, affected_component, fix_action. A field counts correct if the model's answer contains at least one of the required keywords for that field, a deliberately mechanical grader so the scoring is reproducible and not a matter of my own judgment call.

Condition A asks llama3.1:8b once per task for all three fields as JSON. Condition B runs three calls per task:

# The subgraph boundary, as code, not prose.
# The planner writes full notes; the executor only ever sees this:
focus_hint = plan_notes.split(".")[0][:60] if plan_notes else ""

That line is the entire experiment's load-bearing detail, and it is plain Python, not a LangGraph StateGraph call. I wrote it that way deliberately, to model something LangGraph's own subgraph docs describe without needing the framework's full runtime: a subgraph's state schema is what actually crosses the parent/child boundary, and a key the parent step produced but the child's schema never declared is simply absent on the other side. No exception, no warning. I made the schema narrow on purpose, the way a team under deadline pressure genuinely does, by wiring a field name before thinking hard about what actually needs to survive the handoff.

The executor then extracts the three fields with that 60-character hint attached, and a reviewer sees the original report plus the executor's JSON and can correct it. Three calls, three chances to get something right, one shared report each time.

Results, before any explanation

Single call vs. three-step pipeline, same 12 tasks, same model, same machine. Image by author, generated from the run's own summary.json.

The numbers, side by side:

• Field accuracy: 30/36 (83.3%) for the single call vs. 33/36 (91.7%) for the three-step pipeline.
• Tasks with all 3 fields correct: 7/12 vs. 9/12.
• LLM calls: 12 vs. 36.
• Total tokens: 1,659 vs. 7,323.
• Wall-clock time: 72.7s vs. 411.1s.

And the handoff number, which the comparison above does not show: on 12 of 12 tasks, the full planner output ran 368 to 584 characters, and the focus_hint that actually reached the executor was capped at 60. Here is what that looked like on one task, with the exact logged text, not a paraphrase:

Image by author, generated programmatically from the actual run's raw_results.jsonl.

Planner, in full, on the retry-storm task: "Here's a short investigation note: 'Review the system logs to identify the timing and duration of the downstream outage and its impact on the billing worker queue. Investigate the retry logic to determine why the system did not implement exponential backoff initially, and examine the configuration or code changes that were made to implement backoff. Additionally, assess whether the retry storm caused any data inconsistencies or other issues.'" What the executor received: "Here's a short investigation note: 'Review the system logs", 60 characters, cut before "retry storm" or "backoff" ever appear.

Failure analysis: where the gain actually came from

Three fields, across three different tasks, flipped from wrong to right between conditions. I logged the executor's intermediate answer separately from the reviewer's final one specifically so I could check which step did the work instead of assuming, and the three did not all resolve the same way.

On feature-flag-leak, the planner's hint was pure boilerplate: "Here's a short investigation note: Investigation Note", 60 characters of preamble, zero task-specific content, the cleanest version of a useless hint in the whole run. The executor's own answer, before the reviewer ever touched it, still read "feature-flag targeting rule leak due to shared cache entry reuse", correct, despite the hint carrying nothing. It got there by reading the full original report, which every step in the pipeline receives in addition to whatever the planner's hint says.

On retry-storm, the hint was semi-generic ("Review the system logs"), not pure boilerplate, but not specific either. The executor's answer stayed wrong, same gap as the single call: "downstream outage," no mention of a retry storm. The reviewer step, given the full report a second time, corrected it to "downstream outage caused a retry storm" and passed. This is the one fix in the whole run that specifically needed the reviewer, not just the executor's own read.

The third, on redis-pool, is the one honest complication: the single call missed "redis" / "connection pool," but the executor fixed it, and this time the 60-character hint actually did contain "Review the Redis connection pool confi", the planner happened to lead with exactly the right words before the cutoff landed. I can't rule out the hint helping here, and saying it was "useless" for this task specifically would be overclaiming in the opposite direction. What I can say is that two of the three fixes happened with hints that contributed nothing, and the one case where the hint might have helped was a matter of where a sentence break happened to fall, not something the pipeline's schema was designed to guarantee.

Put together: the planner step, measured honestly, earned nothing reliable this run. Its one plausible contribution depended on accidental phrasing, not the architecture. The executor's own full-report read, independent of the hint, already gets to 88.9% (32/36), measured directly from the saved intermediate answers, not inferred. The reviewer adds exactly one more field on top of that, 33/36. If I had cut the planner and reviewer entirely and sent the report straight to one executor-shaped call, I would expect something close to that 88.9% figure, not the 83.3% single-call baseline, because the executor prompt itself asks for more structured output than the bare single-call prompt does. I did not run that exact ablation, so that specific comparison stays a reasoned expectation, not a measured result; everything else in this section is measured.

There is a real theoretical reason to expect source re-reading to matter more than hand-off content here, not just my own anecdote. A April 2026 Stanford preprint, "Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets" by Dat Tran and Douwe Kiela, holds the reasoning-token budget constant across single- and multi-agent setups on three model families and finds single agents consistently match or beat multi-agent ones. Their explanation leans on the Data Processing Inequality: once one agent passes a processed version of its context to the next, information can only be lost or stay the same across that step, never gained. My focus_hint truncation is that inequality made concrete and measurable, not an edge case. My own run adds one more data point in the same direction, with the mechanism visible in the logs rather than inferred: the win was real, 91.7% beats 83.3%, but it was bought mostly by steps re-reading the original source report, not by the architecture's planning step, which is the part most multi-agent write-ups spend the most words justifying.

When a review step earns its cost, and when it doesn't

The honest reading of this run is narrower than "multi-agent wins" or "multi-agent is a trap." Both would oversell a 12-task local run. What it does support: a step that looks at the original source material again rather than trusting an earlier step's summary of it can catch real mistakes, and that happened across three fields here, at the cost of 4.4x the tokens and 5.7x the latency. A planning pass that hands off through a schema too narrow for what it produced bought nothing reliable, and would have looked close to identical in the summary table if I had cut it entirely and gone straight from report to executor to reviewer.

Before adding a planning step to any pipeline, the question worth asking is not "would more structure help," it's "what, specifically, needs to survive from this step to the next one, and does my state schema actually carry it." That is a concrete, checkable thing, not a vibe. Before adding a review step, the better question is whether the reviewer gets the original source material again or only the prior step's output, since my reviewer's advantage here came specifically from re-reading the report, not from critiquing the executor's JSON in isolation.

Reproducibility and the honest gaps

Full script, task set, raw per-task output, and the chart above, all generated directly from this run: github.com/priyansh18/agent-handoff-loss-benchmark. Everything ran locally against Ollama, zero API keys, reproducible on any machine with the same model pulled (exact numbers may still shift slightly with different hardware or Ollama versions, since wall-clock time and token counts aren't hardware-independent). One real limitation: one deterministic run per condition, not a repeated-trial distribution, so a single flipped field would move the accuracy numbers by one unit out of 36 (2.8 percentage points) either way; I'm stating the result as what happened in this run, not as a tight confidence interval. A second limitation: the keyword-based grader rewards completeness over precision, which partly explains why three other tasks stayed wrong in both conditions (detailed in the repo's failure_examples/). I think it's fair for this task shape, but it's a judgment call, named here rather than left to make the numbers look cleaner than they are.

If you've built a planner-executor-reviewer pipeline yourself: did the planning step ever get checked for what actually survives the handoff, or did it get trusted the same way I almost trusted mine?

Resources

• LangGraph subgraphs and state-schema docs: docs.langchain.com/oss/python/langgraph/use-subgraphs
• Anthropic, "How we built our multi-agent research system": anthropic.com/engineering/multi-agent-research-system
• Tran and Kiela, "Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets," April 2026: arxiv.org/abs/2604.02460
• Full reproducibility package: github.com/priyansh18/agent-handoff-loss-benchmark, tasks.py and run_bench.py produced every number above, raw_results.jsonl has the full per-task output including every truncated focus_hint and the executor's intermediate answer, and failure_examples/ walks through each flipped and still-wrong task individually.

More from me: notes.priyanshsinghal.com has the roadmap these posts draw from, and I'm on LinkedIn at linkedin.com/in/priyanshsinghal.