Research, Plan, Implement

Research, Plan, Implement separates understanding from decision-making from execution, so each phase produces a reviewable artifact before the next begins.

Also known as: RPI, Three-Phase Workflow

Understand This First

• Plan Mode – RPI extends plan mode by splitting its exploration phase into two distinct gates.
• Specification – the plan phase produces a specification-grade artifact.
• Checkpoint – each phase boundary is a checkpoint where work pauses for review.

Context

At the agentic level, Research, Plan, Implement is a workflow discipline for tasks where the cost of a wrong approach exceeds the cost of thoroughness. It applies when you’re directing an agent to make changes in an unfamiliar codebase, a complex system, or any situation where acting on incomplete understanding could send the agent down an expensive wrong path.

Plan Mode solves the problem of agents acting before thinking. But plan mode lets the agent mix observation with opinion in a single pass. The agent reads files and simultaneously proposes what to change. A human reviewing the plan sees the agent’s conclusion but not the understanding behind it. If the agent misidentified a dependency or hallucinated an API, that mistake is baked into the plan and harder to catch.

Research, Plan, Implement adds a gate before planning begins.

Problem

How do you catch an agent’s misunderstandings before they get cemented into a plan?

When an agent explores a codebase and proposes changes in one pass, its architectural assumptions travel silently inside the proposal. The agent “discovers” what exists and decides what to change in the same breath. A reviewer who sees “I’ll modify the payment service to add validation” has no way to check whether the agent found the right payment service, noticed the validation that already exists in the middleware, or missed the downstream consumer that depends on the current behavior. The misunderstanding and the plan arrive as a package.

Forces

• Observation mixed with opinion makes mistakes invisible. You can’t review what you can’t see.
• Fresh context per phase prevents earlier assumptions from contaminating later reasoning.
• Three phases cost more than two. Each gate adds time and demands human attention.
• Agents are confident narrators. A plan built on a wrong mental model reads just as convincingly as one built on a right one.

Solution

Split every non-trivial task into three phases, each producing a durable artifact that the next phase consumes:

Phase 1: Research. The agent surveys the codebase and documents what it finds. No opinions, no suggestions, no proposed changes. The output is a research document: which files exist, what they do, how they connect, what tests cover them, and what assumptions the agent is making about the code’s behavior. This document is the agent’s understanding, laid bare for review.

Phase 2: Plan. Using the approved research artifact as input, the agent designs the change. The plan includes explicit tasks, scope boundaries, success criteria, and identified risks. It references the research findings to justify its decisions. The human reviews the plan against the research: does the proposed approach account for what the agent found? The plan should be concrete enough to execute mechanically.

Phase 3: Implement. The agent executes against the approved plan, verifying each step through the Verification Loop. Deviations from the plan are flagged, not silently absorbed. If the agent discovers something the research missed, it stops and reports rather than improvising.

Each phase ideally uses a fresh context window. The research artifact and plan document serve as the durable handoff between phases, replacing the fragile in-context memory that degrades over long conversations.

How It Plays Out

A team needs to migrate their authentication system from session-based to JWT tokens. The developer directs the agent to research first. The agent reads 14 files across four directories and produces a research document: the session middleware lives in src/auth/session.ts, three route handlers check req.session directly instead of going through the middleware, the test suite has 23 tests that create fake sessions, and there’s an undocumented admin endpoint that uses a different session store. The developer reviews the research and spots that the agent missed the WebSocket authentication in src/ws/auth.ts. They add it to the research document and approve.

In the plan phase, the agent proposes a migration path: replace the session middleware with a JWT verification layer, update the three direct req.session callers, migrate the admin endpoint’s separate session store, add JWT validation to the WebSocket layer, and update all 23 test fixtures. Each task has a success criterion. The developer approves with one modification: the admin endpoint migration should happen in a separate PR.

The agent implements the approved plan, running tests after each task. When it reaches the WebSocket layer, it discovers that the auth check depends on a session event listener it hadn’t documented. It stops, reports the finding, and waits for the plan to be updated rather than guessing.

A solo developer working on a smaller change (adding a caching layer to an API endpoint) decides the full three-phase ceremony isn’t worth it. They use Plan Mode instead: one pass of exploration and planning, then execution. RPI is for tasks where the research itself needs to be reviewed as a standalone artifact. Not every task qualifies.

Consequences

The research gate catches misunderstandings at their cheapest point. Correcting an agent’s understanding of the codebase costs a sentence in a review comment. Correcting a plan built on wrong understanding costs rethinking the approach. Correcting an implementation built on a wrong plan costs reverting code.

The three-phase structure produces an audit trail. Months later, someone reading the research document and plan can reconstruct not just what changed but why, what was considered, and what was explicitly excluded. This connects to Architecture Decision Record thinking: the plan document is a lightweight decision record.

The cost is real. Three phases mean three review points. For a task that takes an agent 20 minutes to execute, the research and planning phases might add 30 minutes of agent work and 15 minutes of human review. This overhead pays for itself on tasks where a wrong approach would cost hours of rework. It’s wasteful on tasks where the codebase is well understood and the change is small. Learning when to use RPI versus plain plan mode versus just letting the agent work is part of developing fluency with agentic workflows.

Fresh context per phase prevents the agent from anchoring on early assumptions, but it also means the agent loses conversational nuance. Insights that surfaced during research but didn’t make it into the written document are gone. The quality of each phase depends on the quality of the artifact that preceded it.

Related Patterns

• Refines: Plan Mode – RPI adds the research-only gate before planning begins.
• Uses: Specification – the plan phase produces a specification-grade artifact.
• Uses: Design Doc – the plan artifact often takes the form of a design document.
• Uses: Checkpoint – each phase boundary is a checkpoint where work pauses for review.
• Uses: Verification Loop – the implement phase relies on verification to confirm each step.
• Uses: Context Engineering – each phase’s artifact is a context engineering tool for the next phase.
• Complements: Steering Loop – the steering loop decides whether to continue; RPI structures how each unit of work proceeds.
• Enables: Human in the Loop – each phase boundary is a natural human review point.
• Contrasts with: Vibe Coding – vibe coding collapses all phases into one; RPI enforces their separation.
• Informed by: Externalized State – the research and plan documents are externalized state that survives context window boundaries.

Sources

Kilo.ai documented the Research, Plan, Implement workflow as the “RPI” pattern, describing a strict three-phase discipline where each phase produces a durable artifact consumed by the next. Similar three-phase separations appear independently in practitioner workflows across multiple agentic coding tools. The pattern builds on Martin Fowler’s distinction between exploration and execution in agent workflows, and on Addy Osmani’s O’Reilly Radar series on specification-driven development, which found that effective agentic teams spend the majority of their effort on problem definition and context preparation, with execution as the smaller fraction.