The Pi coding agent’s plugin system (usually called its extension system) is built around a philosophy of minimal core, maximum extensibility, and developer control.

Pi, developed by Mario Zechner, is designed as a programmable agent runtime rather than a fixed coding assistant.

Core principles

1. Minimal core

Pi deliberately keeps its core small. Instead of implementing every feature, it provides a few essential capabilities:

LLM interaction and tool execution.

Conversation and session management.

Context management.

An event-driven extension API.

Features such as subagents, custom workflows, permissions, and integrations can be implemented outside the core.

Principle: Keep the runtime small; move specialized behavior into extensions.

2. Extensions are code, not configuration

Pi extensions are written in TypeScript and execute within the agent process.

They can register tools, commands, event handlers, and UI components.

This is more powerful than declarative configuration because extensions can implement arbitrary logic.

Principle: Prefer programmable behavior over an expanding collection of configuration options.

3. Event-driven architecture

Extensions can react to events throughout the agent lifecycle.

For example:

Before a tool executes.

After a tool returns.

When a user submits a message.

When an agent turn begins or ends.

When the session changes.

This makes it possible to implement policies, logging, custom context injection, and workflow orchestration.

Principle: Expose lifecycle events so extensions can observe and influence execution.

4. Tools are first-class capabilities

Extensions can register tools that agents invoke through structured interfaces.

A tool generally has:

A name and description.

A parameter schema.

An execution function.

A structured result.

The agent decides when to invoke a tool, while the extension controls its implementation.

Principle: Separate the agent’s reasoning from the capabilities it can invoke.

5. Composability

Pi allows multiple extensions to coexist.

Rather than creating a monolithic agent with every feature integrated, developers assemble the functionality they need.

For example, one extension could provide GitHub integration, another could implement approval policies, and another could manage specialized workflows.

However, composability does not automatically guarantee isolation or freedom from conflicts between extensions.

Principle: Build complex agents by combining small, specialized components.

6. Developer ownership

Pi emphasizes that developers should be able to inspect, modify, and replace agent behavior.

Extensions can customize substantial parts of the interaction without requiring modifications to the core.

This includes implementing alternative workflows rather than accepting a predefined agent architecture.

Principle: The framework provides primitives; developers define the product.

Pi’s conceptual architecture

                  Agent

                    │

              Agent Runtime

                    │

           ┌────────┴────────┐

           │                 │

       Event System       Tool Registry

           │                 │

           └────────┬────────┘

                    │

                Extensions

                    │

        ┌───────────┼───────────┐

        │           │           │

     Custom      Workflow     External

      Tools       Logic       Systems

What I find particularly relevant for Seed

Pi makes an interesting distinction between three concepts:

For Seed, I would consider a slightly richer architecture:

Agent → Extensions → Tools → Actions → Distributed Objects

The important distinction is that an extension is not necessarily a tool. An extension can register tools, intercept events, implement policies, or coordinate workflows.

This also raises an architectural question for Seed: Should extensions execute inside the agent runtime, as in Pi, or should they be independent actors communicating through messages?

The second approach could align better with Seed’s distributed-object architecture, providing stronger isolation and independent lifecycles, at the cost of additional complexity.

You can explore Pi’s implementation in the  Pi GitHub repository⁠.

My main takeaway: Pi treats the agent runtime as a programmable substrate, not as a complete application. Its extension system is the mechanism through which developers turn that substrate into specialized agents.