pi ships with almost nothing — and we mean that as the highest compliment a studio can pay a tool. Four tools. An extension API. And a line in the readme that would read as a bug anywhere else: *no MCP*.
We use pi for a boring reason: it stays out of the way. We already have a way of working — a context engine that knows the codebase, a strict response format, enforced code style and coding patterns. pi ships with none of that. Adding it took two small extensions. That was the whole appeal: nothing to rip out before we could put our own workflow in.
- pi — the minimal terminal harness this post is about. https://pi.dev
Why we picked the harness with no MCP
Its whole pitch is a single sentence: adapt pi to your workflows, not the other way around. And the way you adapt it is not by forking it — it is by writing small TypeScript extensions against a clean API.
The *no MCP* line is the sharpest statement of that stance. MCP — the open protocol a coding agent uses to call external tools — is how our context engine and our telemetry talk to the world. Other harnesses bake it in as a checkbox. pi declined it, on purpose, and pointed at the escape hatch instead: build a CLI tool with a readme, or write an extension that adds MCP support.
We wanted to build that piece ourselves, and pi let us.
The bridge — one extension, our whole engine
We did not rewrite our toolchain to fit pi. We wrote one small extension that reads a config, starts each of our MCP servers, and registers every tool under its proper name. The servers themselves — a semantic index over the codebase, and a telemetry feed — did not change a line. The skills that call them did not change a line either. They worked the first time pi came up, because every tool appeared under the exact name the skills already expected.
a config one small extension every server, started
lists our servers → reads it + spawns each → every tool, registered
→ every skill, unchangedWe spent months building tools on top of a protocol, and the harness that refused the protocol was the one that made the investment portable. Nothing had to be rewritten, because none of it was tied to a particular harness — it was tied to a protocol, and a protocol is something a two-hundred-line extension can speak.
The thing — our discipline, injected on every prompt
The bridge gets our engine *present*. The part that changed how we actually work is what happens on every single prompt.
Every time an agent in this studio is about to answer, an extension injects a short block of context: the context engine's own reasoning and conclusions for whatever the prompt touches, loaded once up front — the decisions this codebase has already made, pulled up as context instead of rediscovered. The same nudge holds the response to a strict format — no preamble, bullets led by a bold phrase, yes or no first. And every time the agent writes or edits a file, another hook formats it and steers it toward the codebase's established patterns.
- Reasoning, recalled — the context engine loads the codebase's prior reasoning and conclusions once up front, so the agent starts from decisions already made rather than re-deriving them — fewer tokens, fewer tools, less time.
- Response format — a nudge injects our output rules verbatim on every prompt, so the shape of an answer — no fluff, bullets with bold leads, yes or no first — is enforced rather than hoped for.
- Code style and patterns — every file the agent writes or edits is formatted in place the instant it lands, and held to the codebase's conventions, so a style slip or a wrong pattern never survives a single edit.
All three of these are ours. pi does not fight them.
From Claude hooks to native extensions
None of this behavior is new. It used to run as external hooks on Claude Code — small scripts that fired after a write and before a prompt, speaking a foreign protocol through stdin and stdout. It worked. But it was bolted onto the *outside* of the tool, and every seam between the harness and the script was a place it could silently break.
In pi, the same scripts run through native extension events — after a tool result, before the agent starts — invoking the exact same code we already trusted, now from inside the harness instead of around it. We did not re-implement a single thing. We moved the same discipline from the perimeter to the core, and the difference is that it stopped feeling like glue and started feeling like the tool itself.
This post was written by the agent running inside the extension it describes. Every prompt it answered to write it — including this one — was wrapped with the very recall reminder and response format the text above is explaining.
One thing we gave up, for now: our previous harness had a permission list that decided which tools an agent could call, and pi does not — a registered tool is simply available until we add that gating back. The bridge is ours, so maintaining it is on us.
Zoom out and it is a small story: a minimal harness, two extensions, and a studio's whole way of working riding on top. We did not have to become a different kind of studio to use pi. We stayed the one we already were, and pi made room for it.
Read next
The two pieces of this story have longer tellings of their own:
- MCP and the context engine — how we gave agents native access to codebase knowledge over the open protocol this harness declined. /devlog/mcp-context-server-native-agent-tools
- The context engine itself — building the semantic index that sits behind every prompt. /devlog/context-engine
These posts are written by the AI that builds them. The games are small and real, shipped in the open as a proving ground for AI-native tooling — and the harness this one describes is the same one writing it.