Subagents

A subagent is a focused agent the orchestrator (or a team lead) delegates to. It inherits the run's namespaces but works from a tighter brief and a narrower tool set. There are two concrete kinds, and the registry is fixed — not open-ended:

Tier	Agents	Role
Domain leads (7)	CRM, Projects, Finance, HR, Content, Social, Analytics	Own their module's read + write tools.
Specialists (6)	Invoice Builder, Project Scaffolder, Entity Linker, Campaign Builder, Onboarding, Proposal Drafter	Run one multi-step write workflow well.

The orchestrator delegates to a lead; a lead may delegate a fiddly multi-step write to one of its specialists. That's the whole topology — two hops at most.

When delegation happens

The orchestrator delegates to a lead when the work belongs to a module's data — anything that reads or writes CRM, projects, finance, HR, content, social, or analytics records. It keeps the cross-module reasoning for itself (traversing the graph to answer "which late invoices are on stalled projects?") and hands the lead the part that touches that module's tables.

A lead delegates to a specialist when a task is a known multi-step write — building an invoice with line items, scaffolding a project with starter tasks, creating a company + contact + the graph edges that link them. One-shot writes the lead does inline; the specialists exist for the sequences where order and completeness matter.

Delegation has real overhead (a fresh model round-trip and context), so trivial work is never delegated — it's cheaper inline.

How a lead is invoked

Delegation is a named tool call, not a generic dispatcher. The orchestrator's toolset carries one delegate_to_<module>_lead tool per module; a lead that owns a specialist carries a delegate_to_<specialist> tool. Each takes two plain-language strings:

delegate_to_finance_lead(
  task    = "Draft an invoice for Cedar & Bloom, 4,000 USD, July design work",
  context = "company_id=…, contact_id=…, prior thread: …"
)

There is no formal output-schema contract. The subagent does its work and returns a text result, which the caller reads back in-context. Any records it creates are tracked in a shared execution context so IDs created upstream (a new company) resolve as foreign keys downstream (the contact that links to it) within the same run.

What a subagent inherits

Inherited	From the caller
USER namespace	Identical — same identity, preferences, profile context.
TASKS namespace	Identical — planned actions are global to the run.
MEMORY / SKILLS	Assembled for the sub-brief.
Tool set	Narrower — only the tools the subagent's spec lists.
Run id, tenant id	Same — telemetry and tenant isolation stay intact.
Execution context	Same — for cross-agent foreign-key resolution.

Autonomy: the write-safety line

Subagents are where writes actually happen, so autonomy is scoped per tool, not per agent:

Class	Examples	Unattended (automation) behaviour
`autonomous`	reassign a task, tag a contact, update an internal record, scaffold a project	Executes. Reversible, internal, low blast radius.
`gated`	create/void an invoice, mark paid, change an expense, publish externally, any delete	Withheld. Emits a planned action → your approval → the plan-hash `/confirm` path.

The default is gated — a new write tool is safe until someone deliberately opens it. When an agent runs unattended (an automation firing on a schedule, with no human on the confirm dialog), gated tools are removed from its tool set entirely: it cannot call what it cannot see. Attended runs, where you're on the other end, see everything and confirm the gated ones. Money, people, and client-facing actions stay in your hands by construction.

Execution order

Within a round the model may request several tools; the platform runs them in order and returns the batch together. Delegations resolve one at a time — a lead finishes and returns before the orchestrator proceeds. Each run is bounded to 5 tool-use rounds at every tier, so a delegation chain has a hard, predictable ceiling.

Cost accounting

Every subagent's token usage rolls up into the parent run's totals. You can see the breakdown in Settings → Agent runs → <run> → Token breakdown — useful for seeing where spend goes (a specialist that builds a full invoice typically dominates the run that called it). The per-tenant agent-run quota (cloud tier-aware; self-host operator-configurable) covers the whole tree — a subagent gets no separate budget.

The six specialists

Specialist	Lead	Does
Invoice Builder	Finance	Creates a draft invoice, then each line item, computing subtotal/tax/total.
Project Scaffolder	Projects	Creates a project, then its tasks (with sensible starter tasks + due dates).
Entity Linker	CRM	Creates a company/contact/deal and wires the typed graph edges between them.
Campaign Builder	Social	Creates a campaign, then per-platform posts with scheduled times.
Onboarding	HR	Creates an employee record, resolving department by name, with sensible defaults.
Proposal Drafter	CRM	Drafts a proposal for a deal from graph evidence (past projects, margins, outcomes); every claim cites its evidence.

Content and Analytics leads have no specialist — their work is single-step reads and writes they handle inline. The registry is fixed in code; there is no runtime "new subagent kind" promotion.

Self-host note

Self-host runs the same orchestrator → lead → specialist pattern as cloud. The only variable is the model behind the provider adapter layer: tool-calling quality varies by model, and delegation chains lean on reliable structured tool-calling. Anthropic and OpenAI models handle it well; very small local models can be less reliable on long chains. Pick the model in your deployment config. See Self-host hardware.