Research, Plan, Implement

If the last part established anything, it is that the enemy of a long agent task is the long agent session — one window slowly accumulating file reads, dead ends and corrections until it is doing its most important work in its least capable state. The obvious countermeasure is structural: stop treating a task as one conversation. Break it into phases, give each phase a fresh window, and pass between them only a small, deliberate artefact. That structure has a name, and credit for it belongs squarely with Dex Horthy and the HumanLayer team, whose Advanced Context Engineering for Coding Agents work formalised Research, Plan, Implement — RPI — around the practice they call frequent intentional compaction. They report using the approach on a Rust codebase of roughly 300,000 lines, which is worth knowing before you dismiss the ceremony as something only demo projects can afford; take the figure as their report of their own practice.

What follows is RPI as I run it, in my own words — the phases, the artefacts, and the honest accounting of what it costs.

Research - find out what is true

The first phase produces no code and proposes no changes. Its single output is a document that records what is actually true about the system, as it stands today, in the parts that matter for this task.

That framing carries two disciplines. Actually true means the findings come from the code itself — files read, call paths traced, behaviour confirmed — not from documentation that part 6 taught us to distrust. The parts that matter means the document is scoped by the task, not by curiosity; a research document that tries to describe the whole system is just documentation with a new filename, and it will rot the same way.

Mechanically, this is where the isolation pillar earns its keep. The reading is delegated to sub-agents: one traces how requests reach the module in question, another maps which tests cover it, a third hunts for existing utilities the change should reuse. Each fills its own disposable window with the mess of searching and returns a few paragraphs of findings. The parent assembles them into the research document — typically a page or two of facts, each anchored to a file path and often a line number, plus an explicit list of what was not investigated. The dead ends die with the sub-agent windows. What survives is small, dense and checkable.

Checkable matters, because this is the cheapest place in the whole workflow to be wrong. A misreading that costs one correcting sentence here becomes a misdesigned plan in the next phase and a broken implementation in the one after. I read research documents the way I read a junior engineer's investigation notes: verify the two or three claims everything else hangs on, and push back on any finding that lacks a file path.

Plan - decide what will change

The second phase starts from a fresh window seeded with the research document, and produces the plan: an ordered list of concrete steps that, executed in sequence, complete the task.

Concrete is the whole game. A useful plan step names the file it touches, describes the exact change — often down to the snippet — and states how to verify that step before moving to the next. “Improve error handling in the importer” is not a plan step; it is a wish. A plan step looks more like this:

## Step 3 - stop swallowing parse failures

- File: src/Importer/StatementParser.cs
- Change: in `ParseRow`, replace the bare `catch` that returns null
  with a catch that records the row number and raw line into
  `ImportDiagnostics`, then rethrows `StatementFormatException`.
- Verify: run `dotnet test --filter StatementParserTests`;
  the two new tests from step 2 go green, nothing else changes.

The bar I hold a plan to is deliberately unflattering: a plan is ready when a much weaker model — or a distracted human — could execute it without making a single design decision. Every judgement call the implementer would face is a decision the plan failed to make. Pushing those decisions left, into the phase with the cleanest context and the most human attention, is the entire point of the structure.

The plan is also where human review buys the most for the least. Reviewing a finished thousand-line diff is slow, and rejecting it wastes everything. Reviewing a one-page plan takes minutes, and correcting it costs nothing but an edit. I spend my attention there deliberately, because it is the last point where the task is still cheap to steer.

Implement - execute, small and cold

The third phase is intentionally the least interesting. A fresh window, seeded with the plan — and usually not even the research document, because the plan should have absorbed whatever it needed. The agent executes step by step, verifying as each step's instructions dictate, keeping the window small because the thinking has already been done.

Two rules keep this phase honest. First, deviations are signals, not improvisations. When reality disagrees with the plan — a file is not where the research said, a test fails for an unexpected reason — the wrong move is for the agent to quietly adapt, because a plan that is being silently reinterpreted is no longer the thing that was reviewed. Small surprises get recorded; structural surprises stop the phase and send the task back a step, with the compaction artefact carrying forward what was learned. Going back is not failure. It is the workflow doing precisely what it was designed for: putting the new decision in front of clean context instead of patching it into a hot window.

Second, each phase boundary is a real reset, not a ceremonial one. The temptation, mid-implementation, is to keep the warm window and just “quickly research” the surprise in place. Do that twice and you have reinvented the one long degrading session the workflow exists to prevent.

The ceremony must fit the task

Run full RPI on a one-line fix and you will rightly conclude the workflow is bureaucracy. The complexity-scaling idea — present in HumanLayer's material and obvious within a week of practising this — is that the phases are a dial, not a doctrine.

Changing a button colour: just talk to the agent; any plan would be longer than the diff. A small, well-understood feature: skip research, sketch a five-line plan, implement. A change that crosses module boundaries: research first, because the crossing is exactly where assumptions fail, then plan, then implement. A deep change in a large or unfamiliar codebase: the full structure, sometimes with several research rounds before the plan stabilises. The dial setting is a judgement about risk — how expensive is a wrong assumption — not about effort for its own sake.

My honest ledger after living with the workflow: the overhead is real, and it is front-loaded in exactly the way impatience hates; on genuinely trivial work I skip it without guilt. Plans built on shallow research produce the confident, precise, wrong steps that are more dangerous than vagueness. And the discipline decays quietly — every shortcut feels justified in the moment, and the cost only reappears three hours later, in the dumb zone. The workflow is cheap insurance priced in patience, and the premium is only worth paying when the downside is expensive.

Everything above, though, assumes the agent wakes up already knowing your conventions, your build commands, your constraints — the standing knowledge no per-task research should have to rediscover. That standing layer is its own discipline with its own name. Next, harness engineering in three levels.