How it runs

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:

  1. Creates a board task per delegation, assigned to the report and tagged delegatedBy (the manager) and parentTaskId (the delegating task), at depth + 1.
  2. Queues the manager’s integration follow-upkind: '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.