4.1 What the orchestrator actually does
The orchestrator is the agent that receives the work, splits it up, and owns the result. Strip away the org-chart metaphor and it has five jobs:
Helpers extend the orchestrator. They never compete with it. That gives you one audit trail, one approval surface, and one place that can answer “what is the system doing right now?”
The published evidence cuts both ways (sources in Appendix D). Anthropic reports that a multi-agent system (a Claude Opus 4 lead with Claude Sonnet 4 helpers) outperformed a single Claude Opus 4 agent by 90.2% on its internal research eval, while multi-agent systems used about 15 times more tokens than chat. Microsoft’s Azure SRE Agent team went the other way, collapsing many micro-agents and more than a hundred tools into a few generalists with core tools.
Use both lessons:
- Split along credential and domain boundaries such as cloud, security, database, and Kubernetes. Those splits pay for themselves in least privilege and depth.
- Don’t split further. Every extra agent adds coordination overhead, duplicated context, and another thing to evaluate.
4.2 Handoffs are contracts
Multi-agent systems rarely fail because a helper is bad at its job. They fail at the handoff. Treat a handoff as a typed contract, not a chat message:
With structured returns, the integration step has something concrete to reconcile, and the audit trail records who concluded what from which evidence. A single long reasoning chain hides that.
Parallelism follows naturally. Independent subtasks can fan out at the same time to cut latency, but only when they can’t write to the same thing. Two helpers changing one system at once is a race condition.
IN PRACTICE: SUBAGENTS IN CLOUDTHINKERCloudThinker uses one built-in assistant, also called CloudThinker, as the orchestrator. For focused work it spawns temporary subagents: short-lived helpers that each get one bounded objective and never talk to you directly. See Agents.
- During an incident investigation, CloudThinker hands focused checks (logs, metrics, traces, recent changes, dependencies) to subagents and merges their results into one verdict. See Investigation and RCA.
- By default, a subagent is refused any tool that changes your systems. Changes stay with the orchestrator, where Approvals applies.
- When a subagent fails, the parent gets a fixed failure code, a short redacted message, and one suggested next action, so it can recover instead of guessing:
4.3 The two-engine economics, quantified
The Leadership Edition described the pattern in words: a cheap, always-on sensing engine and an expensive, on-demand resolver engine. Here you compute it. The naive design runs frontier-model reasoning on every signal. At thousands of signals a day, each with a multi-step reasoning pass, the model bill erases the return before the first renewal. Unbounded model spend is one of the documented ways agentic projects get cancelled. Two engines change the shape of the cost:Measure the seam
Three numbers are your unit economics. Put them on the Chapter 8 dashboard:
A worked example with made-up round numbers (not CloudThinker prices):
Halve the promotion rate to 0.25% and resolver spend drops to $100, so cost per resolved incident falls toward $3.75 if the same real incidents still get through. Raise signal volume tenfold at the same promotion rate and the sensing bill barely moves, but resolver spend grows to $2,000 a day. That’s why promotion rate is the dial to watch.
A second lever on the same seam, as a general pattern: routine, well-understood daily work doesn’t need frontier reasoning. Small fine-tuned models can handle the high-volume cases, with frontier models kept for novel investigations. Regulated teams often pair this with self-hosted deployment for full control of the model. In CloudThinker, the closest levers are model tiers (keep routine work on Light, see Usage and credits) and a self-hosted or air-gapped deployment, which is in early access through a design-partner program (Deployment options).
IN PRACTICE: PULSE AND INVESTIGATIONS IN RESOLVEResolve, CloudThinker’s incident response module, ships this split.
- Sensing: Pulse. Pulse takes every alert your tools send, drops noise with four checks in order (dedup, rate limit, snooze, and learned noise verdicts; see noise suppression), groups related signals into clusters, classifies each cluster, and files an actionable one as an incident with status Open. Pulse stops there: it never triages or investigates.
- Resolving: investigation. Investigations run only on incidents. You control what wakes the resolver with Auto-investigate and Only from a minimum severity on each webhook under Resolve → Integrations, and the On duty switch under Resolve → Investigation. See Resolve settings.
- Measuring. Open Resolve → Insights and the Pulse analysis tab (Pulse analytics). Signals ingested is your denominator. Correlation yield (signals whose cluster was linked to an incident or resolved, divided by all signals) is the closest built-in figure to promotion rate; it also counts clusters that resolved without an incident. Noise suppressed shows what sensing filtered out.
- Costing. Credits aren’t shown per investigation. Admin Settings → Usage, under By Feature, shows which capability used the credits over a time range; divide by the investigations in that range for an average cost per investigation (Usage and credits).
- Capping spend. Credit limits set a monthly budget per workspace, with Throttle or Notify only when it’s reached.
4.4 State: the incident record as shared truth
A multi-agent system needs one durable, append-only record per task. It holds the timeline of signals, hypotheses, tool calls, evidence, decisions, approvals, actions, and verifications. Every agent reads from it and writes to it. A human who joins mid-flight sees the same truth the agents see. Build it as an event log, not as mutable chat state. That buys you three things:- Replay for evaluation (Chapter 7): rerun a past incident against a new model or prompt and compare.
- An audit artifact for free (Chapter 6): who did what, on which evidence, with whose approval.
- Crash-safe resumption: an agent that dies mid-investigation resumes from the record instead of starting over.
IN PRACTICE: ONE RECORD PER INCIDENTIn Resolve, an incident has one investigation record. Each new session, started by a person or automatically, adds its steps to the same Investigation timeline under a session marker. If the conclusion changes, the timeline records a root-cause revision instead of creating a second report, and earlier sessions stay under More actions → Earlier sessions. Click Watch live to follow the conversation where CloudThinker is working. See Investigation and RCA.
Next steps
Chapter 5 · The Threat Model
Why an operations agent is an attack surface, and the layered defenses that contain it.
Pulse overview
See how Resolve filters alerts before any investigation starts.