Interactive Explainer

Pi & OpenClaw:
The Self-Extending Agent

Most coding agents ship with dozens of built-in tools. Pi ships with four - and asks the AI to build the rest. Explore how this radical constraint powers a new kind of agent architecture, and how OpenClaw embeds it as the runtime for a multi-channel AI platform.

March 2026 · 12 min read

The typical AI coding agent is a Swiss Army knife: file search, web browsing, code execution, git integration, linting, testing, documentation lookup, image generation, database queries. The list grows with every release. Each new capability means more tools loaded into the system prompt, more context consumed before the agent writes a single line of code.

Pi, created by Mario Zechner, takes the opposite approach. It ships with the shortest system prompt of any coding agent and exactly four tools: Read, Write, Edit, and Bash. Everything else - browser automation, code review, task management, multi-agent orchestration - the agent builds for itself, on demand, by writing code.

This is not minimalism for its own sake. It is a design philosophy: LLMs are already good at writing and running code, so instead of shipping pre-built capabilities that bloat the context window, let the agent extend itself at runtime. The result is an agent that starts small and grows exactly the capabilities it needs.

The Minimal Core

Philosophy

Four Tools, Infinite Capabilities

Pi's core insight is that four primitives are sufficient for any software engineering task. Read lets the agent understand existing code. Write creates new files. Edit modifies existing ones. Bash executes arbitrary shell commands - which means the agent can install packages, run tests, call APIs, start servers, or do anything else a developer can do from a terminal.

When the agent needs a capability it does not have - say, browsing a webpage - it does not look for a pre-installed MCP server or extension. It writes a script that uses the Chrome DevTools Protocol, runs it via Bash, and parses the output. The capability is created on demand, tailored to the specific task, and discarded when no longer needed.

The visualization below demonstrates this principle. Choose a task, and watch how pi decomposes it into a sequence of its four primitive tools. Complex operations emerge from simple compositions.

Figure 1 - Tool Composition

Task:

Each task is decomposed into pi's four primitive tools. Notice that even complex operations like browsing the web or building a new extension resolve to the same four primitives. The self-extend task shows how pi creates new capabilities by writing and executing code.

Why not MCP? Pi intentionally rejects the Model Context Protocol. MCP tools must be loaded into the system context at session start, making runtime reloading difficult without invalidating the cache. Pi instead uses mcporter - which exposes MCP servers as CLI bindings - or simply has the agent write the capability directly.

The Monorepo

Pi is not a single tool but a collection of packages in a TypeScript monorepo. The coding agent CLI is the most visible piece, but beneath it sits a layered architecture of reusable libraries that other projects - like OpenClaw - can embed independently.

pi-ai Unified multi-provider LLM API. Talks to OpenAI, Anthropic, Google, and others through a single interface.

pi-agent-core Agent runtime with tool calling, state management, and the core agent loop.

pi-coding-agent The interactive CLI coding agent. The part users interact with directly.

pi-tui Terminal UI library with differential rendering for smooth, flicker-free output.

pi-web-ui Web components for building AI chat interfaces in the browser.

pi-mom A Slack bot that delegates messages to the pi coding agent.

pi-pods CLI for managing vLLM deployments on GPU pods.

This layered design is what makes pi embeddable. OpenClaw does not fork the coding agent - it imports pi-agent-core and pi-ai as libraries, then builds its own tool set, system prompt, and session management on top. The monorepo provides the engine; the consumer provides the chassis.

Sessions as Trees

Architecture

Not a Chat Log - A Branching History

Most agents store conversations as a flat list of messages. Pi stores them as trees. Each message has an id and a parentId, stored in JSONL format. This means you can branch from any point in a conversation, explore a different approach, and later return to the original path.

This is more than a convenience feature. It changes how you work with an agent. Instead of starting over when an approach fails, you revert to the decision point and try a different branch. You can run parallel explorations and compare results. The session tree becomes a record of your problem-solving process, not just a transcript.

The explorer below simulates a pi session tree. Click any node to select it, then Branch to explore an alternative path. The tree grows as you would navigate a real session - branching at decision points, building parallel explorations.

Figure 2 - Session Tree Explorer

Click a node to select it

Each circle is a conversation turn. Green is the selected node. Click a node and press Branch to create an alternative path from that point. Continue extends the current branch. Notice how the tree structure lets you explore multiple approaches without losing earlier work.

Internally, sessions are stored as JSONL files where each entry carries its parent reference. Pi's SessionManager handles persistence - opening, reading, appending, and navigating the tree. This format also means sessions can contain messages from different model providers in the same tree, since each node is self-describing.

OpenClaw: Pi as Infrastructure

OpenClaw is a messaging gateway that embeds AI agents across communication channels - Discord, Slack, Telegram, WhatsApp. Rather than building its own agent runtime from scratch, it imports pi's SDK directly and wraps it with channel-specific behavior.

Pi CLI Command-line invocation. Default tool set. Static system prompt from AGENTS.md. Sessions stored in ~/.pi/. Single credential. TUI rendering.

OpenClaw SDK embedding via createAgentSession(). Custom tool suite. Dynamic system prompt per channel. Multi-profile auth rotation. Callback-based events.

Integration

Embedding, Not Forking

OpenClaw does not spawn pi as a subprocess or call it over RPC. It directly imports and instantiates pi's AgentSession via createAgentSession(). This embedded approach gives OpenClaw full control over the session lifecycle - creating sessions, injecting custom tools, customizing system prompts per channel, and handling events through callbacks rather than rendering to a terminal.

The flow works like this: a user sends a message on Discord. OpenClaw's gateway receives it, resolves the right agent configuration, builds a dynamic system prompt for that channel, assembles the tool set through a multi-stage pipeline, creates a pi AgentSession, and calls session.prompt(). Pi's agent core handles the LLM communication, tool execution, and response streaming. OpenClaw routes the response back to the channel.

The diagram below shows this flow. Select a channel to see how the same pi core gets wrapped with different system prompts, tools, and behavior for each platform.

Figure 3 - OpenClaw Architecture

Channel:

The same pi AgentSession core is wrapped differently for each channel. Discord gets thread management and reaction tools. Slack gets workspace-aware formatting. Each channel contributes its own tools and system prompt sections, but the underlying agent loop is always pi.

Authentication and Failover

OpenClaw maintains multiple API keys per provider through an auth profile store. When a provider rejects a request - rate limit, quota exceeded, authentication failure - the system classifies the error and can automatically rotate to the next profile or fail over to an entirely different provider. This is invisible to the agent session; it just sees a working LLM connection.

Session Persistence

OpenClaw reuses pi's JSONL tree format for sessions but adds caching on top. A SessionManager cache avoids repeatedly parsing the same JSONL files, with access tracking to evict stale entries. Different channel types get different history depths - direct messages keep more context than group conversations where the agent is mentioned occasionally.

The Tool Pipeline

One of OpenClaw's most interesting architectural details is its seven-stage tool pipeline. Pi's coding agent ships with four default tools. OpenClaw replaces, augments, filters, normalizes, and wraps them before they reach the LLM.

Base tools - Pi's default coding tools (Read, Bash, Edit, Write)
Custom replacements - OpenClaw swaps Bash for sandboxed exec/process variants and customizes file operations
OpenClaw additions - Messaging, browser, canvas, sessions, cron, and gateway tools are added
Channel-specific tools - Discord thread actions, Telegram commands, Slack workspace tools from plugin directories
Policy filtering - Allowlist/denylist applied per profile, provider, agent, group, or sandbox
Schema normalization - Tool schemas adjusted for provider quirks (Gemini's parameter constraints, OpenAI's tool format)
Abort wrapping - All tools wrapped to respect cancellation signals

Rather than using pi's built-in tools at all, OpenClaw passes everything via customTools with the built-in set left empty. This ensures every tool flows through the full pipeline - policy filtering, sandbox integration, and provider normalization are applied uniformly regardless of origin.

The demo below visualizes this pipeline. Toggle different policy filters and provider targets to see how the tool set changes at each stage.

Figure 4 - Tool Pipeline Flow

Policy:

Provider:

Tools flow through seven pipeline stages. Policy filtering removes tools based on configuration - a restricted profile loses dangerous tools like exec. Schema normalization adjusts tool definitions for each provider's quirks. The final set reaching the LLM depends on both policy and provider.

Why It Matters

Pi and OpenClaw represent a shift in how agent software gets built. Traditional agents are monoliths - they ship with every capability pre-installed, consuming context whether you need it or not. Pi inverts this by treating the agent as malleable software that writes its own capabilities.

This has practical consequences. Pi users do not install extensions from a marketplace. They describe what they want, and the agent builds it - a code review workflow, a task management system, browser automation, multi-agent orchestration. These capabilities are written as code by the agent, stored as extensions or skills, and discarded when unused. There is no dead code, no dependency rot, no extension ecosystem to maintain.

The Extension System

Pi's extensions can register tools available to the LLM, persist state to disk between sessions, render custom TUI components (spinners, tables, pickers), and hot-reload without flushing context. A user might ask pi to build a /review command that branches into a fresh context, reviews code changes, and reports findings with customizable rules. The agent writes the extension, and it becomes part of the workflow.

Agent-Built Software

As Armin Ronacher documented in his analysis of pi, this is "software building software." He does not write his extensions by hand - the agent does, to his specification. Browser automation via Chrome DevTools Protocol, commit message crafting, changelog maintenance, session sharing - all written by pi, tested by pi, maintained by pi.

The broader pattern: OpenClaw's success suggests that embedding a minimal, self-extending agent core is a viable architecture for AI platforms. Instead of building a custom agent runtime, import one. Instead of pre-building every capability, let the agent grow what it needs. Pi provides the engine; OpenClaw proves it can power a production messaging platform across four communication channels.

Open Questions

The self-extension model raises its own challenges. How do you audit capabilities the agent creates for itself? How do you ensure sandboxing when the agent can write and execute arbitrary code? How do you maintain consistency when skills are ephemeral rather than version-controlled? These are active design tensions in both pi and OpenClaw, and different deployments resolve them differently - OpenClaw, for instance, layers sandbox constraints, policy filtering, and abort signals on top of pi's permissive core.