Eighty-eight percent of AI agent pilots never reach production (IDC/Forrester, 2026). The usual explanation is governance. The more precise one, according to Microsoft's own open-source engineering framework, is simpler: the model can't tell the difference between investigating a problem and solving it.
Ask an AI coding agent for a function that reverses a string, and you get working code in seconds. Ask for a feature that touches twelve files across three services, and you get something that compiles, looks plausible, and quietly breaks conventions it never checked. Microsoft's hve-core project (a public, MIT-licensed framework for GitHub Copilot) names this directly: when you ask an agent to "build a feature," it generates plausible output fast. It doesn't stop to verify the pattern matches your codebase, or that the API it just called actually exists.
Their fix is a four-phase workflow called RPI: Research, Plan, Implement, Review. Here's what you'll get from this piece:
- What each phase actually restricts the agent from doing, and why that restriction is the point
- The real failure mode that breaks this system, and the specific fix documented for it
- A checklist for applying this to your own AI coding workflow, regardless of vendor
The Core Mechanism
RPI treats a coding task as a pipeline of type transformations: Uncertainty to Knowledge to Strategy to Working Code to Validated Code. Each arrow is a phase boundary, handled by a separate, specialized agent with its own instructions.
The insight worth sitting with: when an agent knows it cannot implement, it stops optimizing for "plausible code" and starts optimizing for "verified truth" (microsoft.github.io/hve-core/docs/rpi). The constraint doesn't just slow the agent down. It changes what the agent is trying to do.
The Four Phases
Task Researcher.
Investigates your codebase, external APIs, and documentation. Cannot write code. Produces verified findings with citations, not code, not opinions, not a plan.
Why it matters: remove the option to implement, and the agent stops filling gaps with confident guesses. It has to show its work instead.
Task Planner.
Turns research into an actionable plan: coordinated planning files with checkboxes, task breakdowns, and every task cross-referenced back to specific line numbers in the research.
Why it matters: this plan is what you actually review before any code exists. Every task traces backward, line by line, from plan to research. That's a real audit trail, not a vague ticket.
Task Implementor.
Executes the plan, following the patterns discovered during research.
Why it matters: by the time code gets written, the hard decisions are already made and documented. Implementation becomes close to mechanical, which is exactly what you want from the highest-risk phase.
Task Reviewer.
Validates the implementation against the original research and plan, and checks convention compliance.
Why it matters: it's not reviewing "is this good code" in the abstract. It's checking the code against specific commitments made two phases earlier.
The Real Failure Mode
The common failure isn't agents drifting into each other's roles mid-conversation. It's more mundane and more diagnosable: skipping the context reset between phases.
Run a full RPI cycle and your conversation balloons (100,000-plus tokens of code, file contents, and tool output). Ask for a second feature in the same session, and the agent skips research and planning entirely, jumping straight to writing code, because its own recent context now dominates with "implement and validate," not "start with research." The documented fix is blunt: clear context or start a new chat between every phase, and store findings in files, not chat history, so the next phase picks them up clean.
Beyond the four core phases, hve-core ships a fifth agent, task-challenger, whose job is to argue against the plan before implementation starts, an adversarial check most teams skip when they build their own version of this pattern. Security-specific validation (OWASP pattern checks folded into the review gate) is active work-in-progress in the project's own GitHub discussions as of this writing, not yet a finished feature.
Best Practices
- Clear context between every phase. Not optional. This is the documented cause of the framework's most common failure.
- Store phase outputs as files, not conversation history. The next agent should read a document, not scroll back through chat.
- Cross-reference every plan task to a specific research citation. If a task doesn't trace to evidence, it doesn't belong in the plan yet.
- Use RPI for genuinely uncertain work, not everything. Microsoft's own rule of thumb: if you need to understand something before implementing, use RPI. If you already know exactly what needs to change, it's overhead you don't need.
Tools and Resources
microsoft/hve-core(GitHub, MIT licensed). Install via VS Code extension or GitHub Copilot CLI plugin.- GitHub Copilot Chat. The interface RPI's agents run in.
.copilot-tracking/directory. Where the framework stores research and planning artifacts as files instead of chat history.
The Bottom Line
This isn't a smarter-model story. It's a narrower-agent story: block implementation during research, force every plan task to cite its evidence, and never let context accumulate silently across phase boundaries. Skip any one, and you get exactly the failure Microsoft's own docs describe: an agent that looks like it's following your process right up until it quietly isn't.
Read the source before you adopt anyone's repackaged version of it. It's public. There's no reason not to.
No comments yet