When One Agent Is Not Enough

This is an advanced course, and the audience already runs single-agent workflows comfortably. The temptation at that point is to treat multiple agents as the obvious next level — more agents, more output, more leverage. The first module pushes back on that framing on purpose: the rest of the course teaches orchestration patterns, MCP chains, concurrent canvases, and pipelines, and all of it is wasted effort if the underlying task should have stayed with one agent.

Set the expectation that this module is a decision module, not a tooling module. There are no agent-team configurations here, no task lists, no worktrees — those arrive in Module 2 and beyond. What this module gives you is the test: three questions, an honest cost ledger drawn from runs executed for the school's own articles, and a worked example where the same task is evaluated both ways.

It helps to say the conclusion up front so nobody spends the module waiting for the reveal: staying with one agent is the default, escalation is cheap because the artifacts are just files, and every exit on the single-agent side of the decision map is a good outcome. The course is not selling multi-agent work. It is teaching you to run it well on the minority of tasks that earn it.

Walk the four bullets as a ledger, because each one is a cost that exists only because the work was split. Orchestration setup is the most visible: in the five-surface run executed for the school's orchestration article, writing the parent contract, the shared constraints, and five worker briefs took about 22 minutes before any worker produced anything. Duplicated context is quieter — every worker reads the design system, the constraints, and its slice of the project from scratch, which is most of why token use multiplies.

Divergent assumptions are the failure class that defines multi-agent work. Two workers each make a locally reasonable decision — one marks recently reviewed content with a green pill, the other with a yellow badge — and the outputs conflict globally. Cognition's widely cited 'Don't Build Multi-Agents' essay makes exactly this argument for write-heavy work: parallel workers that cannot see each other's reasoning will make conflicting assumptions. The school's own traced runs reproduced it on the first attempt, deliberately and then not so deliberately.

Multiplied review is the cost teams underestimate most. The merge is a real design review — reading every output, classifying conflicts, resolving them against the design system, recording what was rejected — and when something is wrong in the merged result, the cause can live in any worker's history, in the brief that shaped it, or in the constraint nobody wrote. None of this is an argument against splitting. It is the price list you check before you do.

The test that does the most work here is the one-sentence boundary. If you cannot describe what a worker owns — and what it must not touch — in one sentence, you do not have a decomposition; you have a wish. A full dashboard with navigation, a queue table, filters, charts, and mobile QA usually passes the test, because each of those is a place or a stage with its own files. A landing-page hero refinement usually fails it, because everything in it depends on everything else.

The three shapes of split worth naming now, ahead of Module 2, are spatial, by stage, and by expertise. Spatial splits — pages, bands, regions — parallelise well and fail at the seams. Stage splits — spec, implementation, QA — barely parallelise but merge almost for free, because each output feeds the next. Expertise splits work best when most of the specialist roles are read-only reviewers rather than writers; a visual-QA worker that reads everything and edits nothing is the cheapest worker you will ever add.

The parallel-deadline signal needs the honest caveat: parallelism only buys wall-clock time when the workers genuinely run at the same time and the surfaces are genuinely separable. A split that runs sequentially because the environment or the dependencies force it to has all of the coordination cost and none of the speed.

The polish pass deserves the most time because it is the most tempting and the worst candidate. A product detail page needing final refinement before a stakeholder review is mostly hierarchy, spacing rhythm, copy tone, and a few mobile adjustments — decisions that only make sense relative to each other. Split that across three workers and the merged result frequently feels less coherent than the starting point, because each worker optimised local details and weakened the whole rhythm. One agent should hold that taste loop, full stop.

The shared-file signal is mechanical rather than aesthetic: two agents editing the same component, the same token file, or the same frame produce a merge that is harder than the original task. The platform vendors say the same thing in their own documentation — as of June 2026, Anthropic's Agent Teams guidance explicitly recommends a single session or subagents for sequential and same-file work, and file-level ownership per teammate when you do split. When the vendor selling the multi-agent surface tells you when not to use it, believe them.

The small-task signal is just arithmetic. In the school's traced runs, briefs and constraints took nine minutes at two-worker scale and twenty-two at five-worker scale; for a single-surface change, that setup is most of the total budget. And unclear ownership is the organisational version of the shared-file problem: splitting a task nobody owns does not create owners, it creates more outputs nobody owns.

Most of the dissatisfaction that drives people to multi-agent setups is actually harness debt. Inconsistent output, invented colours, ignored conventions — none of those are fixed by adding workers, because every new worker inherits the same missing rules. Tightening the harness file, naming the components to reuse, and writing the anti-pattern list raises the floor for one agent and for any future team equally, so it is never wasted work.

Longer runs and sequenced sessions cover the 'the task is too big for one sitting' worry. A single agent with an approved plan can work a large surface in stages, and a sequence of sessions — each starting from the previous session's artifacts and notes — keeps one continuous line of design decisions without any merge step at all. The single-agent baseline in the school's five-surface run covered all four surfaces in about 28 minutes in one pass; what it lacked was not coverage but an independent reviewer and a written decision record.

That last gap is the honest one, and the read-only critique pass addresses most of it: a second pass over the output against written criteria, by the same agent or a cheap separate one, is not orchestration — it is a crit. Keep the escalation point explicit: if the task later grows real boundaries, the parent brief, worker briefs, and merge log you would need are ordinary files. Starting single-agent locks you out of nothing.

Walk the gate panel first, because the order of the questions matters less than the fact that they are asked before any worker exists. Boundaries: one sentence of ownership per worker, including exclusions. Separation: no shared files, no shared components, and no single taste loop stretched across workers. Value: the task has to be worth the coordination and token cost plus a merge review that cannot be skipped. Gates invented after the outputs arrive have a way of bending around whatever came back, which is why the map insists on asking first.

Then make the symmetry explicit: both exits are outcomes with costs, not a good path and a bad path. The single-agent side gives up parallelism, gives up an independent reviewer, and asks one context to carry every decision — which is fine for most tasks and exactly wrong for a handful. The multi-agent side buys separable speed, isolation, and surfaced conflicts, and pays in setup, duplicated context, multiplied tokens, and the merge.

The line under the gate panel — most design tasks fail at least one question — is the empirical claim worth defending out loud. Component tweaks, single-page refinements, token cleanups, copy passes, and polish rounds make up most of a working week, and none of them pass all three. The tasks that do pass — design-system audits at scale, multi-surface redesigns, multi-direction concept exploration — are exactly the workflows the rest of this course is built around.

These numbers come from runs executed for the school's two multi-agent articles, and their honesty matters more than their precision. The two-worker run produced two specification documents for a field-notes section: about 25 minutes of wall clock, nine of them spent on briefs, one deliberate conflict surfaced and resolved at merge, and roughly twice the text written compared with what one agent would have needed. As a one-off it did not pay for itself in speed; what it bought was the conflict arriving as two comparable proposals, a written decision record, and reusable briefs.

The five-surface run makes the same point at larger scale. Orchestrated: about 77 minutes as executed, with the worker passes running sequentially because the environment could not spawn parallel workers — roughly 46 minutes is the estimate had they run in parallel. The single-agent baseline on the same brief: about 28 minutes, one pass, perfectly usable, no conflicts surfaced because one context decided everything implicitly, and no record of why. The tax bought two resolved conflicts, an independent QA pass, explicit state coverage, and a merge log.

The external figures point the same direction more sharply. Anthropic's engineering write-up on its multi-agent research system reports roughly fifteen times the tokens of a single chat interaction — a research workload, not a design benchmark, so quote it for scale only. Claude Code's cost guidance adds that team token use scales with team size and idle teammates keep consuming until shut down. Date-stamp all of this as June 2026 figures and re-check before quoting them to a finance conversation.

The point of this slide is not a tool survey — Module 2 and the platform article carry that — it is that the decision framework in this module is not contrarian. As of June 2026, Anthropic ships two distinct surfaces in Claude Code: subagents, which are stable bounded workers with their own context that report back to the calling session, and Agent Teams, which are experimental, disabled by default, and switched on with an environment flag. The Agent Teams documentation itself recommends a single session or subagents for sequential and same-file work, file-level ownership per teammate, and a team size of three to five workers — with the memorable line that three focused teammates often outperform five scattered ones.

The other platforms express the same operating model with different machinery. Codex offers subagent workflows, worktree-isolated parallel sessions, and hosted cloud tasks. OpenCode makes agent roles project configuration, with per-agent permissions for editing, shell access, and which subagents may be invoked. OpenPencil applies the idea to a shared canvas, with concurrent agents owning regions. In every case the durable parts are the same: a shared contract, bounded workers, owned outputs, and a merge step nobody automates away.

Name the counter-position too, because students will encounter it: Cognition's 'Don't Build Multi-Agents' essay argues that for write-heavy work where every decision depends on its neighbours, parallel workers make conflicting assumptions and a single-threaded agent with full context simply does better. LangChain's follow-up reconciles the positions around the same separability test this module teaches. Date-stamp all of it: these surfaces are moving quickly, and the experimental ones change shape between quarters.

This is the two-worker trace from the school's article on when to use multiple design agents, and its value is precisely that it sits on the boundary of the decision map. The task — specify a field-note card and the section frame that holds it — passes the boundary question, just barely passes the separation question, and arguably fails the value question for a one-off. Running it both ways makes the trade visible instead of theoretical.

Kept with one agent, the work takes ten to fifteen minutes and comes back coherent, because one context holds both surfaces and decides the freshness treatment implicitly along the way. Split across two workers, the briefs took nine minutes, each worker produced its spec in about four, and the merge review took eight more. The deliberate overlap did exactly what it was designed to do: Worker 1 marked recently reviewed notes with a school-yellow badge in the card's meta row; Worker 2 switched the card's accent stripe to green and added an 'Updated this month' line — reaching across the ownership boundary into the other worker's surface. The merge resolved it against the design system, which reserves green for workflow cues, and recorded the rejected option.

The lesson to land is not that one evaluation is right. It is that the split's value was the evidence — the conflict surfaced as two comparable proposals, the decision recorded, the briefs reusable next time these surfaces change — and the single run's value was speed. For a throwaway spec, take the speed. For a surface several people will touch next, the record may be worth twenty-five minutes. The decision map is how you make that call before the work, not after.

This slide previews Module 2 deliberately, because the artifacts are also part of the decision: if your decomposition cannot be expressed as one owner per file with a one-sentence boundary, that is the map telling you the task is not separable yet. The orchestration brief is the parent contract — user job stated once, ownership boundaries, the overlaps you expect the merge to resolve, and the gates written before any output exists. The shared constraints file matters at team scale because pasting constraints into each brief is how drift starts: one brief gets edited, the others do not, and workers follow different rules without anyone deciding that.

The merge log is the artifact people skip and the one with the longest life. It records not just what was accepted but what was rejected and why — the next agent or human who wonders why recently reviewed notes are not green reads the answer instead of relitigating it. The gaps section matters too: decisions no brief assigned are decisions nobody made, and the honest move is to log them as open questions rather than have the orchestrator invent answers during the merge.

The baseline is the quiet discipline: without a single-agent run or at least a prior estimate, nobody can say afterwards whether the orchestration bought anything, and the benefit gets asserted instead of measured. And the fallback path runs through the same files — if workers keep colliding mid-run, hand one agent the brief, the constraints, the surviving outputs, and the merge log so far, and let it finish in one context. The artifacts make both directions cheap.

The exercise is deliberately analogue: three real tasks, one page, no agents. The spread across sizes matters, because the most common discovery is that the small and medium tasks fail the value question immediately, and the big one fails the boundary question on the first attempt — the boundaries people write for it are wishes, not ownership statements. Rewriting them until each is genuinely one sentence with exclusions is most of the learning.

The single-agent alternative line keeps the exercise honest. For tasks that fail the map, the answer should be specific: tighten the harness, run it longer with a reviewed plan, sequence the sessions, or add a read-only critique pass — not just 'use one agent'. For the task that passes, the deliberate-overlap question is the one that separates people who have absorbed the module from people who have skimmed it: naming where two workers will both need a position, and predicting the conflict, is what makes the eventual merge an expected comparison rather than a surprise.

If running this live, collect the boundary sentences and read a few aloud. The difference between 'Worker 1 owns the dashboard' and 'Worker 1 owns the queue table's fields, density, and states, and does not touch navigation, filters, or tokens' is the difference between a decomposition and a wish, and hearing both versions back to back lands it faster than any slide.

Recap the module as a single decision discipline rather than five separate facts. The coordination tax explains why the default is one agent; the split signals and the do-not-split signals are the two halves of the boundary test; the single-agent alternatives are what you exhaust before paying the tax; and the cost accounting is what keeps the decision honest afterwards. If participants remember only the three questions on the decision map, the module has done its job.

Be explicit that nothing in this module argued against the rest of the course. The workflows the school publishes — design-system audits at scale, multi-direction concept exploration, canvas-to-production pipelines — are exactly the tasks that pass the map, and they are why the orchestration skill is worth building. The point of the gate is to protect those cases from being diluted by a habit of splitting everything.

Preview Module 2 concretely: it assumes the decision has been made and covers the three patterns that carry most real cases — fan-out for independent parallel zones with one merge point, pipelines for staged work where each output feeds the next, and critic pairs where one agent produces and another reviews against explicit criteria. It also introduces the orchestrator role properly: the brief, the boundaries, the merge log, and the stop conditions. The exercise page from this module is the input — the task that passed the map is the one participants will sketch a pattern for next.