The shape of orchestration.

From directing one agent to composing several CORE

Every module through Module 7 has been about one student talking to one agent at a time. You held the steering wheel in Module 3 against a repository. You held it in Module 4 against the open web. You held it in Module 5 against a mailbox and a calendar. In Module 6 you let a schedule hold the wheel for you, but the wheel was still steering one agent through one task. In Module 7 you elevated the prompt itself into named, reusable skills and plugins — still one agent, now carrying better instructions.

Module 8 is the first module where you stop holding one wheel and start composing two or three or four of them. The agent that does research does not also draft the brief. The agent that drafts the brief does not also check the citations. The agent that checks citations does not also package the draft for your email. Each of those jobs becomes its own small agent, with its own scope, its own instructions, and its own narrow piece of the work — and the thing you build and own is the pipeline between them.

That move sounds small. It is not. A system made of three agents handing off to one another is a different kind of object from one agent doing a larger job. It has behaviors a single agent cannot have — a stage can run in parallel with a sibling, a supervisor can retry a failed worker, a downstream agent can reject upstream output as insufficient. It also has failure modes a single agent cannot have — a vague handoff silently corrupts everything downstream, a hidden retry loop quietly spends fifty times what you budgeted, a supervisor misjudges which of four workers succeeded and promotes the wrong output.

The central claim of this module is that the quality of an orchestrated system is set by the quality of its interfaces, not the quality of its agents. A brilliant drafter that is handed bad notes produces a bad draft. A merely competent drafter that is handed tightly scoped input produces an acceptable draft. The place to invest your attention — from the very first sketch of the pipeline — is the spaces between the agents, not the agents themselves. Lesson 8.2 makes that into a concrete discipline called the handoff contract. This lesson is where you learn to see the shape that contract is going to sit inside.

A useful way to name the shift: through Module 7 you learned to direct an agent. In Module 8 you learn to compose agents. A director tells one person what to do; a composer writes a score that three or four people can follow together without the composer standing behind each of them. The mental model for the rest of the module is the composer, not the director.

Three shapes orchestration actually takes CORE

Nearly every multi-agent system you will build, install, or read about lands in one of three shapes. You can combine them — a branch of a hierarchical system can be a sequential pipeline; a stage of a sequential pipeline can fan out into parallel workers — but the three primitives are the vocabulary. Name the shape before you build.

1. Sequential pipeline. Agent A produces output; agent B reads that output and produces its own; optionally agent C reads B’s output and produces the final artifact. The work has an order dependency — you cannot draft the brief before the research is done, you cannot check citations before the draft exists. Sequential is the shape most students reach for first, and most of the time it is the right shape. A three-agent research → draft → review pipeline is sequential. A two-agent triage → reply-draft pipeline (Module 5 extended) is sequential. A scheduled gather → summarize pipeline (Module 6 extended) is sequential.

The sequential pipeline is easy to reason about because the state at each step is visible — the artifact agent A wrote is the artifact agent B reads, and you can open both. Cost is additive, not multiplicative. The weakness of the sequential pipeline is that a bad early stage contaminates everything after it. Debugging means reading the trace from the top and finding the first stage whose output drifted.

2. Parallel workers. Several agents run at once on independent subtasks, and the results are combined. The work has no order dependency among the parallel siblings — the draft-social-post agent does not need the draft-blog-post agent to finish first; both start from the same source material and produce different artifacts. Parallel is the right shape when the same input feeds several independent outputs, or when a single input can be sliced and each slice processed without reference to the others (summarize each of ten source articles in parallel, then combine the summaries).

Parallel workers are cheaper in wall-clock time than running the same work sequentially — a student whose pipeline would take twelve minutes sequentially may run it in three minutes in parallel. They are not cheaper in dollar cost; they are usually more expensive, because the combining step (even when trivial) adds tokens. The weakness of parallel workers is coordination: all the workers have to agree on the shape of the input they were given and the shape of the output they produce, because a combiner that receives four differently-shaped outputs cannot cleanly merge them.

3. Hierarchical supervisor. A supervisor agent is handed a goal; the supervisor decides how to decompose the goal into subtasks, spawns worker agents to execute the subtasks (often in parallel), reads their outputs, and produces the final artifact — sometimes calling another round of workers if the first attempt was insufficient. Hierarchical is the right shape when the decomposition itself is non-trivial and you would rather have an agent do it than write the decomposition by hand. It is also the right shape when you do not know, in advance, how many workers the task will need — a research sweep across an unknown number of sources, say.

Hierarchical orchestration is the most powerful shape and the most dangerous. A supervisor that is allowed to spawn workers that spawn workers is the canonical picture of runaway orchestration — the tree of agents grows unchecked, the token count grows with it, and a simple question quietly costs more than a restaurant dinner. The depth and fan-out caps in the Module 8 rails (depth ≤ 3, fan-out ≤ 4) are aimed squarely at this pattern. A sequential pipeline cannot run away. A parallel-worker pipeline runs away only at its fan-out step. A hierarchical pipeline can run away anywhere, any time, and it usually takes the novice by surprise.

Picking the shape: a two-question test CORE

Before you build, you pick. The two-question test is:

Question 1: Does the work have order dependencies? Is there a clean “first this, then this, then this” story you can tell? If yes, you are looking at a sequential pipeline for the ordered portion. If no — if several pieces of work could start at the same time because none of them needs the others’ output — you are looking at parallel workers.

Question 2: Does the decomposition itself need judgment? If you already know what the subtasks are and how many there will be, you do not need a supervisor to figure it out — parallel or sequential composition is enough. If the number of subtasks is unknown, or the right decomposition depends on what the input actually is, you want a hierarchical supervisor to make that call at runtime.

Apply the test to the canonical examples from earlier modules:

• Research sweep on a topic, produce a brief, check citations, deliver the final draft. Order dependency is strong (cannot draft before research, cannot check before draft). Decomposition is fixed (three named stages). Sequential pipeline.
• Given one article, produce a blog post, three social posts, and a newsletter blurb. No order dependency — each output derives from the same source independently. Decomposition is fixed (four named outputs). Parallel workers.
• Given a topic, do enough research to answer it — however many sources that takes, however many angles it needs — and produce a brief. Order dependency is present (decide decomposition first, then execute). Decomposition is not fixed — the supervisor has to decide how to slice the research at runtime based on what the topic actually requires. Hierarchical supervisor.

Most students’ first real pipeline is sequential. That is the intended starting point. A sequential pipeline is legible; a hierarchical pipeline is not. When in doubt, sequential.

The one-agent-too-many test: when not to orchestrate CORE

The most expensive mistake a Module 8 student can make is orchestrating a job a single agent could have done well. Orchestration has real overhead: more prompts to write, more handoffs to design, more artifacts to read, more cost per run, and — worst of all — more surface area for silent failure. If a single agent can do the job reliably, orchestrating it is not leverage; it is drag.

The one-agent-too-many test is four questions. If the answer to any of them is “no,” do not orchestrate. Tighten the single-agent version first.

1. Does the single-agent version already succeed? Have you actually run this as one prompt, one skill, or one scheduled task, and gotten an acceptable result? If you have not tried the single-agent version, do that first. Half of would-be pipelines collapse into “actually, one agent with a better prompt is fine.”

2. Is the single-agent version failing on separable sub-problems? When it fails, does it fail at the same step every time — “the drafting part is fine but the citation-checking part is always sloppy” — or does it fail diffusely? Orchestration helps when the failure is localized; orchestration does not help when the failure is diffuse (that is a prompt or skill problem, and lives in Modules 3–7).

3. Does each sub-problem get materially better with a dedicated agent? Would a focused draft-checker agent — with its own prompt, its own context, maybe its own model — actually do a cleaner job than “please also check the citations” appended to the drafter? If the failure is localized but the cure is “a sharper prompt in the same agent,” stay with one agent.

4. Is the goal big enough to be worth the orchestration overhead? A pipeline costs at least one handoff contract to design, two invocations’ worth of tokens to run, and a place to live in the capstone register. A goal that a human takes five minutes on and an agent takes thirty seconds on is almost never worth a pipeline. A goal that a human takes an hour on, that happens three times a week, is usually worth one.

Applied to concrete examples:

• Summarize an article in my own voice. One agent. A better prompt, maybe a skill from Module 7, will finish this cleanly. Do not orchestrate.
• Write a paper about Napoleon. One agent, mostly. The real work is the student’s thinking; orchestration cannot substitute. Do not orchestrate (for the student’s own writing).
• Review my week’s calendar, draft three preparation notes, and post them into a “meeting prep” folder. Three separable sub-problems, each materially different (one is calendar-reading, one is drafting, one is filing). Happens weekly. Orchestrate, sequentially.
• Once a morning: gather the top headlines from three feeds, summarize each, produce a combined briefing. Two separable stages, each with its own failure mode (gathering fails differently from summarizing). Daily. Orchestrate, sequentially.

A student who applies this test honestly ends Module 8 with one well-built pipeline, not three. That is the intended outcome. The capstone requires one frozen pipeline, not a catalog.

The runaway failure mode, in miniature CORE

Lesson 8.5 treats runaway orchestration at full depth. This block is the headline warning, named early so you see it coming through Lessons 8.2, 8.3, and 8.4.

A runaway pipeline is one that consumes materially more tokens, time, or dollars than the student expected when they wrote the blueprint. The three most common shapes are:

• Depth runaway. A supervisor spawns workers that spawn sub-workers that spawn sub-sub-workers. Each layer looks innocent; the total is not. The depth cap of 3 in Module 8 (workers, one supervisor, optionally one meta-supervisor) exists because students who exceed that depth almost always regret it the first time they read the cost.
• Fan-out runaway. A supervisor or parallel step spawns twelve workers when four would have done. Each worker’s cost is small; twelve of them is not. The fan-out cap of 4 exists as a default to force the student to notice when they are about to exceed it.
• Retry runaway. An agent retries on failure, and the retry logic does not have a clear stopping condition. A flaky tool call plus an aggressive retry loop can multiply token usage by five or ten without anyone seeing it happen. The handoff contract (Lesson 8.2) is what makes “failure” something the system can notice clearly; without it, retry loops do not know when to stop.

Your defense against all three is the same three-part rail: a depth limit, a fan-out cap, and a pre-flight cost estimate you run before every invocation. The rail does not need to be complicated; it needs to be present. Write the estimate in the blueprint. Refuse to run the pipeline until the estimate is within the per-pipeline budget. Practice stopping the pipeline mid-run at least once. These rituals are installed in Lesson 8.5, but every lesson between now and then assumes you are operating under them.