nicobailon/pi-subagents

If you already code inside Pi and want a second opinion or a separate implementation pass without leaving the conversation, this extension is worth a try. It is not a standalone tool, and its value depends heavily on how Pi's tool activation works in your setup.

The problem

You are working in a Pi session on a diff or a plan, and you want a reviewer, a codebase scout or an implementer working alongside you. Normally that means copying context into another session or model and pasting results back, then reconciling what changed. pi-subagents changes that step: you ask in plain language for a named role, and Pi starts a child session with its own task and returns the result to the parent conversation. The result is that review, recon and implementation work appear as separate streams you can inspect, steer or run in the background.

The extension ships builtin roles such as scout, reviewer, worker and oracle, so the first useful run does not require writing agent configs. The README's recommended loop is clarify → scout → worker → fresh reviewers → worker for implementation work project instructions.

What's different

The mechanism is delegation, not a new model: each subagent is a focused child Pi session, foreground runs stream inside the parent process, and background children run in a detached runner and can be checked later standalone background execution. That split is the practical benefit — slow reviews or multi-round loops no longer block the parent conversation, and a FleetView or fleet inspector lets you browse transcripts and stop a child observability.

There is also a deliberate activation layer. On sessions whose model can accept a new tool mid-conversation, Pi initially exposes a small subagents_enable loader rather than the full subagent schema; the full tool appears on the next model request, while other models start with subagent active to preserve prompt caching toolActivation. This avoids starting an automatic reviewer on install, but it means delegation only happens when your request or instructions authorize it — complexity alone does not. The trade-off is fewer surprises at the cost of a less immediate first run.

For larger orchestrations, the package offers saved workflows, scripted chains, missions and council-style multi-model debates workflows missions and schedules. Custom agents, per-agent models and memory are configured through the documented agent and model references agents models. Web research roles need the child to have web access, and a cumulative spawn cap defaults to 64 per run tree web research prerequisites spawn limit.

Who should try it

A good fit is a developer already using Pi 1.2.0+ who wants a repeatable review-and-implement loop, parallel reviewers on different concerns, or background jobs that keep working after control returns. Someone who only wants a one-off second opinion from a separate chat client will get little from the install.

The documented alternative for background execution matters: npm Pi uses its detached Node runner, while the official Linux x64 standalone release can load the same runner through Pi's embedded SDK without a separate SDK install standalone background execution. Users on other distributions should check whether their setup is covered before relying on background children.

Requirements and limitations

This is a Pi extension, not a general-purpose agent runtime: without Pi there is nothing to install it into, and it needs Pi 1.2.0 or newer. The builtin researcher and evidence-auditor roles need pi-web-access in the child web research prerequisites, and background behavior depends on which Pi distribution you run standalone background execution.

At the configuration level, the most consequential knobs are cumulative spawn limits, active concurrency and per-role model choice; the defaults are documented but only you can decide whether a 64-spawn cap and your model tiering match your workflow spawn limit models. Setup is one install command plus a /subagents-doctor check, but ongoing care includes choosing which sessions authorize delegation and reviewing background runs rather than assuming they are correct. The README does not describe cost controls per run, so budget-facing behavior is something to verify in your own setup.

HotRepo's take

The only dated signal available is 2026-10-26, when the repository appeared on the daily board with 4,071 stars and +31 that day. One tracked day cannot establish persistence, so treat the interest as observed once rather than as a trend; the repository was created in January 2026.

Adoption judgement: try it if Pi is already your coding environment and you want role-based delegation; first verify that your Pi version and distribution support background children and that tool activation matches your model's caching behavior toolActivation.