microsoft/hve-core
Publicmirrored fromhttps://github.com/microsoft/hve-coreAvailable
docs/rpi/using-together.md
392lines · modecode
| 1 | --- |
| 2 | title: Using RPI Agents Together |
| 3 | description: Complete walkthrough of the RPI workflow from research through review |
| 4 | author: Microsoft |
| 5 | ms.date: 2026-01-24 |
| 6 | ms.topic: tutorial |
| 7 | keywords: |
| 8 | - rpi workflow |
| 9 | - task researcher |
| 10 | - task planner |
| 11 | - task implementor |
| 12 | - task reviewer |
| 13 | - complete workflow |
| 14 | estimated_reading_time: 5 |
| 15 | --- |
| 16 | |
| 17 | This guide walks through a complete RPI workflow, showing how the four custom agents work together to transform a complex task into validated code. |
| 18 | |
| 19 | ## The Complete Workflow |
| 20 | |
| 21 | ```text |
| 22 | ┌─────────────────┐ Handoff ┌─────────────────┐ Handoff ┌─────────────────┐ Handoff ┌─────────────────┐ |
| 23 | │ Task Researcher │ ──────────→ │ Task Planner │ ──────────→ │ Task Implementor│ ──────────→ │ Task Reviewer │ |
| 24 | │ │ 📋 Create │ │ ⚡ Implement │ │ ✅ Review │ │ |
| 25 | │ Uncertainty │ Plan │ Knowledge │ │ Strategy │ │ Working Code │ |
| 26 | │ ↓ │ │ ↓ │ │ ↓ │ │ ↓ │ |
| 27 | │ Knowledge │ │ Strategy │ │ Working Code │ │ Validated Code │ |
| 28 | └─────────────────┘ └─────────────────┘ └─────────────────┘ └─────────────────┘ |
| 29 | ↓ ↓ ↓ ↓ |
| 30 | research.md plan.md + details.md code + changes.md review.md + findings |
| 31 | ↑ ↑ |
| 32 | └────────────────────────────────┴──────────────── 🔬 Research More / 📋 Revise Plan ────────────────────────┘ |
| 33 | ``` |
| 34 | |
| 35 | ## Critical Rule: Clear Context |
| 36 | |
| 37 | 🔴 **Use `/clear` or start a new chat between EVERY phase.** |
| 38 | |
| 39 | Why this matters: |
| 40 | |
| 41 | * Each agent has different instructions and behaviors |
| 42 | * Accumulated context causes confusion and errors |
| 43 | * Research findings are in files, not chat history |
| 44 | * Clean context lets each agent work optimally |
| 45 | |
| 46 | For the deeper explanation of how LLM context affects agent behavior, see [Context Engineering](context-engineering.md). |
| 47 | |
| 48 | ## Walkthrough: Adding Azure Blob Storage |
| 49 | |
| 50 | Let's walk through adding Azure Blob Storage to a Python data pipeline. |
| 51 | |
| 52 | ### Phase 1: Research |
| 53 | |
| 54 | 1. Use `/task-research` with your topic to start research (this automatically selects Task Researcher): |
| 55 | |
| 56 | ```text |
| 57 | /task-research Azure Blob Storage integration for Python data pipeline |
| 58 | ``` |
| 59 | |
| 60 | 1. Provide additional context in your message: |
| 61 | |
| 62 | ```text |
| 63 | I need to add Azure Blob Storage integration to our Python data pipeline. |
| 64 | The pipeline currently writes to local disk in src/pipeline/writers/. |
| 65 | |
| 66 | Research: |
| 67 | - Azure SDK for Python blob storage options |
| 68 | - Authentication approaches (managed identity vs connection string) |
| 69 | - Streaming uploads for files > 1GB |
| 70 | - Error handling and retry patterns |
| 71 | |
| 72 | Focus on approaches that match our existing patterns in the codebase. |
| 73 | ``` |
| 74 | |
| 75 | 1. Wait for completion (20-60 minutes). Task Researcher will: |
| 76 | |
| 77 | * Search your codebase for existing patterns |
| 78 | * Research Azure SDK documentation |
| 79 | * Evaluate authentication options |
| 80 | * Create a research document with recommendations |
| 81 | |
| 82 | 1. Review the output: |
| 83 | |
| 84 | ```text |
| 85 | ## 🔬 Task Researcher: Azure Blob Storage Integration |
| 86 | |
| 87 | ✅ Research document created at: |
| 88 | .copilot-tracking/research/2025-01-28-blob-storage-research.md |
| 89 | |
| 90 | Key findings: |
| 91 | - Recommended: azure-storage-blob SDK with async streaming |
| 92 | - Authentication: Managed identity for production, connection string for dev |
| 93 | - Existing pattern: WriterBase class in src/pipeline/writers/base.py |
| 94 | ``` |
| 95 | |
| 96 | ### Phase 2: Plan |
| 97 | |
| 98 | 1. Clear context: `/clear` |
| 99 | 1. Use `/task-plan` with the research file **open** (this automatically selects Task Planner): |
| 100 | |
| 101 | ```text |
| 102 | /task-plan |
| 103 | ``` |
| 104 | |
| 105 | 1. Provide additional planning guidance: |
| 106 | |
| 107 | ```text |
| 108 | /task-plan |
| 109 | Focus on: |
| 110 | - The streaming upload approach recommended in the research |
| 111 | - Phased rollout: storage client first, then writer class, then integration |
| 112 | - Include error handling and retry logic |
| 113 | ``` |
| 114 | |
| 115 | 1. Review the output. Task Planner creates two files: |
| 116 | |
| 117 | ```text |
| 118 | .copilot-tracking/plans/2025-01-28-blob-storage-plan.instructions.md |
| 119 | .copilot-tracking/details/2025-01-28-blob-storage-details.md |
| 120 | ``` |
| 121 | |
| 122 | 1. Verify the plan structure: |
| 123 | |
| 124 | ```markdown |
| 125 | ### [ ] Phase 1: Storage Client Setup |
| 126 | * [ ] Task 1.1: Create BlobStorageClient class |
| 127 | * [ ] Task 1.2: Add configuration schema |
| 128 | |
| 129 | ### [ ] Phase 2: Writer Implementation |
| 130 | * [ ] Task 2.1: Create BlobWriter extending WriterBase |
| 131 | * [ ] Task 2.2: Implement streaming upload |
| 132 | |
| 133 | ### [ ] Phase 3: Integration |
| 134 | * [ ] Task 3.1: Update pipeline factory |
| 135 | * [ ] Task 3.2: Add integration tests |
| 136 | ``` |
| 137 | |
| 138 | ### Phase 3: Implement |
| 139 | |
| 140 | 1. Clear context: `/clear` |
| 141 | 1. Use `/task-implement` to start implementation (automatically switches to Task Implementor): |
| 142 | |
| 143 | ```text |
| 144 | /task-implement |
| 145 | ``` |
| 146 | |
| 147 | Or use the generated prompt for a specific plan: |
| 148 | |
| 149 | ```text |
| 150 | /implement-blob-storage |
| 151 | ``` |
| 152 | |
| 153 | 1. Review at each phase. After Phase 1 completes: |
| 154 | |
| 155 | ```text |
| 156 | Phase 1 complete. Changes: |
| 157 | - Added: src/storage/blob_client.py |
| 158 | - Modified: src/config/schema.py |
| 159 | |
| 160 | Ready for review. Continue to Phase 2? |
| 161 | ``` |
| 162 | |
| 163 | Check the code, run linters, then continue. |
| 164 | |
| 165 | 1. Final output: |
| 166 | |
| 167 | When all phases complete: |
| 168 | |
| 169 | ```text |
| 170 | Implementation complete! |
| 171 | |
| 172 | Changes log: .copilot-tracking/changes/2025-01-28-blob-storage-changes.md |
| 173 | |
| 174 | Files created (3): |
| 175 | - src/storage/blob_client.py |
| 176 | - src/pipeline/writers/blob_writer.py |
| 177 | - tests/integration/test_blob_writer.py |
| 178 | |
| 179 | Files modified (2): |
| 180 | - src/config/schema.py |
| 181 | - src/pipeline/factory.py |
| 182 | |
| 183 | Ready for review. |
| 184 | ``` |
| 185 | |
| 186 | ### Phase 4: Review |
| 187 | |
| 188 | 1. Clear context: `/clear` |
| 189 | 2. Use `/task-review` to validate the implementation (automatically switches to Task Reviewer): |
| 190 | |
| 191 | ```text |
| 192 | /task-review |
| 193 | ``` |
| 194 | |
| 195 | 3. Task Reviewer validates against specifications: |
| 196 | |
| 197 | * Locates research, plan, and changes artifacts |
| 198 | * Extracts implementation checklist from source documents |
| 199 | * Validates each item with evidence from the codebase |
| 200 | * Runs validation commands (lint, build, test) |
| 201 | |
| 202 | 4. Review the findings: |
| 203 | |
| 204 | ```text |
| 205 | ## ✅ Task Reviewer: Blob Storage Integration |
| 206 | |
| 207 | | 📊 Summary | | |
| 208 | |-----------------------|-------------------------------------------------------------| |
| 209 | | **Review Log** | .copilot-tracking/reviews/2025-01-28-blob-storage-review.md | |
| 210 | | **Overall Status** | Complete | |
| 211 | | **Critical Findings** | 0 | |
| 212 | | **Major Findings** | 0 | |
| 213 | | **Minor Findings** | 2 | |
| 214 | | **Follow-Up Items** | 1 | |
| 215 | |
| 216 | Minor findings: |
| 217 | - Missing docstring on BlobStorageClient.upload_stream() |
| 218 | - Consider adding retry count to configuration schema |
| 219 | |
| 220 | Follow-up item: |
| 221 | - Add performance benchmarks for large file uploads (deferred from research) |
| 222 | |
| 223 | Ready for commit. |
| 224 | ``` |
| 225 | |
| 226 | 1. Address findings and commit: |
| 227 | |
| 228 | * Fix Minor findings if desired (optional for commit) |
| 229 | * Address Critical and Major findings before committing |
| 230 | * Note Follow-Up items for future RPI cycles |
| 231 | |
| 232 | ## Artifact Summary |
| 233 | |
| 234 | After completing RPI, you have: |
| 235 | |
| 236 | | Artifact | Location | Purpose | |
| 237 | |----------|-------------------------------|------------------------------| |
| 238 | | Research | `.copilot-tracking/research/` | Evidence and recommendations | |
| 239 | | Plan | `.copilot-tracking/plans/` | Checkboxes and phases | |
| 240 | | Details | `.copilot-tracking/details/` | Task specifications | |
| 241 | | Changes | `.copilot-tracking/changes/` | Change log | |
| 242 | | Review | `.copilot-tracking/reviews/` | Validation findings | |
| 243 | | Code | Your source directories | Working implementation | |
| 244 | |
| 245 | ## Common Patterns |
| 246 | |
| 247 | ### Iterating on Research |
| 248 | |
| 249 | If implementation reveals missing research: |
| 250 | |
| 251 | 1. Note the gap in your current session |
| 252 | 2. Clear context |
| 253 | 3. Return to Task Researcher |
| 254 | 4. Research the specific gap |
| 255 | 5. Update plan if needed |
| 256 | 6. Continue implementation |
| 257 | |
| 258 | ### Handling Complex Tasks |
| 259 | |
| 260 | For very large tasks: |
| 261 | |
| 262 | 1. Break into multiple RPI cycles |
| 263 | 2. Each cycle handles one component |
| 264 | 3. Use research from previous cycles |
| 265 | 4. Build incrementally |
| 266 | |
| 267 | ### Team Handoffs |
| 268 | |
| 269 | RPI artifacts support handoffs: |
| 270 | |
| 271 | * Research doc explains decisions |
| 272 | * Plan shows remaining work |
| 273 | * Changes log shows what's done |
| 274 | * Review log shows validation status |
| 275 | |
| 276 | ## Iteration Loops |
| 277 | |
| 278 | The Review phase can trigger iteration back to earlier phases when findings reveal gaps. |
| 279 | |
| 280 | ### Iteration Paths |
| 281 | |
| 282 | | Review Status | Action | Target Phase | |
| 283 | |---------------|-----------------------------|--------------| |
| 284 | | Complete | Commit changes | Done | |
| 285 | | Needs Rework | Fix implementation issues | Implement | |
| 286 | | Research Gap | Investigate missing context | Research | |
| 287 | | Plan Gap | Add missing scope | Plan | |
| 288 | |
| 289 | ### Rework Flow |
| 290 | |
| 291 | When Task Reviewer identifies Critical or Major findings: |
| 292 | |
| 293 | 1. Clear context: `/clear` |
| 294 | 2. Open the review log in your editor |
| 295 | 3. Use `/task-implement` to address findings |
| 296 | 4. Task Implementor uses the review log to guide fixes |
| 297 | 5. Return to review: `/task-review` |
| 298 | |
| 299 | ### Escalation Flow |
| 300 | |
| 301 | When Task Reviewer identifies research or planning gaps: |
| 302 | |
| 303 | 1. Clear context: `/clear` |
| 304 | 2. Open the review log in your editor |
| 305 | 3. Choose the appropriate phase: |
| 306 | * `/task-research` for missing technical context |
| 307 | * `/task-plan` for scope additions |
| 308 | 4. Complete the phase and continue through the workflow |
| 309 | |
| 310 | ## Quick Reference |
| 311 | |
| 312 | | Phase | Invoke With | Agent | Output | |
| 313 | |-----------|------------------------------|------------------|---------------------| |
| 314 | | Research | `/task-research <topic>` | Task Researcher | research.md | |
| 315 | | Plan | `/task-plan [research-path]` | Task Planner | plan.md, details.md | |
| 316 | | Implement | `/task-implement` | Task Implementor | code + changes.md | |
| 317 | | Review | `/task-review [scope]` | Task Reviewer | review.md | |
| 318 | |
| 319 | > [!TIP] |
| 320 | > `/task-research`, `/task-plan`, `/task-implement`, and `/task-review` all automatically switch to the appropriate custom agent. |
| 321 | |
| 322 | Remember: **Always `/clear` between phases!** |
| 323 | |
| 324 | ## Handoff Buttons |
| 325 | |
| 326 | RPI agents include handoff buttons that streamline transitions between workflow phases. When an agent completes its work, handoff buttons appear in the chat interface. |
| 327 | |
| 328 | ### Available Handoffs |
| 329 | |
| 330 | | From Agent | Handoff Button | Target Agent | Action | |
| 331 | |------------------|------------------|------------------|--------------------------------| |
| 332 | | Task Researcher | 📋 Create Plan | Task Planner | Starts planning with research | |
| 333 | | Task Planner | ⚡ Implement | Task Implementor | Executes the plan | |
| 334 | | Task Implementor | ✅ Review | Task Reviewer | Reviews implementation | |
| 335 | | Task Reviewer | 🔬 Research More | Task Researcher | Researches identified gaps | |
| 336 | | Task Reviewer | 📋 Revise Plan | Task Planner | Updates plan based on findings | |
| 337 | |
| 338 | ### Using Handoff Buttons |
| 339 | |
| 340 | 1. Complete work in current agent |
| 341 | 2. Click the handoff button in the chat interface |
| 342 | 3. The target agent activates with the appropriate prompt pre-filled |
| 343 | 4. Conversation context carries over automatically |
| 344 | |
| 345 | ### When to Use Manual Transitions |
| 346 | |
| 347 | Use `/clear` and manual `/task-*` commands instead of handoffs when: |
| 348 | |
| 349 | * You need to reset conversation context completely |
| 350 | * You want to provide custom parameters to the next agent |
| 351 | * The handoff button doesn't match your intended workflow |
| 352 | |
| 353 | > [!TIP] |
| 354 | > Use `/compact` when you want to reduce conversation length without losing all context. Unlike `/clear`, `/compact` summarizes the conversation history rather than removing it. This is useful mid-phase when context grows long but you want to continue the current task. |
| 355 | |
| 356 | ## RPI Agent: When Simplicity Fits |
| 357 | |
| 358 | For tasks that don't require strict phase separation, **rpi-agent** provides autonomous execution with subagent delegation. Use it when the scope is clear and you don't need the deep iterative research that comes from constraint-based separation. |
| 359 | |
| 360 | ### Quick Decision Guide |
| 361 | |
| 362 | | Choose Strict RPI when... | Choose rpi-agent when... | |
| 363 | |------------------------------|------------------------------------| |
| 364 | | Deep research is critical | Scope is clear and straightforward | |
| 365 | | Multi-file pattern discovery | Minimal external research needed | |
| 366 | | Team handoff needed | Quick iteration during development | |
| 367 | | Compliance or security work | Exploratory or prototype work | |
| 368 | |
| 369 | ### Escalation Path |
| 370 | |
| 371 | You don't have to decide upfront. Start with rpi-agent for speed, and if the task reveals hidden complexity, it can hand off to Task Researcher. This hybrid approach gives you speed for simple tasks and the verified truth that comes from constraint-based research when you need it. |
| 372 | |
| 373 | > [!TIP] |
| 374 | > For the full explanation of why constraints change AI behavior, see [Why the RPI Workflow Works](why-rpi.md#the-counterintuitive-insight). |
| 375 | |
| 376 | See [Agents Reference](../../.github/CUSTOM-AGENTS.md) for rpi-agent implementation details. |
| 377 | |
| 378 | ## Related Guides |
| 379 | |
| 380 | * [RPI Overview](README.md) - Understand the workflow |
| 381 | * [Context Engineering](context-engineering.md) - Why context management matters |
| 382 | * [Task Researcher](task-researcher.md) - Deep research phase |
| 383 | * [Task Planner](task-planner.md) - Create actionable plans |
| 384 | * [Task Implementor](task-implementor.md) - Execute with precision |
| 385 | * [Task Reviewer](task-reviewer.md) - Validate implementations |
| 386 | |
| 387 | --- |
| 388 | |
| 389 | <!-- markdownlint-disable MD036 --> |
| 390 | *🤖 Crafted with precision by ✨Copilot following brilliant human instruction, |
| 391 | then carefully refined by our team of discerning human reviewers.* |
| 392 | <!-- markdownlint-enable MD036 --> |
| 393 | |