Our first article on the RPI framework covered the why: coding agents do their best work when you split a task into Research, Plan and Implement, and keep each phase's context clean. This one is the how. It is the working setup we use day to day with Claude Code subagents, including the parts that went wrong.
Nothing here is a benchmark. It is one small team running a monorepo of about a dozen products (helpdesk, MES, email hosting, a university AI assistant) with an AI coding agent doing a large share of the work. The failure stories are the useful part.
The short version
- Research runs in a subagent, never in the main conversation. It returns a summary or writes a file.
- Plan happens in the main conversation, in writing, before any code changes.
- Implement runs in one or more subagents, each with a narrow scope and clear ownership of files and tools.
- Verify against something that can't lie to you: a file on disk, a fresh page load, a length check. Never against the agent's own echo of what it did.
Why research belongs in a subagent
Research is the phase that eats context. Reading logs, grepping a codebase, pulling a Search Console export, paging through a mailbox: most of that output is looked at once and never needed again. If it lands in the main conversation, it stays there for every later turn, pushing the model out of what Dex Horthy calls the "smart zone" and into the "dumb zone", where it starts forgetting instructions and repeating mistakes.
Anthropic's subagent documentation states the goal plainly: "Preserve context by keeping exploration and implementation out of your main conversation." Each subagent gets its own context window and hands back only a summary.
In practice, our research subagents do two things differently from a quick question:
- They write their findings to a file. When we researched topics for this blog, the research agent wrote a structured topics file with sources and target queries, and returned a 200-word summary. The writers that came after read the file, not the summary.
- They are told what not to do. "Research only, no publishing, no browser" is part of the directive. A research agent that starts fixing things mid-investigation is how you end up with changes nobody planned.
One example of why the research phase matters: Search Console flagged 79 pages on our site as "alternate page with proper canonical tag." The easy move was to start tweaking canonical tags. Drilling into the example URLs first showed that none of them were on our site at all. They belonged to a forgotten subdomain pointing at a server we don't run. The fix was deleting one DNS record, not touching a single template. Research first saved a pointless code change.
Planning: the one phase that stays in the main conversation
The plan is where your judgement goes in, so it stays where you can see it. Our plans are short and concrete: which files change, what "done" looks like, what is explicitly out of scope, and how the result will be checked.
The most useful habit has been writing each subagent's directive as if for a capable colleague who just walked in: what to do, what not to touch, what to report and in how many words. Directives that say "fix the bug based on your findings" push the thinking onto the subagent, and the results show it. Directives that name the file, the function and the check come back right far more often.
Implementation: parallel agents need ownership rules
Running several implementation agents at once is where the time savings are. It is also where most of our incidents happened. Three rules came out of them.
1. One agent owns each shared resource
We drive a real browser over a remote debugging port for tasks that have no API: Reddit, a Telegram chat, the Search Console UI. Two agents driving the same browser at once means tabs switching under each other and actions landing on the wrong page. So every directive now states it: "You are the only agent allowed to drive the browser," or "No browser, another agent owns it." The same applies to a mailbox, a database migration, or a deploy.
We also learned that "the browser" is not always one thing. At one point the browser tool the agent had been using was connected to a different, isolated browser instance than the one on the debugging port. It was getting blocked by a site while the real browser was not. Checking the target list directly (curl localhost:9222/json) and connecting to it explicitly fixed it.
2. Commit fast, and never trust an uncommitted worktree
When several sessions share a repository, uncommitted work is fragile. We lost edits once when another session ran git reset --hard in the same working tree. The rule since then: small commits, pushed immediately, and git add by explicit path so an agent never sweeps up someone else's half-finished changes.
The opposite problem showed up this month. Our production site had been built from a working tree that contained files nobody had ever committed. Tracked code imported them, so the site built fine on that one machine. When the site moved to a new server, a clean checkout of main failed to build. The fix was committing the missing files and proving it with a build from a fresh worktree. "It builds here" is not the same as "it builds."
3. Scope each agent to the smallest thing that can be checked
"Update the SEO titles" is too loose. "Change only meta_title and meta_description on these three documents, preserve every other field, then curl the live page and confirm the new title" is the kind of task an agent finishes correctly. When we once let an agent update whole documents, it dropped the Arabic translations on the way; the narrower instruction would have prevented it.
Verification: check the world, not the transcript
This is the lesson that cost the most. An agent reporting "done" means the agent believes it is done. Tool output shown back to the model is not always the ground truth either.
Tool output can be quietly wrong
In long sessions we saw displayed tool results with words silently dropped. The underlying data was fine; the text the model saw was not. Twice that nearly led to a wrong conclusion, including a false diagnosis that a website was corrupting form input. The fix is boring: write results to a file and read the file, or compare a length or checksum instead of eyeballing text. Before we publish a post through a web form now, the agent checks that the field's character count matches the source exactly.
"The button was clicked" is not "the message was sent"
Our worst incident was in a Telegram web chat with a real business contact. The agent inserted text into the message box with a DOM editing command. The text showed on screen, but the app's internal draft state never updated. Every send attempt read stale, partial state, and repeated retries sent seven garbled fragments to the other person before anyone noticed. We deleted them through the app's own API and sent one clean message.
Two changes came out of it. Input now goes through real input events that the app actually listens to. And after sending, the agent reads the message back from the app's own data store and compares it to the intended text before reporting success. A green checkmark in the UI is not evidence.
Verify from where the user stands
After a deploy, check the live URL from outside, not the container you just restarted. We deployed an SEO fix, confirmed it on our server, and only later noticed that the domain's DNS now pointed to a different host still serving the old build. Checking both, with curl --resolve for the origin and a plain request for what the public sees, would have caught it straight away.
A directive template that works for us
Task: one sentence.
Scope: the exact files, records or pages. What is out of scope.
Ownership: which shared resources you may use (browser, mailbox, deploy).
Rules: no bypassing bot checks, no paid actions, commit by path only.
Verify: the specific check that proves it worked.
Report: under N words, with commit hashes and anything that needs a human.It looks like overhead. In practice it is the difference between one pass and three.
What we would tell a team starting with RPI and subagents
- Put research in subagents first. It is the cheapest win and the lowest risk.
- Keep the plan in the main conversation and keep it written down.
- Add parallel implementation only when you have ownership rules for shared resources.
- Make every agent prove its result against the real system. Trust the file, the fresh page load and the checksum, not the summary.
For the reasoning behind the three phases, see part one. For a broader view of the discipline, Sourcegraph's practical guide to context engineering is a good companion read.
AI helped draft this write-up; the workflow, the incidents and the fixes are our own.
