Coordinator Overview
What a Rensei coordinator is, the tool vocabulary it shares across front-ends, and which front-end to use.
Beta. The tool vocabulary below is live on both MCP doors. The tenant-wide swarm observability view (a lineage-aware dashboard across everything you've spawned) has not shipped yet - see Spawning sub-agents for what's available today instead.
A coordinator is any agent session - human-attended or headless, running on the platform or on your own machine - that spawns, steers, and observes other Rensei-hosted sessions as children. The children can run any harness the platform supports; the coordinator itself is usually Claude Code or Codex, on- or off-platform.
Every front-end talks to the same six spawn/lifecycle tools plus the four durable-mailbox tools underneath them - only how you connect and how you hear back differ.
The shared tool vocabulary
| Tool | What it does |
|---|---|
dispatch_child | Spawn a child session under you. |
watch_session | Live status of one session plus its direct children. |
replay_session | Fetch a session's recorded terminal-session pointer. |
cancel_session | Cooperatively stop a session you directly spawned. |
get_session_receipt | Lineage-aware subtree rollup: count, per-status tally, max depth. |
steer_child | Inject a message as a direct child's next turn. |
a2a_list_agents / a2a_send_message / a2a_inbox / a2a_complete_task | The durable, address-by-handle mailbox every session (spawned or not) can use to reach any other. |
The six spawn/lifecycle tools are documented in full - including the credential model, the authority-ceiling narrowing rule, and the typed refusal codes - in Spawning sub-agents. The mailbox tools' delivery guarantees are documented in A2A Delivery Tiers.
Both MCP doors - the on-platform per-session endpoint and the off-platform external facade - serve the identical tool names, schemas, and result shapes from one shared module, so a coordinator built against one door works unmodified against the other. Only caller resolution differs: on-platform, your own session's lineage row is the source of authority; off-platform, you present a spawn credential explicitly.
Choosing a front-end
| Front-end | Where it runs | Tool access | Live delivery |
|---|---|---|---|
| Claude, on-platform | An interactive session the platform launched | Automatic - server-injected on your own session's MCP endpoint, no install | Best-effort heartbeat wake only (see delivery tiers) |
| Claude, off-platform (plugin) | Your own machine, Claude Code CLI | Rensei Claude Code plugin (MCP server + optional channel) | A fallback ladder from best-effort channel push down to durable poll |
| Codex | Either - generated config.toml MCP wiring | Generated MCP server block, optional subagent | Poll-only; steering into a busy Codex child is not yet automatic |
None of the three front-ends grants a coordinator more authority than its own session already has - every child's capability is a narrowed subset of its parent's, enforced server-side regardless of which front-end dispatched it. See Spawning sub-agents for the ceiling model.
If the sub-agent you're spawning is a pi sub-agent specifically, its capability surface (which of the mailbox tools it gets for free, what "zero-boilerplate" means for it, and its current provider story) is documented separately: pi sub-agents.
Related pages
- Spawning sub-agents - the six-tool vocabulary in depth
- pi sub-agents - the pi capability pack
- A2A Delivery Tiers - what "delivered" actually means today
- Use Rensei from any agent session - the general external-facade doc this vocabulary extends
A2A Delivery Tiers
What "delivered" actually means for agent-to-agent messages today: the durable floor, the best-effort wake nudge, and what's coming per harness.
Spawning Sub-Agents
The six-tool spawn/lifecycle vocabulary, the credential and authority-ceiling model, typed refusal codes, and per-child customization.