pi Sub-Agents

pi is one of the harnesses a coordinator can spawn a child under (alongside claude and codex). Because pi's own extension model lets a host binary register tools that run inside the pi process itself - no MCP round trip - every pi sub-agent Rensei spawns carries a closed capability pack that gives it the durable mailbox natively, with no configuration.

What "zero-boilerplate" means here

You do not install anything, register an MCP server, or opt a card into anything to get this. Spawn a pi sub-agent through any of the coordinator front-ends and it already has:

• a2a_inbox, a2a_send_message, a2a_complete_task, a2a_list_agents - the same four durable-mailbox verbs documented in A2A Delivery Tiers and Use Rensei from any agent session - registered as native pi tools, with no MCP hop between the tool call and the platform.
• The platform URL, a session-scoped bearer token, its own session id, and its project scope, injected into its process environment automatically alongside its usual credentials.
• A wake-poll loop that periodically checks its own inbox and wakes (or steers, if it's mid-turn) the pi session when something new has arrived - a belt-and-suspenders mechanism on top of the durable floor every harness gets, described further in A2A Delivery Tiers.

The pack is delivered onto every provider rensei agent run spawns, not gated on harness - a harness with no equivalent extension hook simply ignores the delivery, so the same unconditional wiring costs nothing on claude or codex children and activates automatically the moment the child is pi.

What's missing on purpose

Everything above runs entirely inside the pi process once the extension loads - there is no separate installation step, no marketplace listing, and no config file to author for it, unlike the Claude plugin or the Codex config generator. If a pi sub-agent's a2a_* tool calls fail with a connection-shaped error rather than a normal tool refusal, the platform URL or session token did not reach its environment - check how the child was spawned before assuming the pack itself is broken.

Providers

Today, a pi sub-agent authenticates against its model provider through a single pinned credential channel set on its process environment - broader per-org or per-session credential and model-provider selection for pi (matching the breadth other harnesses already have) is a tracked follow-up, not yet shipped. Don't design a coordinator workflow around picking a specific model/provider per pi child until that lands; today's pinned channel is the only one available.

Related pages

• Spawning sub-agents - how to pin harness: "pi" on a spawn request
• A2A Delivery Tiers - the durable floor and wake-nudge mechanism the pack builds on
• Coordinator Overview - the full front-end/child comparison