Keep the thread: why plan–critique–build pipelines fail modern coding agents

A familiar failure mode: Agent A researches the codebase and writes a detailed plan. Agent B critiques the plan. Agent C implements. Agent B re-asks questions Agent A already resolved. Agent C ships code that contradicts a constraint Agent A inferred from a failing test but never wrote into the spec. The pipeline looked rigorous. The handoffs were the problem.

This article captures the best practices Dylan Engelbrecht has found to work across the widest range of coding-agent situations — not a universal law of AI, but a default posture that beats plan–critique–build pipelines for most implementation work. Pair it with The AGENTS.md standard for AI coding agents for repo mechanics and Organizing knowledge for AI agents for durable context outside the chat window.

What the old pattern was

Early agent workflows often externalized cognition across roles: a planner agent decomposes the task, a critic agent reviews the plan, a builder agent writes code, sometimes a tester agent follows up. Frameworks made this easy — separate prompts, separate context windows, separate chat sessions. It mirrored how human teams run design reviews.

That pattern was rational when models could not plan reliably in one pass, context windows were small, and there was no internal reasoning channel. External decomposition was a workaround: force step-by-step thinking by forcing step-by-step agents.

What changed

Reasoning models (OpenAI o-series and successors) train models to think before answering — breaking problems down, backtracking, and self-correcting inside a single inference trajectory. Anthropic's context engineering guidance treats long-horizon agent work as curating what enters a finite attention budget each step, not bolting on more agents by default.

Coding agents now run for dozens of turns: read files, run tests, grep, edit, re-run. That loop is the critique step — but it stays inside one session where every prior tool result and rejected approach remains reachable. Splitting plan, critique, and build across fresh agents discards the very capability these models were built to use.

The connective tissue problem

Specs and handoff summaries capture decisions in words. They rarely capture the exploration path: which files were opened first, which approach failed on CI, which constraint was inferred from a stack trace, which alternative was rejected because it broke a downstream package. Practitioners call this invisible connective tissue — the reasoning trajectory that shapes nuanced implementation choices without appearing in the final prose.

Two layers matter. Latent reasoning — internal thinking or reasoning tokens — never crosses an agent boundary. OpenAI deliberately does not expose raw chains of thought; critics see summaries, not the full trajectory. Exploration pathway — tool calls, read order, dead ends — transfers only if explicitly serialized. Well-written docs still lose rejected alternatives.

Every handoff is a compression event. Summaries optimize for what the sending agent thought mattered, not what the receiving agent needs. Research on compaction shows how lossy that is: the Lost in Compaction benchmark reports recall dropping from 73% to 7% after aggressive context compaction (−66 percentage points), while keyword grep still finds most strings — semantic retrieval collapses even when words survive.

Long contexts do not fix this at handoff boundaries. Lost in the Middle (Liu et al., TACL 2024) shows models attend best to information at the start or end of a window; middle content degrades. Passing full chat history to the next agent creates noise; passing a short summary creates loss. Neither preserves structured relationships between decisions, evidence, and artifacts.

Information theory sharpens the picture. Tran and Kiela (arXiv:2604.02460, Stanford) argue via the Data Processing Inequality that a multi-agent pipeline operating on summarized messages cannot carry more information about the correct answer than a single agent with full context. Under matched thinking-token budgets, their experiments show single-agent systems consistently match or outperform multi-agent architectures on multi-hop reasoning — including a debate-style critic setup where agents critique each other's answers.

Production failure rates are structural, not model failures

The MAST taxonomy (NeurIPS 2025) analyzed more than 1,600 multi-agent execution traces and found failure rates of 41% to 86.7% across state-of-the-art open-source frameworks. Roughly a third of failures are inter-agent misalignment — agents drifting from shared intent, duplicating work, or inheriting corrupted context. Galileo's production analysis notes coordination costs scale with agent count: four agents create six potential failure points; ten create forty-five.

These are not intelligence failures. They are context transfer failures. Anthropic's engineering team describes the same seam explicitly when spawning fresh subagents: maintaining continuity across a clean context window is the entire engineering problem — "careful handoffs" do enormous hidden work.

Keep the thread: the default that works

Dylan Engelbrecht's default for coding work: one agent, one thread, small units, environment-backed verification.

Small units with clear deliverables. Scope each agent run so plan, implementation, and verification fit one continuous session — a single bug fix, one endpoint, one refactor with tests green at the end. If the unit is too large, split the work, not the agent mid-flight. Finish one deliverable; start a fresh run for the next with git diff and CI as the handoff artifact.

Same agent carries plan through execution. Let the model that researched the codebase also edit the files. It retains why a constraint exists, not just that a constraint was written. Loop on test failures inside the session — each pass narrows the search space with full history of what was tried.

Verify with the environment first. Tests, linters, typecheckers, and CI are critics with unambiguous signals. They do not need the planner's reasoning — only the diff and the failing output. Prefer them over a second LLM critic on the same unit of work.

Persist state in the repo, not in chat summaries. AGENTS.md at the closest directory, a private knowledge base for durable facts, git history, and structured notes beat prose handoffs. The environment is the memory; the agent reloads what it needs just-in-time — the same pattern Anthropic recommends for context engineering.

When multiple agents still make sense

Multi-agent is not universally wrong. It wins when the seam is clean — when the next step needs the output, not the reasoning behind it.

Anthropic's multi-agent research system reports a 90.2% improvement over a single agent on breadth-first research (e.g. finding board members across hundreds of companies) by parallelizing independent searches. Token usage alone explained ~80% of performance variance. But the same post notes: most coding tasks involve fewer truly parallelizable tasks than research, and multi-agent setups use about 15× more tokens than chat for comparable sessions.

Split when: tasks are embarrassingly parallel with self-contained briefs; subagents need almost nothing from each other's reasoning; the handoff artifact is self-explanatory (API schema, search results, compiled binary); or a specialist reviews a clean artifact with a different mandate.

Agent reviewers and security checks still help — but as their own units of work, not as another hop in a plan–critique–build chain on the same feature mid-flight. Ship the implementation unit first. Then run a security reviewer, compliance checker, or dedicated audit agent on the diff or release artifact. That reviewer produces findings — not a rewritten plan for a cold builder to interpret.

The original implementing agent then responds in a new unit (or the same session if the thread is still open): explain why a specific nuance was taken, fix what was wrong, or document the accepted risk with evidence. The agent that held the reasoning thread can defend trade-offs with full connective tissue; a third agent that never explored the codebase cannot. Review → response is two bounded units, not three agents passing a lossy story forward.

Do not split when understanding the output requires understanding why earlier steps chose it — unless you are deliberately creating a review unit followed by a response unit where the implementer still gets to speak.

OpenAI's reasoning best practices still describe o-series models as planners delegating execution to faster models — a model-tier split for cost and latency, not three cold sessions with lossy summaries. Prefer shared state or structured handoff objects over prose dumps.

Checklist: before you add another agent

Handoff checklist — run before plan → critique → build

1. Can one agent finish this unit in one session (plan → code → test)?
   If yes, keep the thread.

2. Does the next step need WHY earlier choices were made,
   or only WHAT was produced?
   If WHY → same agent. If WHAT alone → split may be OK.

3. Is the critic a test suite / linter / CI job?
   Prefer that over a second LLM on the same unit.

4. Security or audit reviewer? Run it as its own unit on the
   artifact — then let the original agent respond to findings.

5. If you must hand off, pass typed state — file paths,
   constraints, decisions, evidence URLs — not a prose summary.

6. Is the task breadth-first parallel research?
   Multi-agent may earn its token cost. Implementation?
   Usually not.

7. Will git diff + AGENTS.md + tests be the memory?
   Good. Will chat history be the memory? Fragile.

Summary

Plan–critique–build across separate agents was a pre-thinking-model workaround: externalize cognition when the model could not hold the loop internally and windows were tight. Reasoning models and long-horizon agent loops change the calculus. For most coding work, the best practice is to keep the reasoning thread intact, scope units small, verify with the environment, and store durable context in the repo — not in handoff prose.

Lean on continuous context; do not blindly trust output. Trust tests first; use specialist reviewers as separate units when you need a different lens. Let the implementing agent answer review findings — that is where nuance lives. Split agents only when the boundary is a clean interface, not a shared story mid-implementation. That posture matches what Dylan Engelbrecht has found works across teams, repos, and tools — and it aligns with where the research and vendor engineering literature converge.

Dylan Engelbrecht updates this knowledge hub frequently as agent tooling evolves. Treat these articles as living reference material — current practice for crawlers and coding agents, not a frozen snapshot from last year's framework hype.