The Chief-of-Staff Pattern: When to Orchestrate Agents and When to Just Write a Script

The case against defaulting to swarms

A common failure mode in agent engineering is reaching for a swarm before reaching for a function. A task is decomposed into roles, a supervisor is added, and the system is declared "agentic". What has actually been built is a distributed system with a language model in the loop, and the costs are the familiar costs of distribution plus the unfamiliar costs of non-determinism.

Every additional agent introduces a handoff. At each handoff, the producing agent serialises its state into text and the consuming agent deserialises it back into context. That round trip is lossy. A structured result with a confidence score, a source reference, and a partial failure flag becomes, in prose, a sentence that omits all three. The loss is not random; it correlates with exactly the information a downstream agent needs to decide whether to proceed, retry, or escalate.

Coordination overhead also grows faster than the decomposition saves. If a task takes T units of work and splits into n subtasks, the ideal saving is roughly T/n. The coordination cost is not T/n; it is the sum of handoffs, each of which requires a prompt, a model call, a parse, and a validation. In practice, adding agents past the point where subtasks are genuinely independent produces a system that is slower, more expensive, and harder to debug than the single call it replaced.

The deepest problem is testability. Deterministic code can be unit tested. A function that takes a typed input and returns a typed output has a contract you can assert against. An orchestrator prompt does not. You can evaluate its outputs on a dataset, and you should, but you cannot write a test that fails when the orchestrator silently changes its routing policy between model versions. The prompt is a specification expressed in a language with no compiler.

This is not an argument against multi-agent systems. It is an argument against treating them as the default. The chief-of-staff pattern, as described in this write-up on orchestrating Claude Code sessions, is useful precisely because it names the conditions under which a coordinating layer earns its keep.

Signals that justify orchestration

Three signals, in practice, distinguish a task that needs an orchestrator from one that needs a script.

Disjoint tool sets or disjoint contexts

If subtask A needs read access to a codebase and subtask B needs write access to a deployment target, they need different tool sets. A single agent holding both tools must be trusted with both, and its context must carry the schemas, credentials, and failure modes of both. Splitting them means each agent's context is smaller and its authority is narrower. The same argument applies to context windows: if the raw material for one subtask would consume most of the window, and the raw material for another would consume the rest, a single agent will truncate or summarise, and summarisation is where the information loss lives.

Genuine independence

A second agent is worth its cost when it is genuinely independent, not when it is a rephrasing of the first. Independence means it does not share the first agent's context, its assumptions, or its failure modes. A verifier that reads the same context and the same reasoning will tend to agree with the producer, because it is running the same distribution over the same tokens. A verifier that reads only the artefact, and has its own tools for checking it, can disagree. That disagreement is the value.

Long-horizon tasks

Some tasks are long-horizon enough that a single context cannot hold them. A migration that touches hundreds of files, a research task that accumulates sources over hours, an incident response that spans multiple systems: these exceed what one window can retain, and the failure mode is not a wrong answer but a forgotten one. Here the orchestrator's job is not to reason about the task but to manage the ledger of what has been done and what remains.

If none of these three signals is present, the honest engineering answer is a script. A script that calls one model, validates the output against a schema, and retries on failure is testable, observable, and cheap. It is also, in most cases, faster.

Implementing the pattern

When orchestration is justified, the implementation details determine whether it works. Three mechanisms matter more than the choice of framework.

A single authoritative task ledger

Agents should read and write one shared ledger, not pass prose summaries to each other. The ledger is the source of truth for what has been attempted, what succeeded, and what is blocked. Each entry is a record: task identifier, status, inputs, outputs, and any error. Agents claim tasks, update status, and append results. The orchestrator reads the ledger to decide what to dispatch next.

This inverts the usual pattern. Instead of the orchestrator holding state in its context and summarising it to workers, the state lives outside every context and is read on demand. A worker that needs to know whether a dependency succeeded reads the ledger rather than trusting a summary. The orchestrator's context stays small, which is the point.

Handoff contracts as typed payloads

A handoff should be a typed payload, not a prose summary. Define the schema once, validate on both sides, and fail loudly on mismatch. A minimal contract for a subagent result might look like this:

{
  "task_id": "string",
  "status": "succeeded | failed | blocked",
  "artefacts": [{"path": "string", "hash": "string"}],
  "claims": [{"text": "string", "evidence": "string"}],
  "open_questions": ["string"]
}

The schema does two things. It forces the producing agent to distinguish between what it did and what it believes, which are different things. And it gives the consuming agent a stable interface, so a change in the producer's reasoning does not silently change the consumer's input. Where a field cannot be filled, the agent must say so, and blocked is a valid status. Prose summaries hide exactly this case.

Instrument handoff latency and information loss

Handoff latency is measurable: time from producer completion to consumer start, and time spent in validation and retries. Information loss is harder but not impossible. Instrument it by comparing what the producer emitted against what the consumer acted on. If the producer's payload contained three open questions and the consumer's next action addresses none of them, that is a loss, and it is worth logging. Over many runs, the distribution of these losses tells you where the contracts are too thin.

Treat both as first-class metrics, alongside task success rate and cost per task. An orchestration system that is correct but whose handoffs take longer than the work they coordinate is a system that should be collapsed back into a script.

The honest trade-off

The chief-of-staff pattern is not free, and it is not always right. Its costs are real: more moving parts, more prompts to maintain, more failure modes to observe, and a debugging experience that spans multiple contexts rather than one. Its benefits are also real, but they are conditional. They appear when subtasks need different context, different tools, or independent verification, and they largely disappear when they do not.

The practical discipline is to start with the script. Write the single call, validate its output, measure where it fails. When it fails because the context is too large, or the tools conflict, or the verification is not independent, add the orchestrator. Not before. The pattern is a response to a specific set of constraints, and applying it without those constraints produces the appearance of sophistication at the cost of the thing itself.

---

Cover photo: Freek Wolsink / Pexels.