Primitives, not features: why Pi is my go-to agent harness

Lilian Weng recently wrote that a model’s real-world performance is decided less by the model than by its harness, the system around it that “orchestrates execution and decides how the model thinks and plans, calls tools and acts, perceives and manages context, stores artifacts, and evaluates results.” Most harnesses answer that brief by adding: sub-agents, plan modes, permission systems, memory layers, a growing pile of built-in behaviour.

Pi answers it by removing almost all of it. It calls itself a minimal agent harness, and its motto is “primitives, not features.” Over the past few months it has quietly become the tool I reach for first, for my own projects and for client work. It is stupidly simple, and the simplicity is deliberate.

What a harness is, and why the simple wins

Weng’s framing is useful because it moves the attention off the model and onto the machinery around it. Her design principle is the part worth holding onto: a harness “should be deliberately simple and generic to enable generalization.” She reaches for the operating-system analogy, a good harness encapsulates complexity behind a simple interface, the way an OS does, rather than growing a special case for every workflow.

Pi takes that almost literally. The creators left sub-agents, plan mode, and permission popups out of the core on purpose, on the expectation that you add exactly the ones you need as extensions or install them from npm. What is left is small: an interactive terminal interface, a print and JSON mode for scripting, an RPC protocol for talking to it from other languages, and an SDK for embedding it. Fifteen or so model providers are supported out of the box, and you switch between them mid-session with /model. Project instructions live in plain AGENTS.md and SYSTEM.md files. Capabilities load through a skills system only when they are relevant.

That is not a stripped-down toy. It is a small core you extend as far as you want and no further. Extensions are just TypeScript with access to tools, commands, and shortcuts, and they install from npm or git like anything else. “Adapt Pi to your workflows, not the other way around” is the whole pitch, and it holds up.

Why it saves tokens

This is the part I did not expect and now rely on. A lot of harnesses spend a large fixed budget before you type a single word: a heavy system prompt, a full catalogue of tool descriptions, the scaffolding for plan mode and permission flows, all of it re-sent every turn. You pay for the machinery whether or not you use it.

Pi’s core carries very little of that, so every turn starts lighter. Skills load on demand through progressive disclosure, so you are not paying to describe capabilities you are not using. You decide what context gets injected through AGENTS.md and SYSTEM.md instead of inheriting a fat default. And sessions are a tree you can branch, with auto-compaction as you approach the context limit, so you manage the transcript deliberately rather than dragging an ever-growing one behind you.

I want to be fair to Weng here, because she is careful about this: her point is that the win comes from context structure, not from minimalism for its own sake, and she is right. A lean harness with lazy context habits will still bloat. But in practice, a small core that hands me the controls is exactly what let me structure context well, and the token bill came down noticeably as a result. The minimalism is what makes the structure mine to design.

Why it is my default now, for me and for clients

For personal projects the appeal is that I stop fighting the tool. When I want a behaviour, I write forty lines of TypeScript or install someone’s extension, and I reuse a small set of my own across projects. Nothing is hidden and nothing is fighting me.

For client work two things matter more. The first is cost. Fewer tokens per turn is real money once an agent is running all day across a team, and it is more predictable, which finance departments care about more than raw cheapness. The second is control. Pi is MIT-licensed, model-agnostic across fifteen-plus providers, scriptable through its print, RPC, and SDK modes, and it runs wherever I put it. That is the same posture I argued for in own the model, not the API: do not rent a capability from a vendor who can change the terms under you. The AGENTS.md instructions are the same idea as the loadable skill files I use in ECL, workflow captured as a plain, versioned, reviewable document rather than baked into a black box.

What I’d be careful about

The flip side of “primitives, not features” is that the good defaults are now your job. Out of the box Pi does less than a batteries-included agent, and if you want sub-agents or a plan mode you install or write them. For someone who wants to open a tool and have it do everything on day one, that is friction, and it is a fair reason to pick something easier/heavier.

And the last point, again, is Weng’s: the harness being small is not itself the win. It is the room it gives you to do context engineering properly. Pi will not save you tokens if you fill that room carelessly. It gives you the controls; using them well is still on you! That is a trade I make gladly, because I would rather own that responsibility than have a vendor make the choice for me and bill me for it. But it is a trade, and worth knowing before you switch.

If you want an agent setup that is cheap to run, easy to audit, and not welded to a single vendor, that is the kind of thing I set up for clients. Get in touch.