Orchestrator

The orchestrator is the root agent. It receives every user request, decides how to handle it, and either answers directly or delegates to a team lead. Every surface in the app — Today, Inbox, Dashboard, chat — boots an orchestrator.

It sits at the top of a fixed three-tier structure of 14 agents:

Orchestrator                      (1 · routes + cross-module reasoning)
├── CRM · Projects · Finance · HR         ┐
├── Content · Social · Analytics          ┘  7 domain leads (module tools)
    └── 6 specialists                        multi-step write workflows
        (Invoice Builder, Project Scaffolder,
         Entity Linker, Campaign Builder, Onboarding,
         Proposal Drafter)

The tiers are concrete, not dynamic — there is no open-ended "spawn any agent" mechanism. The orchestrator reasons and routes; the eight leads own their module's data; five specialists run the fiddly multi-step writes. See Subagents.

What it sees

When the orchestrator starts, its system prompt has been assembled by the platform into a strict sequence:

<system instructions: role, defaults, hard constraints>

<USER namespace>      ← who's asking
<MEMORY namespace>    ← what's happened
<SKILLS namespace>    ← how to do things
<TASKS namespace>     ← what's pending

<tool definitions>    ← what tools are available

This layout is deliberate. USER first so identity sets the frame. MEMORY next so recall is on top of mind. SKILLS so the playbook is visible before it's needed. TASKS last so pending work surfaces without dominating attention.

The user's actual question comes in as the first user-role message. Anything previously in the conversation is in the message history.

The decision loop

For each turn, the orchestrator:

Reads the assembled context + new user message.
Decides — answer directly, call a read tool, or delegate to a team lead.
If tool call — emits a tool call, receives the result, loops back to step 1 with the result in context.
If delegate — calls the relevant delegate_to_<module>_lead tool with a plain-language task + context brief; awaits the lead's return (see Subagents).
If answer — emits final text, optionally with a planned action attached (which goes into TASKS for confirmation).

Streaming starts at step 5. Earlier steps run server-side without emitting text — only the final answer + structured tool-call events stream to the UI.

Tool selection

The orchestrator has a fixed toolset on every run — read/reasoning tools plus one delegation tool per module:

Tool	Purpose
`quick_lookup`	Direct single-table read (e.g. "how many open deals?") without delegating.
`graph_search`	Find entities by question. Vector + fuzzy hybrid over the knowledge graph.
`graph_traverse`	Walk typed edges between entities (multi-hop).
`graph_context`	Pull the neighbourhood around an entity for grounding.
`graph_add_edge`	Record a new typed relationship between two entities.
`project_margins`	One-call retainer profitability (invoiced revenue − logged time cost) per project.
`import_mapping`	Map an external source's fields onto the typed graph during onboarding.
`memory_propose`	Propose a durable memory for the tenant's MEMORY namespace.
`delegate_to_<module>_lead`	Hand a task to one of the 7 domain leads (crm, projects, finance, hr, content, social, analytics).

The orchestrator does the cross-module reasoning itself — the flagship "which late invoices are on stalled projects?" is a graph traversal it runs directly, then it delegates the writes to the lead that owns them.

Model

Cloud runs the orchestrator on Claude Sonnet 5 (claude-sonnet-5), with Haiku 4.5 reserved for lightweight, high-volume sub-steps. Every agent in the registry defaults to the same model; there is no per-turn cost-routing across a fleet of providers.

Self-host swaps the model through the provider adapter layer (clients/adapters/*) — bring your own Anthropic or OpenAI key, or run a local model via Ollama. The abstraction exists precisely so the model is a configuration choice, not a code change. See Self-host BYO key.

Tool-calling cadence

Multi-round, bounded. The orchestrator runs up to 5 tool-use rounds in one user turn before it must produce a final answer — a safety limit that leaves room for genuinely multi-step tasks while capping runaway loops.

Within a single round the model may request several tools at once (e.g. graph_search across a few entity kinds). The platform runs them in order and returns the results together as one tool_result block, so the model sees a coherent batch on the next round.

Evidence, not enforcement

Answers are grounded in what the agent actually read. Cross-module claims come from real graph_search / graph_traverse calls, and the records touched are surfaced as citations in the UI — click a number, the citation drawer opens with the rows behind it.

This is evidence by construction, not a post-hoc grader: there is no separate pass that re-runs the model to force citations. The contract the platform does enforce is on the write side — see below.

Writes: planned, hashed, confirmed

The orchestrator never executes a write. When an action is warranted it (or the lead it delegates to) emits a planned action into TASKS. Before it reaches you, the action set is serialized and SHA-256 plan-hashed; the /confirm endpoint re-hashes at execution time and rejects on any mismatch — so nothing can change between the preview you approved and the write that runs.

Autonomy is scoped per tool. Reversible, internal writes can run unattended in automations; anything that touches money, people, or a client is gated and withheld from unattended runs entirely. See Subagents → Autonomy for the classes.

Error handling

Tool failures are returned to the orchestrator as tool_result blocks with an error field. The orchestrator can:

Retry once with adjusted parameters.
Skip and answer with partial data, flagging the gap.
Surface a "tool failed" message asking the user how to proceed.

Transient LLM errors (rate limit, 5xx) are retried inside the client before the orchestrator ever sees them; it gets a clean response or a final error after retries are exhausted.

Telemetry

Every orchestrator run emits a structured turn trace:

Run id, tenant id, user id, surface.
Assembled context size + breakdown (USER, MEMORY, SKILLS, TASKS).
Tool calls with timing + result sizes.
Lead/specialist delegations with depth + outcome.
LLM tokens in/out.
Final answer length.
Plan hash if a planned action was emitted (for dedup + /confirm).

You can see your own runs at Settings → Agent runs. Admins see all runs in their tenant. Cross-tenant aggregates power the benchmarks flow (cloud only, k-anonymized).