Hiring & delegation
How the org grows itself — auto-hire on decomposition, explicit HIRE[], DELEGATE[] down the reporting tree, consultants, and the roster.
An org isn’t a fixed team. It employs the agents it needs and hands work down its reporting tree — then reviews and integrates what comes back. Two mechanisms do this: hiring (add headcount) and delegation (route work to existing reports).
The roster
agents/roster.json is the living ledger of employed agents. It’s seeded from
the agent definitions on first boot, then becomes the source of truth — so
hires and departures survive restarts. Every hire and fire is audited and
shown in the dashboard roster.
Hiring — two paths
Both are capped by maxAgents (default 16) and gated by the hire capability.
Auto-hire on decomposition
When the lead’s plan assigns a task to a role the team lacks, the coordinator hires a specialist for it. The plan can pick the hire’s brain:
{ "title": "Build the API", "assignee": "Engineer", "model": "claude-sonnet-4-6", "effort": "low" }
Otherwise the hire inherits the org default brain.
Explicit HIRE[...]
The lead or a manager can deliberately employ a specialist by emitting a line in its task output — this is how a CEO-only org bootstraps a whole team:
HIRE[<role>]: <their mandate>
HIRE[<role> | model=<model> effort=<low|medium|high|xhigh|max>]: <mandate>
The new agent joins as a direct report, so the same task can then
DELEGATE[...] to it and it lands in one cycle (hires run before
delegations). Hiring is gated by the hire capability, offered only to the
lead/managers, suppressed on integration tasks, and deduped by role among a
manager’s reports — so repeating a HIRE across cycles can’t runaway-grow the
team. The hire’s brain is persisted on the roster.
Delegation — delegate-then-depend
A manager hands a scoped subtask to one of its employed reports by emitting:
DELEGATE[<id or role>]: <subtask>
On acceptance the runtime does two things:
- Creates a board task per delegation, assigned to the report and tagged
delegatedBy(the manager) andparentTaskId(the delegating task), atdepth + 1. - Queues the manager’s integration follow-up —
kind: 'integration', depending on the delegated tasks — so it runs once the reports report back and gets their output as upstream context to integrate.
So the report does the work, the manager reviews it (manager-routed review), and the follow-up integrates what came back rather than delegating blind.
The rules that keep it sane
Each of these fixes a specific failure mode:
- Direct reports only. Targets come from one level of the tree, so work descends a level at a time — a top manager can’t dump on distant grandchildren and skip the intermediate managers who should route and review.
- Ambiguous role targets are rejected, not first-matched. Because the org
auto-hires role-named specialists, “delegate to
engineer” with several engineers would be arbitrary; the manager re-delegates by id. - The integration step shares the delegating task’s depth (not
depth+1), so the depth cap bounds real delegation chains rather than integration steps — and an integration task is suppressed from re-fanning-out. - Integrated output reaches consumers. Tasks that depended on the manager’s original task are re-pointed to depend on the follow-up instead, so downstream work builds on the integrated result.
- Deep results roll up. A multi-level tree reduces correctly: a grandchild’s work flows up through each integration step instead of being dropped one level up.
Fan-out is capped (maxDelegations, default 3) and chain depth is bounded
(maxDelegationDepth, default 2).
Consultants — the Task tool
Separately from employees, an agent can spawn Claude’s built-in sub-agents
(the Task tool, gated by the consult capability) for focused help. These are
consultants, not employees: ephemeral, never on the roster, and their cost
rolls up to the agent that hired them. Use delegation when you want tracked,
reviewed work by a real report; use a consultant for a quick, in-task assist.
What happens when an agent leaves
When an agent is fired or the roster shrinks, the org re-homes its open work
so a departure can’t strand the scheduler: reports are re-anchored to the
departed manager’s manager, and delegatedBy is re-routed so review stays in the
chain. Any open task assigned to the departed agent is reassigned or parked
blocked — never left to throw the batch.
Manual hire/fire buttons in the dashboard are a planned addition; today the org grows and shrinks itself through the mechanisms above.