Pi

Start with four core tools and add workflows instead of baking subagents and plan mode into the core

The coding agent exposes read, write, edit, and bash by default. Its README explicitly says Pi skips built-in features such as subagents and plan mode, encouraging users to ask Pi to build the behavior they need or install a third-party Pi package. The interactive environment still provides core coding-agent mechanics such as model switching, session branching, and context compaction, while team-specific approval, review, and integration workflows remain extensions layered on top.

Sources: [2]

Replace tools, add commands and UI, or register providers through the extension system

TypeScript Extensions can subscribe to agent lifecycle events, block or modify tool calls, register custom tools and slash commands, and add custom terminal UI. An extension can even register a tool under the same name as a built-in tool to replace its implementation, enabling patterns such as audit logging, protected paths, Git checkpoints, or project-specific permission gates without forking Pi itself. The lower-level pi-agent-core and pi-ai packages can also be used as SDK building blocks when the agent runtime or unified multi-provider API needs to be embedded in another application.

Sources: [1][3]

For developers who would rather encode their own engineering rules than conform to a coding agent's product workflow

Pi fits developers and teams that want to integrate existing development rules, internal tooling, approval flows, or custom model providers into the agent itself. Its interactive, print/JSON, RPC, and SDK modes also make it useful when the same runtime should serve both humans in a terminal and automated systems such as CI or internal developer tools. It is especially relevant when model providers may change but the surrounding agent workflow should remain under the team's control.

Sources: [2][1]

The flexibility comes with an explicit security responsibility: Pi runs with the permissions you give its process

Pi does not include a built-in permission system for filesystem, process, network, or credential access. By default its tools run with the permissions of the user and process that launched Pi, and extensions execute arbitrary code in the same environment as the Pi process. When stronger isolation is required, the project documents patterns using Gondolin, plain Docker, OpenShell, and Docker Sandboxes to isolate either the entire process or tool execution.

The minimal-core philosophy also means features such as subagents, plan mode, or an organization-oriented permission interface may require additional packages or custom extensions rather than being available out of the box. Teams therefore need to decide which extensions they trust and which tools they expose. Pi itself is MIT-licensed.

Sources: [1][2][3][4][5]