Pi Is Not Another Agent SDK — and That’s the Whole Point

Most “build your own agent” frameworks hand you a bigger box of parts. Pi hands you a smaller one, then teaches the agent to build the rest itself.

If you’ve spent any time wiring up AI agents lately, you know the drill. You pick a harness — the layer that sits between the model and the real world, running the loop of reason → call a tool → feed the result back → repeat. You reach for the Claude Agent SDK, or LangChain’s deepagents, or the OpenAI Codex SDK, or one of the dozen Kimi/Cursor/Antigravity flavors shipping every week. Each one adds more: more built-in tools, more orchestration, more config, more MCP integrations, more abstraction.

Then there’s Pi — the tiny coding agent that powers OpenClaw — which went the opposite direction and somehow ended up being the one a lot of serious people now use exclusively.

This post is about why that happened. By the end you should understand what makes Pi architecturally different from the mainstream harnesses, and why “smaller core, agent extends itself” might be a better bet than “batteries included” as agents get more capable.

First, what’s a harness, and why does it matter now?

The model is the easy part. As one widely-shared teardown of Claude Code put it: the codebase is ~500K lines, and the actual API call is maybe 200 of them — everything else is the harness, and the harness is where the differentiation happens.

That’s the shift the whole industry is going through right now. The AI model is no longer the product. The harness is. As agents move from “answer my question” to “go do a multi-hour task,” the decisive layer becomes the one running the loop: sandboxing, tool routing, state, credentials, and multi-agent delegation.

So every harness is making a bet about how that layer should look. The mainstream bet is accumulation. Pi’s bet is subtraction.

The mainstream harnesses: more is more

To be clear, the popular SDKs are good software. They’re just optimizing for a particular idea — that a great agent comes from giving the model a rich, pre-built environment.

• Claude Agent SDK is the exact engine that powers Claude Code, extracted as a library. Same agent loop, same tools, same context management, same permission pipeline. It’s deeply polished — and deeply tied to Anthropic’s stack and (originally) its sandbox model.
• deepagents (LangChain) is the model-agnostic answer. It ships write_todos for planning, a full filesystem toolset, shell execution, subagent spawning, and pluggable backends — swap in-memory state for disk, LangGraph Store, or remote sandboxes like Modal or Daytona. The LLM is "just a parameter."
• Codex SDK (OpenAI) is the single-provider, OS-isolation-first approach — a native app-server that owns threads and compaction, optimized hard for one provider’s models.

Notice the common thread: each treats the harness as the thing you configure. You bring requirements; the SDK has a feature for them. Need a to-do list? It’s built in. Need a tool? Register it, often through MCP. The framework anticipates your needs and ships the abstraction.

That works. It also means the harness layer keeps getting heavier, and you’re increasingly betting on someone else’s idea of what an agent should be able to do.

Pi’s bet: a tiny core that rewrites itself

Pi, written by Mario Zechner and championed loudly by Armin Ronacher, makes a startlingly different wager. Here’s Ronacher describing what drew him in — Pi has the shortest system prompt of any agent that I’m aware of and it only has four tools: Read, Write, Edit, Bash.

Four tools. That’s the whole default surface area. No planner, no subagent system, no MCP, no plugin marketplace baked into the core.

The magic isn’t in what’s there — it’s in the philosophy behind what’s missing. When you want Pi to do something it can’t, you don’t go and download an extension or a skill or something like this. You ask the agent to extend itself. Pi celebrates the idea of code writing and running code.

That single idea — software that builds more software — is the thing to hold onto. It reframes the harness from “a feature catalog” into “a substrate the agent reshapes on demand.”

The deliberate omissions

The clearest tell is MCP. The mainstream harnesses lean into the Model Context Protocol as the way to bolt on capabilities. Pi has no MCP support at all — and that’s a stance, not laziness.

There’s even a sharp technical reason. With MCP, tools generally have to be loaded into the system context at session start. That makes it very hard to impossible to fully reload what tools can do without trashing the complete cache or confusing the AI about how prior invocations work differently. If your whole design goal is an agent that rewrites its own tools mid-flight, baking tools into the opening context fights you. So Pi doesn’t.

Why “extend yourself” actually works

This only holds together because of a few quietly excellent architecture decisions underneath:

1. Sessions are trees, not logs. You can branch and rewind. Ronacher uses this to make a side-quest to fix a broken agent tool without wasting context in the main session — then rewinds, and Pi summarizes what happened on the branch. Your main context stays clean.
2. Extensions can persist state into sessions. The session file holds not just model messages but custom messages that extensions (or the system) read and write — state that may never be sent to the model at all.
3. Hot reloading is built in. The agent can write an extension, reload, test it, and loop until it works — without restarting.

Put together, you get an agent that can notice a gap, write code to fill it, test that code, and keep going, all in one session. The to-do list, the code-review flow, the browser automation — in Ronacher’s setup, none of it was downloaded. He told Pi what he wanted; Pi built it.

What Pi actually looks like in code

Under the hood, Pi (the [pi-mono](https://github.com/badlogic/pi-mono/) monorepo) is layered so you take only what you need:

┌─────────────────────────────────────────┐
│  Your Application                       │
│  (OpenClaw, a CLI tool, a Slack bot)    │
├────────────────────┬────────────────────┤
│  pi-coding-agent   │  pi-tui            │
│  Sessions, tools,  │  Terminal UI,      │
│  extensions        │  markdown, editor  │
├────────────────────┴────────────────────┤
│  pi-agent-core                          │
│  Agent loop, tool execution, events     │
├─────────────────────────────────────────┤
│  pi-ai                                  │
│  Streaming, models, multi-provider LLM  │
└─────────────────────────────────────────┘

pi-ai normalizes every provider behind one streaming interface. pi-agent-core is the loop. A minimal agent is genuinely just this:

typescript

import { Agent } from "@mariozechner/pi-agent-core";
import { getModel, streamSimple } from "@mariozechner/pi-ai";
const agent = new Agent({
  initialState: {
    systemPrompt: "You are a helpful assistant with access to tools.",
    model: getModel("anthropic", "claude-opus-4-5"),
    tools: [weatherTool],     // your tools - or none
    thinkingLevel: "off",
  },
  streamFn: streamSimple,     // swap providers without touching the rest
});
await agent.prompt("What's the weather in Tokyo and London?");

You didn’t write the reason-call-feed-back loop. The agent handles it. Want a different model provider? Change the getModel line; everything else stays put.

Crucially, Pi’s session portability is a design constraint, not an afterthought. The SDK assumes a session may contain many different messages from many different model providers, so it deliberately doesn’t lean in too much into any model-provider-specific feature set that cannot be transferred to another. Compare that to a harness optimized hard for one provider’s native server — convenient until you want to leave.

OpenClaw: the same tiny core, taken to the extreme

Here’s the payoff that makes the philosophy concrete. OpenClaw — the agent-connected-to-your-chat project that went viral earlier this year — is built on these exact packages. It’s the same pi-coding-agent core, just with the UI removed and the agent wired straight into WhatsApp, Telegram, Discord, Slack, Signal, and more.

OpenClaw doesn’t fork Pi or fight it. It uses Pi’s extension hooks — context to prune oversized tool results, session_before_compact to swap in a smarter summarization pipeline that preserves file-operation history — and the tool factories to scope each user's file access to their own workspace. The harness stayed minimal; the product-specific behavior lives in extensions layered on top.

That’s the thesis in action. Ronacher’s framing of where this goes: working with a minimal agent makes you live that idea of using software that builds more software — and taken to the extreme, that’s exactly what OpenClaw is.

And notably, OpenClaw can fall back across harnesses — its docs describe an auto runtime that uses [the Codex harness for `codex/` models and the internal Pi harness otherwise](https://deepwiki.com/openclaw/docs/5.4-agent-harness-plugins). The minimal core and the heavyweight SDKs aren't always either/or.*

So which should you reach for?

There’s no universal winner here, and anyone selling you one is selling you something. The honest split looks like this:

• Reach for a batteries-included SDK (Claude Agent SDK, deepagents, Codex SDK) when you want a polished, supported, well-trodden path — built-in planning, sandboxing, RBAC, multi-user isolation — and you’re happy to operate inside the framework’s worldview. For many production teams, that maturity is exactly right.
• Reach for Pi when you want a small, legible core you fully understand, provider portability baked in, and an agent that extends itself rather than pulling in third-party extensions you have to trust. It rewards people who’d rather have their agent build a tool than download one.

The deeper point is the trend. As harnesses get more complex and more products ship features into that layer, Pi is a bet that the winning move might be less harness, not more — a minimal, malleable core that treats “the agent writes its own tools” as the primary feature instead of an edge case.

That’s a genuinely different idea about where agents are heading. Whether or not you adopt Pi, it’s worth understanding — because the question it raises is the one every team building agents will have to answer.

Want to dig in? Pi lives at [badlogic/pi-mono](https://github.com/badlogic/pi-mono/), Armin Ronacher's writeup on why he's hooked is here, and Nader Dabit's hands-on build guide walks through every layer with code. If you've built an agent on Pi — or deliberately chosen not to — I'd love to hear what tipped the decision.

This story is published on Generative AI. Connect with us on LinkedIn and follow Zeniteq to stay in the loop with the latest AI stories.

Subscribe to our newsletter and YouTube channel to stay updated with the latest news and updates on generative AI. Let’s shape the future of AI together!