@saifymatteo/pi-orchestrator
Simple agent orchestration for pi coding agent (pi.dev)
Package details
Install @saifymatteo/pi-orchestrator from npm and Pi will load the resources declared by the package manifest.
$ pi install npm:@saifymatteo/pi-orchestrator- Package
@saifymatteo/pi-orchestrator- Version
0.11.0- Published
- Oct 26, 2026
- Downloads
- 1,370/mo · 397/wk
- Author
- saifymatteo
- License
- MIT
- Types
- extension
- Size
- 587.4 KB
- Dependencies
- 1 dependency · 5 peers
Pi manifest JSON
{
"extensions": [
"./src/index.ts"
]
}Security note
Pi packages can execute code and influence agent behavior. Review the source before installing third-party packages.
README
pi-orchestrator
A pi extension that turns the main agent into an orchestrator. While engaged, the parent keeps a configurable tool allow-list and delegates work to subagents with isolated contexts. You describe the task; the orchestrator picks agents, dispatches work, and receives their results.
Disclaimer
This project is written entirely by GLM 5.3 Flash via the pi harness. It intentionally disables most main-agent capabilities and forces delegation to a subagent fleet.
Quickstart
Requires Pi >= 1.0.4. Install from npm:
pi install npm:@saifymatteo/pi-orchestrator
Start Pi in your project:
cd <path-to-your-project>
pi
Ask for a task in natural language, for example:
Have scout find how configuration is loaded in this project, then ask planner to propose tests for the fallback behavior. Return a short plan with file references; don't edit anything.
The builtin fleet is ready to use; no configuration file is required. Async dispatches return acceptance first, then deliver outcomes into the conversation. Accepted work may be queued, not yet running. The fleet widget shows queued and active work, progress, and pending or failed delivery. You can keep talking or dispatch more work without polling.
For git/local installs and testing a checkout, see Development.
Engaged vs AUTO
Orchestration starts engaged by default:
| Mode | Parent tools | Delegation |
|---|---|---|
| Engaged | Effective keep-list only; delegate is always available |
Real work goes through Workers. |
| AUTO (disengaged) | Normal tool access; no delegation policy | delegate remains available when useful. |
Child tool policy applies to every delegated spawn in either mode. Workers do not orchestrate further.
/orchestratortoggles engagement and persists it in the selected configuration file; startup notifies when disengaged./orchestrator-toolsopens the TUI's per-tool allowed/blocked editor. It saves individual overrides, never rewrites the baselinekeepTools, and shows discovered extension groups read-only. Choosing the baseline result removes the override. Long lists truncate to terminal width (at most 6 names plus+N more).
See parent tool access for matching rules, overrides, and safety caveats.
Builtin fleet
| Agent | Role | Shipped thinking level |
|---|---|---|
scout |
Read-only reconnaissance | low |
planner |
Read-only planning | high |
worker |
General-purpose work, full tools | medium |
reviewer |
Read-only tools plus shell, code review | high |
User and project agents shadow builtins by name. Define custom agents or tune the builtin fleet.
Dispatch and results
delegate supports single jobs, parallel tasks (up to 8 per request), and sequential chains. Single/parallel dispatches are async by default; pass async: false to return the outcome directly. Chains always block. All modes share one live-session capacity pool (default: 4 active Workers, 32 queued runs).
Discovery/control actions include list, sessions, status, cancel, and retry-delivery. Cancellation of one run returns or delivers a cancelled outcome; Escape and session teardown stop the fleet and suppress pushes into that interrupted session. Async delivery retains unconfirmed outcomes, with explicit retry rather than automatic blind retries. It does not promise restart recovery, disk durability, or exactly-once insertion.
Extension integration (Pi 1.3.0): other extensions in the same parent session can tap into our agent-result mechanism through the async-work:providers:v1 event-bus protocol. Emit a discovery request to obtain the agent provider, then claim and collect results through its lease API. No specific consumer extension is required or added as a dependency. See Event-bus integration for the protocol and an example.
Optional pi-atelier fleet panel
With pi-atelier supporting sidebar contributions installed, Orchestrator Fleet (orchestrator:fleet) is available through its public pi-atelier:sidebar-panels protocol v1. The integration adds no dependency: pi-atelier is not required. The sidebar has its own compact layout, separate from the live transcript-area fleet widget.
New panels start hidden. To enable this one:
- Open
/atelier→ Settings → Display (or run/atelier display). - Enable Orchestrator Fleet.
The panel uses the existing watcher fleet projection: idle AUTO/ENGAGED status, queued and running Runs, turns, context, tokens, and pending or failed Result delivery. Its compact sidebar layout uses left-aligned structured text rows, not label/value (keyValues) fields, and omits task and prompt excerpts. Idle shows AUTO · idle or ENGAGED · idle followed by a bullet roster (• scout, • worker), or (empty fleet) when no agents are available, without a redundant Fleet heading. The active sidebar puts the dispatch title and status counts on separate rows; the detailed widget keeps its single-line header. Atelier clips rows to the available width rather than wrapping them. It does not integrate with Atelier's native Subagents cost graph.
The live transcript-area widget stays visible by default (showFleetWidget: true). To use only the sidebar, enable it first, then set "showFleetWidget": false in your selected configuration file and start a new session. This hides only the live widget: Result messages, acceptance messages, and transcripts are unaffected. Handoff is manual; consumer discovery never hides the widget because the sidebar protocol has no visibility acknowledgement. Restore true if you disable or remove the sidebar. See Fleet displays for the recipe.
Guides
- Configuration: schema/editor help, parent and child tools, extension control, models, thinking, budgets, and optional guardrails.
- Usage: dispatch examples, actions, lifecycle guarantees, event-bus integration, delivery, cancellation, and session ids.
- Custom agents: frontmatter, discovery directories, and precedence.
- Development: alternative installs, architecture, schema maintenance, lifecycle verification, and file map.
- Architecture decision records: design rationale and contracts.