> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cloudthinker.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Chapter 4 · Orchestration and Two-Engine Economics
> Multi-agent is not a philosophy; it is a set of engineering trade-offs about context, credentials, latency, and cost.
*Multi-agent is not a philosophy; it is a set of engineering trade-offs about context, credentials, latency, and cost. This chapter is the mechanics behind the reference architecture.*
## 4.1 What the orchestrator actually does
Strip the org-chart metaphor and the orchestrator is five concrete responsibilities: intake (normalize goals, incidents, and events into tasks); decomposition and routing (decide what the task needs and which specialist owns each part); context management (give each specialist the subset of context its subtask needs — the single biggest cost and quality lever in a multi-agent system); integration (reconcile specialist findings into one evidenced conclusion, including when they disagree); and escalation (own the conversation with humans — approvals, notifications, the incident record). Specialists extend the orchestrator; they never compete with it. That design keeps one audit trail, one approval surface, and one place where “what is the system doing right now?” has an answer.
The published evidence cuts both ways, and honest engineering uses both halves. Anthropic’s account of its multi-agent research system reports large quality gains from an orchestrator-worker pattern with parallel specialists — at materially higher token cost. Microsoft’s SRE Agent team reports the opposite correction: collapsing dozens of micro-agents and a hundred-plus tools into a few generalists with core tools. The synthesis this series has argued from the start: specialize by operational domain and credential boundary — cloud, security, database, Kubernetes — because those boundaries pay for themselves in least-privilege and depth; resist fragmenting further, because every additional agent is coordination overhead, duplicated context, and another thing to evaluate.
## 4.2 Handoffs are contracts
The failure point of multi-agent systems is rarely a specialist’s competence; it is the handoff. Engineer handoffs as typed contracts, not chat: a delegated subtask carries objective (what question to answer or outcome to achieve), scoped context (what the specialist gets to see), budget (steps, tokens, time), and return schema (findings with evidence pointers, confidence, and explicit “what I did not check”). The orchestrator’s integration step then has structured inputs to reconcile — and the audit trail records who concluded what from which evidence, which monolithic reasoning hides. Parallelism falls out naturally: independent subtasks fan out concurrently (latency win), but only when their write-scopes cannot collide; concurrent mutations to one estate are a race condition with an apology attached.
> *Figure 2 — A delegation contract: objective, scoped context, budget, and return schema. Handoffs are typed; integration is evidenced; the audit trail survives.*
## 4.3 The two-engine economics, quantified
The Field Guide introduced the pattern qualitatively: a cheap, always-on sensing engine and an expensive, on-demand resolver engine. The Engineer Edition’s job is to make you compute it. The naive design — frontier reasoning on every signal — fails arithmetic: thousands of daily signals × a multi-step reasoning pass each is a model bill that erases the program’s ROI before its first renewal, and “unbounded model spend” is one of the documented ways agentic projects die. The two-engine design changes the equation structurally:
| | Sensing engine (“pulse”) | Resolver engine |
| ------------ | ------------------------------------------------------ | -------------------------------------------------------- |
| Runs | Continuously, on every signal | On demand, when sensing promotes an event |
| Work | Ingest, dedup, correlate, policy-filter, enrich, score | Full investigative loop: hypotheses, tools, plan, verify |
| Compute | Streams + rules + small/cheap models | Frontier or fine-tuned models, tens of steps |
| Cost shape | Near-flat with signal volume | Linear with promoted incidents only |
| Failure mode | Misses or over-promotes (tune with evals) | Expensive wandering (budgets, Ch. 1) |
Instrument the seam: promotion rate (what fraction of signals wake the resolver), cost per promoted investigation, and cost per resolved incident. Those three numbers are your unit economics, they belong on the Chapter 8 dashboard, and they are the honest answer to “what will this cost at our scale?” — a question you should never let a vendor answer with a shrug. A second-order lever on the same seam: routine daily operations do not need frontier reasoning. Fine-tuned small models running the high-volume, well-understood work — with frontier models reserved for novel investigation — cut the resolver line further and, for regulated buyers, compose with self-hosted deployment for full model control.
**IN PRACTICE — DRE: PULSE + RESOLVER**
CloudThinker’s Deep Response Engine is this pattern shipped as the flagship: Pulse ingests and filters the event stream continuously (Redis Streams + time-series storage under the hood); the Resolver Engine spins up the full DARV investigation only for promoted events, inside a sandboxed runtime, with per-incident budgets. The tagline is the architecture: they see, we act, we learn. Whatever platform you evaluate, ask for its promotion rate and its cost-per-resolved-incident at a reference scale — if it cannot answer, it has not run at scale.
## 4.4 State: the incident record as shared truth
Multi-agent systems need one durable, append-only record per task: the timeline of signals, hypotheses, tool calls, evidence, decisions, approvals, actions, and verifications. Everything reads from it; everything writes to it; humans join it mid-flight and see the same truth the agents see. Engineering it as an event log (rather than mutable chat state) buys you replay for evaluation (Chapter 7), a natural audit artifact (Chapter 6), and crash-safe resumability — an agent that dies mid-investigation resumes from the record, not from amnesia.
**KEY TAKEAWAY**
Orchestration is intake, routing, context allocation, integration, and escalation — with handoffs as typed contracts and one append-only incident record as shared truth. Economics are a design input: two engines, measured at the seam, with cost per resolved incident as the number that decides whether 24/7 agentic coverage is viable at your scale.