Pi Is a Coding Agent for People Who Like Control

I have been writing a lot about harnesses because that is where the useful AI work keeps ending up.

The model matters.

The harness decides whether the model can actually do the job.

That is why Pi has become one of my favorite coding agents to play with. The interesting part is not that it is another terminal agent. There are plenty of those now.

The interesting part is that Pi treats the harness as something you are expected to own.

The tagline on the Pi site gets this right:

There are many agent harnesses, but this one is yours.

That is the whole reason I care about it.

As of May 2026, the Pi docs describe it as a small core that can be extended with TypeScript extensions, skills, prompt templates, themes, and packages. The main site uses the same framing: adapt Pi to your workflows, instead of adapting your workflow to the product.

That sounds like a positioning line until you actually set it up.

Then it becomes the whole point.

The missing features are the product

Most coding agents sell completeness.

Plan mode. Subagents. MCP. Background shell commands. Permission systems. Task lists. Review loops. Browser automation.

Pi starts from the other direction.

The default surface is intentionally small. You get the terminal agent, model access, file and shell primitives, sessions, and a TUI. Then you decide what the agent should become.

That can feel strange if you expect every product to arrive with one official answer.

I think it is the right default for a certain kind of user.

If you already know how you like to work, a sealed agent gets in the way. It makes you accept its plan mode, its review flow, its context rules, its idea of safety, and its interface decisions.

Pi makes a different tradeoff.

It gives you a small machine and makes the surrounding system editable.

My setup says more than the docs

The reason Pi clicked for me was not the public feature list.

It was opening my own .pi config and realizing how much of the system had become explicit.

The version I am actually using day to day is pretty simple:

• the solo theme
• openai-codex as the default provider
• gpt-5.5 at extra-high thinking
• pi-solo installed as a package
• the Pi MCP adapter
• the Solo MCP server wired into Pi
• my shared agent skills available from the same local skill directory I use elsewhere
• a few local extensions, including a Solo status footer, Git AI integration, and Superset lifecycle hooks

There are other packages in there too. I have an ask-user-question package, pi-btw, and theme support installed.

That is the part I like.

The setup is not hidden behind a product setting somewhere. It is local, inspectable, and close to the work.

If I want Solo context in the terminal, that is a package and an MCP server. If I want status visible in the TUI, that is an extension. If I want lifecycle hooks to fire into another local system, that is an extension. If I want my broader skill library available, that is a setting. If I want the interface to feel like my own environment, that is a theme.

This is the harness as code.

Solo is the part that made it stick

The Solo piece is the most important part of my current setup.

I still use Pi as a normal terminal coding agent.

I have just been living most of my recent development work inside Solo, so that is where Pi has become especially interesting.

That is a different feeling.

The normal coding-agent loop is one session talking to one repo. That is useful, but it can become isolated fast. The agent knows what is in its context window. It may know the current folder. It may know the last command. It does not automatically understand the broader local process.

Solo changes that shape. It gives Pi a way to participate in a wider local system of projects, processes, agent coordination, and status. The Solo MCP server gives it a tool boundary. The extension gives me visible state in the interface. The theme makes it feel native to the rest of the setup instead of bolted on.

I will do a full Solo writeup soon, because that deserves its own piece.

That matters more than another clever prompt.

The best agent experience I have found is not the one with the most visible features. It is the one that fits into the way the rest of the machine works.

Extensions are where Pi gets personal

The extension system is the part I keep coming back to.

Pi's core is small enough that extensions do not feel like decorations. They feel like the product boundary.

That distinction matters.

In a lot of tools, an extension adds a button, a command, or a narrow integration. Useful, but still peripheral.

In Pi, extensions can change the working shape of the agent. They can add status. They can add lifecycle behavior. They can connect to local systems. They can change how the session feels and what the agent can reach.

The strange part is that Pi understands this about itself.

You can ask Pi to inspect its own setup, change its config, write a new extension, install a package, adjust a theme, or explain how the pieces fit together. That is rare among coding agents. Most tools can edit your repo. Far fewer can help modify the harness they are running inside.

That is a big part of why Pi feels different.

My local extensions are not a huge product surface. That is the point.

They are small, specific pieces of glue:

• show the Solo/MCP state in the footer
• connect Git AI behavior
• emit lifecycle hooks into Superset
• keep the rest of the interface quiet

That is the kind of customization I trust because it is grounded in actual friction.

I do not want a giant agent configuration because it looks impressive. I want a few sharp extensions because I can feel the missing piece during work.

MCP should be boring

The MCP side of Pi is similar.

I do not want MCP to be a novelty layer.

I want it to be boring plumbing.

In my setup, Pi has MCP servers available for Solo, Cubic, Exa, Context7, and Ref. The important one for this post is Solo because it changes the operating context of the agent. The others are examples of the same pattern: give the agent bounded access to useful local or external capabilities instead of hoping the base model remembers everything.

That is where Pi's small-core philosophy pays off.

You do not need every capability built into the agent.

You need a clean way to attach the capabilities you actually use.

Control beats completeness

The mistake would be to read this as an argument that every team should use my exact setup.

That is backwards.

The point is that Pi makes the setup worth having.

My current setup is Solo-heavy because that is where my work is right now. Someone else might care more about browser automation, planning workflows, model routing, package distribution, repo-specific prompts, or a different MCP stack.

That is fine.

The product idea is the same: keep the core small, then make the surrounding system editable.

This is why I think Pi is more interesting than its surface area suggests.

It is not trying to convince me that its defaults are the future of coding.

It is giving me a place to put my own defaults.

The tradeoff is ownership

Pi is not the right tool for everyone.

If you want the most polished default experience, you may prefer a more opinionated agent. If you want every feature already designed for you, Pi can feel too bare.

That is the tradeoff.

Pi gives you control, and control gives you work.

You need to decide which packages to trust. You need to maintain your prompts. You need to keep skills sharp. You need to notice when a workflow is useful and when it has become ritual. You need to think about where safety belongs.

I like that tradeoff because it matches how serious agent work actually feels.

The durable advantage is not one magic prompt or one perfect model choice.

It is a system you can keep improving.

For me, Pi is valuable because it makes that system visible.

The agent is not floating above the repo as a black box. It is sitting inside a local operating layer that I can inspect, edit, package, and replace.

That is the version of AI coding I want more of.

Less theater around autonomy.

More control over the harness.