# Strict RPI vs rpi-agent in HVE Core: Architectural Differences and Usage Guide > Understand strict RPI vs rpi-agent in HVE Core. Learn how strict RPI uses isolated steps while rpi-agent automates the workflow for seamless execution. - Repository: [Microsoft/hve-core](https://github.com/microsoft/hve-core) - Tags: architecture - Published: 2026-03-09 --- **Strict RPI executes research, planning, implementation, and review as isolated steps requiring manual context clearing between phases, while rpi-agent automates the entire workflow as a single continuous conversation using sub-agent delegation.** Microsoft's HVE Core repository provides two distinct approaches to executing the Research-Plan-Implement-Review (RPI) workflow. Understanding the difference between strict RPI and rpi-agent is essential for selecting the appropriate method based on your compliance requirements, research depth needs, and tool availability. Both approaches ultimately leverage the same underlying task agents but differ fundamentally in context management, user interaction patterns, and audit trail generation. ## How Strict RPI Manages Workflow Isolation Strict RPI enforces **manual phase boundaries** by requiring users to invoke four separate task agents in sequence. Each phase runs as a distinct step with explicit context isolation. ### Agent Composition and Phase Separation In strict RPI mode, you interact directly with four discrete agents: - `task-researcher` – Performs deep, verified research with citations - `task-planner` – Creates implementation plans based on research artifacts - `task-implementor` – Executes the planned implementation - `task-reviewer` – Validates the implementation against requirements The critical enforcement mechanism is the **`/clear`** command. According to the workflow documentation in [`docs/rpi/why-rpi.md`](https://github.com/microsoft/hve-core/blob/main/docs/rpi/why-rpi.md), you must clear the chat between phases to guarantee a fresh context for every step. This eliminates token contamination between research, planning, implementation, and review. ### Context Management in Strict Mode Strict RPI eliminates **context contamination** by design. When you execute `/clear` between phases, earlier tokens cannot bias later steps. This produces deep, verified research because the Researcher runs in isolation, allowing scrutiny of the generated document before proceeding. ## How rpi-agent Automates Phase Transitions The **`rpi-agent`** operates as a single autonomous orchestrator that automates hand-offs between phases using sub-agent calls. ### Sub-Agent Delegation Architecture Located in [`.github/agents/hve-core/rpi-agent.agent.md`](https://github.com/microsoft/hve-core/blob/main/.github/agents/hve-core/rpi-agent.agent.md), the rpi-agent definition specifies that this mode uses the `runSubagent` (or `task`) tool to delegate work to the underlying task agents. Rather than manually invoking each agent, the rpi-agent: 1. Runs all five phases (Research → Plan → Implement → Review → Discover) in a **single conversation** 2. Automatically carries context forward between phases 3. Manages the sub-agent invocation protocol internally ### Context Accumulation and Token Budget Unlike strict RPI, rpi-agent maintains **shared context** across all phases. While this enables faster execution for straightforward tasks, it introduces potential recency bias in later phases as the conversation accumulates tokens. Research depth is moderate and inline, with citations embedded within the continuous session rather than isolated in discrete artifacts. ## Workflow Comparison: Key Differences Understanding the operational distinctions helps determine which approach fits your current task. **Agents Involved** - **Strict RPI**: Requires manual invocation of four distinct agents: `task-researcher`, `task-planner`, `task-implementor`, and `task-reviewer`. - **rpi-agent**: Uses a single `rpi-agent` orchestrator that delegates to the four task agents as sub-agents via the `runSubagent` tool. **Phase Separation** - **Strict RPI**: Enforced by the user through `/clear` commands between phases, guaranteeing fresh context for every step. - **rpi-agent**: All five phases (Research → Plan → Implement → Review → Discover) run in a single conversation with automatic hand-offs. **Context Management** - **Strict RPI**: Eliminates context contamination—each phase starts with a clean slate, preventing earlier tokens from biasing later steps. - **rpi-agent**: Accumulates context across the entire session, which can cause recency bias in later phases. **Research Depth** - **Strict RPI**: Produces deep, verified, cited research because the Researcher runs in isolation with dedicated token budgets. - **rpi-agent**: Provides moderate, inline research; citations may be embedded but share the session's unified token budget. **Audit Trail** - **Strict RPI**: Generates complete artifacts for each phase stored under `.copilot-tracking/` (research documents, plans, implementation logs, review logs). - **rpi-agent**: Creates summary-only artifacts by default; detailed logs exist but remain internal to the sub-agent calls. **Tool Requirements** - **Strict RPI**: Requires only basic Copilot chat functions. - **rpi-agent**: Requires the `runSubagent` (or `task`) tool to be enabled. **When to Use** - **Strict RPI**: Complex, unfamiliar, or compliance-heavy work requiring thorough investigation and permanent records. - **rpi-agent**: Straightforward features, quick bug-fixes, or prototyping where speed outweighs deep investigation. ## How to Invoke Each Mode ### Manual Strict RPI Execution Execute each phase separately, clearing context between steps: ```text # Phase 1: Research /task-researcher analyze authentication vulnerabilities in JWT libraries # Review the generated research document, then clear chat /clear # Phase 2: Planning /task-planner create secure implementation plan based on research findings /clear # Phase 3: Implementation /task-implementor implement the JWT validation module per the approved plan /clear # Phase 4: Review /task-reviewer verify implementation against security requirements ``` Each isolation boundary ensures that planning tokens do not influence research objectivity, and implementation details do not bias review criteria. ### Automated rpi-agent Execution Select the agent from the Copilot Agent picker or type: ```text /rpi-agent ``` For step-by-step progression within the automated workflow: ```text # Start Research phase /rpi continue=1 # Move to Planning phase /rpi continue=2 # Move to Implementation phase /rpi continue=3 # Move to Review phase /rpi continue=4 # Optionally run Discover phase /rpi continue=5 ``` All phases share the same conversation context. The agent delegates to sub-agents via the protocol defined in the rpi-agent definition file. ### Handling Tool Unavailability If the `runSubagent` tool is disabled, the rpi-agent will warn: ```text ⚠️ The `runSubagent` or `task` tool is required but not enabled. ``` Fall back to the manual strict RPI workflow when this occurs. ## Summary - **Strict RPI** requires manual invocation of four separate agents (`task-researcher`, `task-planner`, `task-implementor`, `task-reviewer`) with `/clear` commands between phases to ensure complete context isolation. - **rpi-agent** automates the workflow as a single conversation using the `runSubagent` tool to delegate to task agents, carrying context forward across all five phases. - Choose **strict RPI** for complex, unfamiliar, or compliance-heavy work requiring deep research and permanent audit trails stored in `.copilot-tracking/`. - Choose **rpi-agent** for straightforward features, quick bug-fixes, or prototyping where speed outweighs the need for isolated investigation. - Strict RPI requires only basic Copilot chat functions, while rpi-agent requires the `runSubagent` tool to be enabled according to [`.github/agents/hve-core/rpi-agent.agent.md`](https://github.com/microsoft/hve-core/blob/main/.github/agents/hve-core/rpi-agent.agent.md). ## Frequently Asked Questions ### When should I use strict RPI instead of rpi-agent? Use **strict RPI** when working on complex, unfamiliar, or compliance-heavy projects that benefit from thorough, isolated research and a permanent audit record. The enforced phase separation via `/clear` commands eliminates context contamination and produces verified, cited research artifacts in `.copilot-tracking/`. Use **rpi-agent** for straightforward features, quick bug-fixes, or prototyping where execution speed outweighs the need for deep investigation. ### What happens if the runSubagent tool is not available? If the `runSubagent` or `task` tool is disabled, the rpi-agent cannot delegate to sub-agents and will display a warning message. In this scenario, you must fall back to the **manual strict RPI workflow**, invoking each task agent separately (`/task-researcher`, `/task-planner`, etc.) and clearing the chat between phases with `/clear` as documented in [`docs/rpi/why-rpi.md`](https://github.com/microsoft/hve-core/blob/main/docs/rpi/why-rpi.md). ### Does rpi-agent produce the same research quality as strict RPI? Research quality differs between modes. Strict RPI produces **deep, verified, cited research** because the `task-researcher` runs in complete isolation with a fresh token context. The rpi-agent performs **moderate, inline research** where the agent may embed citations, but the shared token budget across all phases limits research depth and may introduce recency bias during later phases. ### Where are workflow artifacts stored in each mode? In **strict RPI**, complete artifacts for each phase—including research documents, plans, implementation logs, and review logs—are stored under `.copilot-tracking/`. In **rpi-agent** mode, only summary-level artifacts are exposed to the user by default; detailed logs are still generated by the underlying sub-agents but remain hidden unless specifically requested.