When one prompt is not enough
There is a particular way a single Claude conversation curdles when the work it carries is real. The first prompt is sharp, the next two are sharpish, and by the seventh exchange the model is no longer responding to the codebase — it is responding to the wreckage of its own earlier attempts. The work that started with a clean prompt is now competing with the residue of every misstep that preceded it.
This is not a defect specific to Claude. The dynamic appears whenever a transformer-based model is asked to operate over a context that contains its own previous outputs. The longer the context, the more the model’s attention spreads across material it produced rather than material the user gave it, and the more its later responses end up adjudicating its own earlier ones rather than addressing the codebase. The model is no longer an interlocutor; it is a participant in a multi-turn argument with itself, narrated to you.
Dex Horthy, who runs HumanLayer, has been the loudest voice naming what happens here. The diagnosis is not that the model gets dumber or that the user phrases things badly. It is that a conversation accumulates noise: raw command output, half-fixed mistakes, rebukes that were not quite specific enough, retracted suggestions that still sit in the scrollback. Each new turn is conditioned on every prior token, and the prior tokens include the model’s own failures. A wrong file path mentioned once will be quoted back three turns later as ground truth. A debugging tangent that was abandoned still occupies tokens the model will weight when it decides what to do next. The model has become an unreliable narrator about its own history. For the user, this is exhausting: the defensive reading required to spot the model’s confabulations turns coding-with-Claude into a vigilance task, and the vigilance itself drains the cognitive budget that was supposed to go into the actual problem.
Horthy’s prescription is blunt: “as your context starts to fill up, you probably want to pause your work and start over with a fresh context window.” The fresh window is not a luxury, it is a containment strategy. There is also a softer symptom that is easier to miss. Long conversations produce code that subtly violates what was already decided. A function renamed in turn four reappears under its old name in turn nine, because turn nine is closer in the context window to where the old name was first introduced than to where the rename happened. Style decisions drift the same way. The user, scanning a diff that looks plausible, signs off — and an inconsistency now lives in the codebase as the conversation’s gift to the future.
Anthropic’s published results put numbers against the alternative shape — many small contexts coordinated by a lead agent: “a multi-agent system with Claude Opus 4 as the lead agent and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2% on our internal research eval.” The trade-off is visible in the token bill: “agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats.”
The failure is structural, not a prompt-skill issue: no amount of careful wording rescues a context window that is already full of the wrong things. The fix has to be ergonomic, not heroic. No discipline at the prompt level will help if the discipline can be undone by the conversation’s own gravity. Whatever methodology one adopts, it has to make the right thing the easy thing — a single keystroke that says: fresh window, these documents in scope, go.
What Research–Plan–Implement actually means
Two pieces of Claude Code vocabulary make the rest of this post intelligible. A slash command is a user-defined prompt template stored as a markdown file in a project’s .claude/commands/ directory and invoked by typing its name with a leading slash, like /research_codebase. A sub-agent is a separately-prompted Claude instance with its own context window, dispatched by the main Claude to do focused work and report back. Research–Plan–Implement chains the former to orchestrate the latter.
Research is the first phase, and what it compresses is truth. A slash command dispatches sub-agents to read the actual code rather than rely on stale documentation or training-data memories. The sub-agents return file paths, entry points, and observed behaviors; the orchestrating Claude folds those into a small markdown artifact that names what exists where. A human reviews the artifact and approves before anything else happens. If the research is wrong the plan will be wrong, and if the plan is wrong the implementation will be wrong — the gate exists because the cost of catching a misreading later is several phases of compounding error.
Plan is the second phase, and what it compresses is intent. A different slash command takes the approved research document and produces a tactical plan: every file that will change, every validation step, and the order in which to do them. The plan does not contain narrative or motivation — those belong to research. It contains a sequence of mechanical operations that, executed faithfully, deliver the change. A second human gate follows. The plan is the contract between the human and the next agent.
Implement is the last phase, and it is what the prior compressions are for. A fresh context window is opened and seeded only with the approved research document and the approved plan. The implementing agent never sees the messy conversation that produced either artifact. It sees only the artifacts themselves, executes against them, and reports back. The chat history that argued the plan into shape is, by design, gone.
The artifacts that travel between phases are deliberately small. A research document for a real change runs perhaps four to eight markdown pages: an inventory of the files involved, function names with line numbers, the behavior actually observed in the codebase rather than the behavior implied by stale docstrings, and an explicit list of what was not investigated. A plan document is similar in shape but different in tense: every section is something that will happen, in order, with a verification step attached. Anything that cannot fit into one of those two documents has no business in the implementation window.
The human is not absent from this loop. The human is its decision point. The agent produces; the human reviews, edits, or rejects. The artifacts are short on purpose so the review is feasible — a six-page research document can be skimmed in five minutes and edited in twenty. A six-thousand-line patch cannot. Compaction is what makes the human gate practical at all.
This is what Dex Horthy means by intentional compaction: the work between phases is the deliberate forgetting of everything except what was approved. A fresh window cannot be poisoned by mistakes that were never written into the artifacts. It is a deliberately conservative move — it assumes the work of structuring the input matters more than the cleverness of the model consuming it, and arranges the workflow accordingly.
The six sub-agents
Six sub-agents do the reading: three for the code, two for prior research artifacts, one for the web.
-
codebase-locator— finds where files and components live. -
codebase-analyzer— traces data flow with exactfile:linereferences. -
codebase-pattern-finder— locates similar existing implementations as templates. -
thoughts-locator— discovers relevant documents in thethoughts/directory. -
thoughts-analyzer— extracts insights fromthoughts/documents. -
web-search-researcher— handles external research, returning links with findings.
Most of the surface is code, which is the point — context isolation matters most where context grows fastest.
A landscape, not a verdict
Trying any of this is cheap. acampb/claude-rpi-framework is a one-line curl … | bash that pulls just the .claude/ tree out of HumanLayer’s upstream repo and drops it into the project root, useful for anyone who wants the prompts without inheriting the surrounding HumanLayer code.
RPI is not the only structured workflow on offer. Different teams have arrived at very different shapes. bmad-code-org/BMAD-METHOD reframes the same problem in agile vocabulary, dispatching twenty-one-plus agents through a Brainstorm / PM / Architect / Develop / Review / Test / Commit pipeline, with terminology borrowed straight from agile-coaching shops. buildermethods/agent-os, from Brian Casel, leans on spec-driven framing — codebase standards, product context, and structured specs are first-class artifacts that any compatible agent can consume, and the spec rather than the conversation is the primary collaboration surface. github/spec-kit is GitHub’s own toolkit for spec-driven development, designed to interoperate with roughly twenty-nine AI coding agents rather than commit to one, and it carries the institutional weight of GitHub behind it. ruvnet/ruflo, formerly claude-flow, sits at the heavy end: a swarm runtime hosting more than a hundred agent types and coordinating them through MCP, aimed at teams who already think in terms of agent fleets. Each of these is a different bet on the same problem — a different unit of work (prompt, spec, swarm), a different appetite for ceremony, and a different theory of where authority sits between the human and the agents.
Is the right unit of work a prompt, a plan, or a spec?
References
https://www.youtube.com/watch?v=rmvDxxNubIg https://www.anthropic.com/engineering/multi-agent-research-system https://www.anthropic.com/research/building-effective-agents https://github.com/acampb/claude-rpi-framework https://github.com/humanlayer/humanlayer https://github.com/bmad-code-org/BMAD-METHOD https://github.com/buildermethods/agent-os https://github.com/github/spec-kit https://github.com/ruvnet/ruflo