How to Actually Adopt Hypervelocity Engineering (Without Buying the Whole Pitch)

I sat through two different Microsoft talks on Hypervelocity Engineering a few weeks apart, convinced I'd already written this article, then couldn't find it anywhere. Turns out I hadn't written it. I'd just watched enough HVE content that it felt written. That's its own small lesson about AI-generated summaries: they create the sensation of having done the work.

So here's the actual work. Not the keynote version, with the 2 to 3x velocity numbers and the "30% of Microsoft's code is agent-written" line attributed to Satya Nadella (unverified in either talk, for what it's worth). The part that matters if you're an engineer trying to use this on Monday: the RPI workflow, and how to install and adapt it without breaking your existing setup.

What RPI actually is

RPI stands for Research, Plan, Implement, Review. It's not a slogan, it's a four-agent handoff system, and each agent has a real name in Microsoft's actual repo:

• Task Researcher
• Task Planner
• Task Implementor
• Task Reviewer

Each phase is a separate agent with a separate scope, and they don't overlap by design. That's the entire mechanism. The constraint is the feature.

The Research phase is the one worth understanding first, because it's the one people skip. The Task Researcher reads your codebase, your APIs, your conventions, your documentation. It cannot write code. That's a hard rule, not a style preference. Microsoft frames the reasoning this way: a model still allowed to write code while "researching" will quietly start writing code anyway, because writing code is the thing it's good at and the thing it thinks you want. Take that option off the table, and the only thing left to optimize for is being right about what it found. The output changes from "here's some code that plausibly does what you asked" to "here's what your codebase actually does, with file references."

Plan, Implement, and Review follow the same logic. The Task Planner turns verified research into a strategy. The Task Implementor writes the code, using the plan, not the research. The Task Reviewer checks the diff against the plan, not against vibes.

The two-prompt habit that actually matters

If you take one thing from this, take this: stop one-shotting.

The habit that makes RPI work has nothing to do with installing anything. It's a discipline you can start using today, in whatever tool you already have open:

1. Prompt one: "Research this. Do not write code."
2. Prompt two: "Propose a plan."

That's it. Two prompts, two separate turns, no code in the first response. If your current workflow is "describe the feature, get code back," you're skipping the phase that makes the rest of RPI trustworthy. You can get most of the value of hve-core by just enforcing this split manually, in Copilot, in Claude, in whatever you're already paying for.

Installing hve-core (and the part most writeups get wrong)

The actual toolkit lives at github.com/microsoft/hve-core, MIT licensed, published under the ise-hve-essentials account. Beyond the four RPI agents, it includes agents for PR review, doc ops, commit messages, prompt evaluation, a design-thinking coaching agent, memory agents, and coding-standard checkers for C#, Python, Bash, and TypeScript. Microsoft's own agent catalog puts the count at 21 named agents (a separate installer listing rounds it to "25+" depending on what you count as a standalone agent versus a supporting skill). Either way, it's a real library, not a handful of prompts with a marketing name.

If you're on VS Code, install from the Marketplace, reload, and the agent picker dropdown shows up in Copilot Chat. Done. The rest of this section is for the case most coverage skips entirely: what to do if you're on Visual Studio, not Code.

The answer, if you're on Visual Studio

Visual Studio 2026, version 18.4 and later, has native custom-agent support. No extension, no CLI, no plugin marketplace. Drop .agent.md files into .github/agents/ at your repo root, and they show up directly in the Copilot Chat agent picker.

Quick orientation if you haven't used this part of Copilot Chat yet: open the chat panel with Ctrl+Alt+I, and above the message box there's a row of dropdowns, one of them (usually reading "Agent," "Ask," or similar) is the mode selector. Click it and a menu opens: built-in modes like Ask, Plan, and Agent at the top, then Visual Studio's built-in specialized agents (Debugger, Modernize, Profiler), and below those, a section for anything you've added yourself. That's the agent picker. Any .agent.md file Visual Studio finds under .github/agents/ in your open solution shows up in that bottom section, and selecting one switches the whole chat session into that agent's persona and constraints for whatever you ask next. If that section reads "No custom agents added," either the files aren't in the right place yet or the solution needs a reload, more on that below.

Copy the whole hve-core collection as a unit, preserving its internal structure, into your solution:

your-solution\
├── your-solution.sln
└── .github\
    └── agents\
        └── hve-core\
            ├── task-researcher.agent.md
            ├── task-planner.agent.md
            ├── task-implementor.agent.md
            ├── task-reviewer.agent.md
            ├── task-challenger.agent.md
            ├── rpi-agent.agent.md
            ├── subagents\
            │   └── (everything in here)
            └── (a few non-RPI utility agents you can prune later)

Copy the whole hve-core subfolder, not individual files. The core RPI agents delegate to files under subagents/, and a flattened copy will silently break that delegation.

Two things have to be true before the picker will show anything:

1. Reload the solution after adding the files, not just the picker. The agent scan runs on solution load; files added while a solution is already open won't appear until you close and reopen it.
2. The solution needs to be an actual git repository. The custom-agent loader scans disk directly and doesn't care, but the agents' own file-reading tools (what they use to actually research your code) operate against a git-tracked workspace. If you haven't run git init yet, an agent can find itself in the picker and still report zero files found when you ask it to do anything. git init, git add ., one commit, that's enough for local testing.

No solution yet? "Blank Solution" is a real template (File → New → Project → Blank Solution). Gets you a .sln with nothing in it, which is enough to anchor .github/ at the right level and test the whole setup before you've decided what kind of app you're building. Add a real project into it whenever you're ready.

The path that looks like the answer and isn't, yet

The Copilot CLI also supports installing hve-core as a plugin (copilot plugin marketplace add microsoft/hve-core, then copilot plugin install hve-core@hve-core), and on Linux or macOS this works cleanly, no IDE required at all. On Windows, it currently doesn't. hve-core ships its agent files as git symlinks. Windows Git defaults to treating symlinks as plain text files containing a path string, not real links, so every agent file the CLI tries to load comes back as "malformed frontmatter," and the plugin installs but the agents never actually load. This is a confirmed, open bug in GitHub's own CLI repo as of this writing, not a local misconfiguration, and no combination of Developer Mode, git config --global core.symlinks true, or reinstalling fixes it. If you hit Access is denied (os error 5) partway through installing instead, that one's unrelated and usually just means VS Code is open and its file watcher is holding a lock on the plugin folder; close VS Code entirely and retry.

Given that, the CLI plugin isn't a real option for a Visual Studio shop on Windows right now, which is exactly the audience it would need to serve. The native custom-agent path above isn't a workaround for the CLI being broken, it's simply the better answer: no plugin marketplace (which has no review or signing, worth knowing before a team standardizes on one), no version pinning to worry about, no symlink dependency at all, since you're copying real files instead of asking git to resolve links.

Write down your actual preferences

The part of this that people underuse is copilot-instructions.md as an enforcement mechanism, not just documentation. If you have a real opinion (ban AutoMapper in this codebase, require a specific test pattern, whatever it is) write it down as a concrete instruction. A checking agent can then actually enforce it instead of you catching it in review three weeks later. Vague preferences don't get enforced. Specific, written ones do.

The one warning worth repeating

Don't cherry-pick individual hve-core agents out of the system and expect them to work the same way in isolation. The Reviewer agent checks against a Plan artifact the Planner produced; pull it out on its own and it has nothing to check against. The whole point of RPI is that each phase produces an artifact the next phase depends on. Grab the parts you like without the handoff structure, and you've built something that looks like RPI but doesn't have the constraint that makes it work.

Where this actually lands

Strip away the keynote numbers and the architecture diagrams, and HVE's actual claim is narrow: a research phase that can't write code, followed by a plan the implementation has to follow, followed by a review that checks against that plan, produces more trustworthy output than letting an agent go straight from prompt to pull request. You don't need Microsoft's toolkit to test that claim. You need two prompts and the discipline not to skip the first one.

Whether that's worth a 20-plus-agent install depends on how much of your team's current workflow is already "describe it, get code, hope it's right." If that's where you are, the two-prompt habit alone is worth adopting before you touch the repo.