Chapter 14: Work Alone or Work in a Group — Multi-Agent
Xiao A's agent grew busier by the day. It switched among three tasks and did justice to none of them. Halfway through a bug fix, he remembered a feature still unwritten; halfway through the feature, he remembered the docs untouched. He could not take it any longer and went to find Lao Z.
"One person can't keep up — surely hiring a few more hands helps?" he asked.
"Don't rush to hire," Lao Z said. "A Skill reuses experience, but it does not add parallelism. About your idea of handing everything out at once, I have one question: can these three jobs really run independently?"
Xiao A froze. He had never thought about that question.
This chapter discusses the engineering trade-offs of subagents, communication, and orchestration. It does not treat "multi-agent" as an inevitable route to greater capability.
Align the names first
| Term | English / abbreviation | Working definition in this book | What it is not |
|---|---|---|---|
| subagent | subagent | an independent executor delegated a bounded task | a guarantee of independent permissions |
| multi-agent system | multi-agent system | a system where two or more executors collaborate through tasks or messages | a system that is automatically more reliable |
| orchestrator / control plane | orchestrator / control plane | the coordination layer that assigns, cancels, aggregates, and observes tasks | the final guarantor of quality |
| task ownership / shared state | task ownership / shared state | the contract over who may change what, and which states are jointly visible | one shared long context |
Judge first whether the split is worth it
Xiao A thought back to his three jobs. "Under what conditions is multi-agent really worth it?"
"The preconditions are that the tasks can run in parallel, the deliverables can be merged under clear rules, and shared state stays controllable," Lao Z said. "Flip it around: if every step depends on the judgment the step before it just produced, splitting only adds coordination rounds and copies of context."
"I guess that's because the judgments can't run in parallel?" Xiao A ventured.
"Right. Suppose the plan in step two leans heavily on the conclusion of step one: step two can only start once step one is done, so the so-called parallelism is just each step queueing on its own. The gain is zero, and you still pay the handoff cost. So to judge whether a task can be split, ask one thing: after the split, can every subtask take its input and independently produce a verifiable result? If yes, the split is worth it. If not, serial stays simpler."
"And the cost of merging? How do you estimate that?"
"Merging is the hidden cost of splitting, and you usually discover it at the very end," Lao Z said. "All three subtasks produce output, and the aggregator has to merge three outputs into one consistent result. If the three come in different formats, use different criteria, or contradict each other, the merging effort can exceed the time parallelism saved. So define before you split what each output looks like, who merges them, and whose word wins a conflict — don't wait for the results and then scramble."
Lao Z drew the two routes on paper:
No split (serial):
input ──> step A ──> step B ──> step C ──> result total time = A+B+C, zero handoff
Split (parallel):
input ──> subtask A ──┐
subtask B ──┼─> aggregate/merge ──> result total time ≈ max(A,B,C) + merge
subtask C ──┘"Serial takes the sum of the three steps, but every round keeps a short context and the handoff cost is zero," Lao Z said, pointing at the drawing. "Parallel takes the longest step plus the merge, and that merge box is the one people forget. If B depends on A while C is independent, A and C can start together, and B waits for A. Total time is approximately max(A+B,C) + aggregation. Only when A, B, and C all form a serial dependency chain does it become the sum of three, plus merging. Split or don't split is a contest between the waiting you save and the merging you add. Counting subagents tells you nothing."
| Situation | The likelier choice | Why |
|---|---|---|
| A small fix in a single file | single Agent | handoff cost exceeds the parallel gain |
| Independent research plus test design | parallel subagents | each output can be verified on its own |
| Large changes to the same file | assign ownership first, or run in order | avoids conflicts and overwrites |
| A high-risk release | an explicit approval chain | responsibility cannot be handed to a "vote" |
"If I hire more agents and let them vote, won't the result be more reliable?" Xiao A was still attached to the hiring idea.
"Not necessarily. They may share the same wrong material or the same prompt, which produces correlated errors," Lao Z said. "Independent verification, different evidence sources, and clear acceptance criteria matter more than headcount."
"Correlated errors? Don't they each run independently?"
"Running in parallel is not the same as failing independently," Lao Z said. "Three subagents reading the same out-of-date document reach three identical wrong conclusions; you see three votes in agreement and feel reassured — that is the problem. For a vote to mean anything, the voters have to consult different sources, use different retrieval methods, even run different prompts. Otherwise the three votes you receive are one echo of the same mistake."
"So for my three subagents, what exactly counts as truly independent?"
"A rough self-test: remove any two of them. Can the one left still reach a verifiable conclusion on its own?" Lao Z said. "If one executor's output is just the other's output in a different format, the two are really two stations on the same pipeline, not independent executions. What that situation calls for is a division of labor, which is the next section."
Metaphor: hiring people
Whether more hires speed you up depends on whether the work splits. If the jobs are interdependent, more heads only means more voices fighting over the same file.
Three common structures
Having settled whether the split is worth it, Xiao A asked on: "So how are these subagents usually organized?"
"Three structures are common," Lao Z said:
- Delegation: the main Agent assigns bounded subtasks, aggregates the results, and owns the final action.
- Pipeline: one role produces output for the next role to check or transform; it suits flows with a clear dependency order.
- Competition / review: several executors propose solutions independently, and an independent standard or a human adjudicates. It consumes more model calls and should not be the default.
Xiao A copied the three down, then looked up. "Whichever one I pick, is there anything all of them need?"
"Whatever the structure, the task card should carry the input, the allowed tools, file ownership, the output format, the stop condition, and how the result is accepted. Collaboration without those boundaries is just forwarding vague context."
"How do I choose among the three?"
"Look at whether the tasks relate in parallel or in series," Lao Z said. "Delegation presumes the subtasks are independent of each other, so who finishes first changes nothing for the others. Pipeline presumes the next step must wait for the previous step's product; what it buys is a shorter, more focused context per role — not parallel speed-up. Competition is worth the multiplied call cost only when correctness is hard to judge and a single person is likely to miss things. Force delegation onto strongly dependent tasks and you get a pile of subtasks waiting on each other and an invoice spinning in neutral."
"Can the costs of the three structures go in one table?"
| Structure | Precondition | What it buys | What it costs | Most common failure |
|---|---|---|---|---|
| delegation | subtasks are independent | parallel speed-up, clear responsibilities | aggregation and merge cost | subtasks look independent but share one output |
| pipeline | each step needs the previous step's product | short, focused context per step | serial waiting, handoff drift | the handoff ships conclusion and process together |
| competition / review | correctness is hard to judge, one person misses things | fewer single-perspective blind spots | multiplied model calls | participants share material, so errors correlate |
"The third and fourth columns of that table grew facing each other," Lao Z said. "Every benefit has a matching cost. When you pick a structure, first confirm the cost is affordable and the failure is detectable; only then care whether it sounds sophisticated. If competition can't afford the call cost, the extra reliability it brings is an illusion."
"Then my bug fix — that's delegation, right? A main Agent dispatching work sounds a lot like it."
"That's a typical pipeline: retrieve the evidence → change the code → run the verification," Lao Z said. "But the precondition is that you can draw a clear responsibility line between retrieving and changing. If the retriever can't even say where to change, and the person making the change has to look everything up again from scratch, then that step is one step disguised as two — better handed to a single Agent to finish in one pass."
"The stop condition on the task card — what goes in it, concretely?"
"Write when the subagent should stop, and what it hands over when it does," Lao Z said. "For a retriever, the stop condition might be 'found the definition site, or checked five sources'; what it hands over is 'function location and signature', not every web page it read. For a verifier, the stop condition is 'ran the designated case set', and what it hands over is 'a pass/fail list plus a reproducible command for each failure'. The fuzzier the stop condition, the more the subagent drags its whole context back, and the aggregator has to filter it a second time."
"The task card also lists file ownership as its own field. Why?"
"Because ownership is where conflicts come from," Lao Z said. "One file claimed by two subagents at the same time is a race at write time. A file no subagent claimed gets changed wrongly and nobody owns it. Ownership has to answer 'who is in charge of this file right now', and it has to agree with permissions: a read-only role may not own a writable file. Get the ownership claim wrong, and every conflict ruling downstream goes wrong with it."
Communication, state, and isolation
With the division of labor settled, Xiao A reached the next question: "So how do they 'talk' to each other?"
"Messages should carry conclusions, where the evidence lives, and open questions — not whole passages of hidden reasoning," Lao Z said. "Shared files, shared sessions, and shared credentials turn parallelism into contention: you need locks, branches, workspace isolation, or read-only copies."
"Why not just share the context? It's less work."
"Because the price of 'less work' is contamination," Lao Z said. "A retrieval subagent's context is packed with web page fragments. Pass it along verbatim and the modifier has to dig the one line it must change out of a pile of irrelevant search results. A conclusion-style message — 'function X is at line 200 of file Y, signature Z' — carries the conclusion, not the process, and only that keeps downstream context from inflating or drifting."
"What does a good message look like, and a bad one?"
"A good message is short and verifiable," Lao Z said. "'The payment function is at line 40 of payments.py, signature pay(amount, currency); callers at line 12 of orders.py; no other references found' — every clause can be checked in the source. A bad message pastes three retrieval results whole to whoever is downstream: 'I read web page A, doc B, forum C, and here is roughly what they said...' Such a sentence can't be verified on its own and smuggles in a heap of source judgments. For every sentence you pass, ask: can the receiver verify it independently? If not, the message carries process and opinion that should not have travelled."
"What does 'shared state' actually cover? Does a shared file count?"
"It does, and shared state isn't only shared files," Lao Z said. "Shared files, shared sessions, shared databases, shared configuration — anywhere two executors read and write the same state. Each has its own conflict pattern: shared files overwrite each other, shared sessions inject irrelevant content into one another, a shared database writes two values to the same row at once. Every kind of shared state needs a matching control. Saying 'we all work in the same workspace' does not make it safe."
"So what do the conflicts look like, per kind of shared state?" Xiao A pressed.
Lao Z laid those conflicts out in a table:
| Shared state | What the conflict looks like | Control | Cost |
|---|---|---|---|
| shared files | two subagents write the same file, overwriting each other | file ownership, locks, branch workspaces | serialized waiting, or a merge ruling |
| shared sessions | one subagent's messages leak into another's context | session isolation, messages tagged with a task ID | context copying cost |
| shared database | concurrent writes to one row, reads of uncommitted changes | transactions, version numbers, read-only replicas | lock and retry overhead |
| shared configuration | one side changes the config, the other still uses the old value | config snapshots, versioning, change notifications | synchronisation complexity |
"What these controls have in common: they trade 'everyone may write concurrently' for 'explicit ownership or serialization'," Lao Z said. "With the former, when something breaks you can't find who wrote it. With the latter you can at least trace who, when, and against which version. Shared state may exist, but it needs a rule for who has the right to change it and who learns about the change. Tacit agreement is not a rule."
"Doesn't an isolated workspace get expensive?"
"Expensive, but expensive once," Lao Z said. "Creating a separate workspace, configuring its own permissions, mounting a read-only snapshot — those are one-time costs. What they buy runs on every single execution: one subagent can't overwrite another's output, and can't read someone else's intermediate state. High setup cost and low running cost is exactly what a cost worth paying looks like. The reverse — cheap to set up, and fighting on every run — that is the genuinely expensive one."
"And permissions?"
"Permissions should narrow with the role too. A retrieval task doesn't need to write files; a test task doesn't need publishing credentials," Lao Z said. "A subagent's tool calls, cost, and failures must attribute to its task ID, so the main Agent can stop it on a timeout, a conflict, or an abnormal outbound request."
"Handing every subagent its own credentials — isn't that too much trouble?"
"Troublesome, but more controllable than one shared high-privilege token," Lao Z said. "Shared means any subagent that gets tricked into exfiltrating leaks the whole set. Issue a scoped token per role, and a single leak only reaches that role's scope. The measure is 'how far can one failure spread' — convenience comes second."
"So isolation just means separating credentials?"
"It goes further. Isolation has three planes: files, credentials, network," Lao Z said. "File isolation: each subagent gets only its own workspace or a read-only snapshot. Credential isolation: each role holds only its own token. Network isolation: each subagent's outbound destinations are restricted separately. The three planes each cover one class of leak surface, and isolation only counts when all three are written down. Isolate files while credentials stay shared, and one induced subagent carries everyone's tokens out with it."
"How do you decide the degree of isolation?"
"By the role's risk," Lao Z said. "A read-only retrieval role is low risk, so thin isolation is enough: a read-only snapshot plus no network. A role holding publishing credentials is high risk, so isolation must be thick: its own credentials, its own network, approval per action. The thickness follows 'how much damage a leak does' — the more damage the role can do, the thicker its isolation."
Cost is not a side issue
The more Xiao A thought, the less right it felt: "Doesn't all this make things more expensive?"
"It can. Every subagent can generate context, tool calls, and retries. Parallelism lowers wall-clock time; it does not promise lower total cost. The aggregator also has to judge conflicting outputs," Lao Z said. "In practice, measure where a single Agent fails first, then add concurrency only for a bottleneck you can verify. That is usually steadier than assembling a 'team' first."
"How do you 'measure the failure points'?"
"Run a single Agent on real tasks and record three things: which step is slowest, which step fails most often, and which step's output most often gets overturned downstream," Lao Z said. "If the slowest step is 'read three large documents', it is a real candidate for saving time in parallel. If the most failing step is a decision that needs global judgment, splitting it out only amplifies the error: several subagents each holding partial information will decide worse. A bottleneck worth concurrency is one you can measure. If you can't say where the bottleneck is, every subagent you add is a guess."
"So is 'parallel saves time' true or false?"
"Wall-clock time may fall; total tokens and call count must be measured," Lao Z said. "Three parallel subtasks have their own contexts, and the aggregator must read their outputs. Extensive copying, repeated work, or retries often increase calls and total tokens. But splitting context can also reduce repeated input of long histories and lower total tokens. Call count depends on each loop's rounds and retries. Compare elapsed time, calls, total tokens, and actual cost on the same task with the same acceptance criteria before deciding whether the waiting saved is worth it."
"Any way to squeeze that cost back down?"
"Parallelize only the parts that are genuinely parallel," Lao Z said. "Pull strongly dependent steps back into the main Agent, and split out only what really can run in parallel — fetching several unrelated documents, for example. Each extra subagent may add context copying and aggregation overhead. Measure whether benefits such as shorter contexts offset that overhead."
"Can cost be attributed to each subagent?"
"It must be. Every subtask's tokens, call count, and duration have to hang on its task ID," Lao Z said. "Without per-task cost, all you can see is 'the total went up'. You can't say which subagent burned it or which kind of action is priciest, so you can't decide what to cut next. Cost attribution and status reporting are two sides of the same data: one task table shows both progress and the bill."
"Are there cases the other way, where a single Agent is actually the more expensive one?"
"There are — when the bottleneck is waiting on an external resource," Lao Z said. "Say you must consult three unrelated large documents. A single Agent queries them in series and waits through three I/O spells. Three parallel subagents query at once and compress wall-clock time down to the longest single one. What you save there is waiting; what you pay is three independent contexts. If the single Agent's waiting itself costs more than that context overhead, parallelism pays."
"Can you put the costs in one comparison?"
"I can. Run the same task both ways and read four kinds of accounts," Lao Z said,
| Account | single Agent | parallel subagents | Where the difference comes from |
|---|---|---|---|
| model call count | sum of requests across main-loop rounds | sum of requests across sub-loops and aggregation | a loop is not a single call; rounds, aggregation, and retries determine the difference |
| total tokens | input and output tokens summed across requests | input and output tokens summed across subtasks and aggregation | copying and repeated material may add usage; shorter contexts may save usage |
| wall-clock time | A+B+C in series | max(A,B,C) + aggregation | saved in waiting, paid in merging |
| retry count | retry only on failure | every sub-context may retry | more calls may increase the chance of encountering failures; measure actual retries |
"That table isn't for memorizing numbers; it reminds you of three things," Lao Z said. "First, total cost may rise or fall: measure the effects of context copying and shortening. Second, retries are not free, and more calls may increase the chance of encountering failures. Third, compare wall-clock time, call count, and total tokens separately; parallelism alone does not determine them. Record these accounts before judging whether parallelism is worth it."
The control plane and failure propagation
With several subagents running at once, what came to Xiao A's mind was loss of control: "So who is in charge of calling a stop?"
"A multi-agent system needs a control plane that maintains task state, budget, permissions, and cancellation — not just executors firing text at each other," Lao Z said. "Illustration: after a research task times out, the control plane cancels its remaining network calls and hands 'insufficient evidence' to the aggregator; the aggregator must not treat the timeout as support for a conclusion."
"Why not let the subagents shout stop at each other directly?"
"Because an executor has no global view," Lao Z said. "A subagent knows only that it timed out. It doesn't know whether this cancellation is a local degradation or the end of the whole task. If it has to notify whoever is downstream, how far should they trust that? The control plane is the only party holding the budget, the task tree, and ownership. Only when it issues the cancellation do all subtasks share one stop semantics."
Xiao A moved up a layer: "Then how does the control plane itself know where things stand right now?"
"From the status each subagent reports back," Lao Z said. "The task card states what to report after each step: in progress, completed, failed, waiting on external input. The control plane hangs those four states on the task tree, which lets it answer 'who is waiting, who is running, who blew the budget'. If subagents don't report status, the control plane can only guess from timeouts — which makes it a wall clock."
Xiao A dug further: "Does cancellation take effect immediately, or with delay?"
"Usually best effort, not instantaneous," Lao Z said. "A subagent may be stuck inside a tool call, and the control plane can only let it see the cancellation signal once it returns to a loop boundary. So the task card must state how to wind down safely after cancellation: is a file mid-write discarded or flushed, and a network request already sent cannot be recalled. Design cancellation as an instantaneous operation and long tasks will leave half-finished artifacts behind."
"Then does one subtask's failure drag the whole task down?"
"That depends on how the task card declares its dependencies," Lao Z said. "The same failure can be a local degradation or a global termination. If a retrieval timeout only means 'one reference short', the task can degrade and continue. If that retrieval feeds every decision afterwards, you must terminate or reroute. Failure modes belong in the task card too, stated as clearly as stop conditions. Leave them out and the control plane can only guess when a subagent fails."
"How many ways can a failure propagate?"
"Three typical ones." Lao Z sketched the three routes:
Failure ──> (1) Isolate: degrade only this subtask's output, the rest proceed as usual
│ e.g. retrieval times out; mark "insufficient evidence" and continue
├──> (2) Block: wait for that subtask, or hand the work back to the main Agent
│ e.g. a middle step of a pipeline fails and every downstream step waits
└──> (3) Terminate: propagate cancellation and wrap up as a whole
e.g. the main Agent judges the failure unrecoverable and cancels everything"Which one applies is declared in advance, on the task card," Lao Z said. "(1) suits side paths where the job can go on without that output. (3) suits core paths where one cut stops everything. (2) is the one most likely to grow a deadlock: downstream keeps waiting and nobody calls stop. So label every subtask with which class its failure belongs to, and let the control plane act on the label instead of improvising on the spot."
Collaboration is not sharing one long context
"Can you walk a complete scenario through?"
"Sure. The common topologies are main Agent delegation, pipeline handoff, and independent review. In every one of them, the task owner must be the one who does the final merge."
Xiao A picked the first. "What does the main Agent delegation topology look like drawn out?"
"Take the defect-fix scenario that runs through this book," Lao Z said, drawing as he spoke:
┌───────────────────┐
│ main Agent │ assign / aggregate / accept
└─────────┬─────────┘
┌──────────────────────────┼──────────────────────────┐
↓ ↓ ↓
┌─────────────────────┐ ┌─────────────────────┐ ┌─────────────────────┐
│ retriever │ │ modifier │ │ verifier │
│ read-only + search │ │ owns target module │ │ owns test directory │
│ out: evidence sites │ │ out: diff + notes │ │out: pass / fail list│
└─────────────────────┘ └─────────────────────┘ └─────────────────────┘
read-only snapshot writable copy read-only"Of the three subtasks, only the modifier gets a writable copy; the other two are read-only," Lao Z said, pointing at the drawing. "The main Agent takes back three conclusions — where the evidence is, what changed, what the tests say — merges them itself, and runs acceptance. This picture answers two things: who owns what, and who is responsible for the last step. If you can't draw the topology, the boundaries aren't thought through yet. Don't start work."
"A happy path isn't enough, is it? What happens when things fail?"
"Still the defect-fix scenario," Lao Z said. "The happy path is each role producing verifiable evidence. Failure path one: retrieval times out, and the main Agent degrades to a single Agent or terminates. Path two: the modifier's and the verifier's conclusions conflict, and you rule by test results and source evidence. Path three: the main Agent cancels, which propagates cancellation to every subtask and waits for the safe wind-down of writes already begun."
"Can you show me one subagent's task card?"
"Take the verifier," Lao Z said, and wrote a sample:
Role: verifier
Input: the modifier's list of changed files + its change notes
Allowed tools: read, run_test (no file writes, no network, no publishing)
File ownership: test directory (read-only); no writable files at all
Output format: a pass/fail list; every failed case carries a reproducible command
Stop condition: the designated case set has been run
Failure mode: test infrastructure unavailable → report "cannot verify", the main Agent rules
Acceptance: the main Agent re-runs one key case as a cross-check"This card turns every boundary we just discussed — input, tools, ownership, stop condition, failure mode, acceptance — into fields you can check," Lao Z said. "Whoever reads it, a subagent or you, knows what it should do, what it may touch, when it stops, and which failure class applies. A task card is not documentation for show. It is the smallest unit of contract in a multi-agent system."
"Then can voting solve the 'they are all wrong together' problem?"
"It can't. Voting does not cure correlated errors, and parallelism may add total tokens, coordination latency, and context copying cost; measure the actual changes," Lao Z said. "Don't split when steps depend strongly on each other, risk can't be isolated by role, or merging has no clear rules."
"Can the 'don't use multi-agent' cases go in a table too?"
"They can, and that table matters more than 'when to use it'." Lao Z wrote the signals down one by one:
| Signal | Why you shouldn't split | What fits a single Agent instead |
|---|---|---|
| every step depends on the previous step's judgment | the parallel gain is zero, only coordination cost is left | a single Agent runs the whole chain in series |
| merge rules can't be stated | conflict rulings degrade into whoever shouts loudest | a single Agent keeps a consistent view |
| subagents share the same material | outputs correlate, so parallelism amplifies | a single Agent plus clear acceptance criteria |
| risk can't be isolated per role | any one subagent leaking is everyone leaking | tighten permissions, don't run concurrently |
| the task has no acceptance criteria | nobody can say when it is done | define acceptance first, then discuss splitting |
"None of these signals exist in a single Agent," Lao Z said. "Dependency order is satisfied naturally, no merge is needed, and there are no two executors fighting over state. So judge in this order: check the table first, and if any row hits, don't split. If none hits, then ask whether the waiting parallelism saves is worth the cost you add."
"When the modifier and the verifier conflict, what does the main Agent rule on?"
"On reproducible evidence, not on who sounds more certain," Lao Z said. "A failed case in the test directory is reproducible: re-run it and it passes or it doesn't. The modifier's claim may be nothing more than 'I think this change is right'. The main Agent sides with the reproducible party and downgrades the other's conclusion to unproven. If neither side is reproducible — both are just natural-language assertions — then the task itself isn't at the stage where it can be split across multiple agents. Go back and write the acceptance criteria first."
"What's the difference between a 'read-only snapshot' and a 'branch workspace'?"
"A snapshot is a read-only copy: the subagent sees state as of one moment and cannot change the original files. It suits read-only work such as retrieval and analysis," Lao Z said. "A branch workspace is a writable copy: the subagent changes its own copy, and the main Agent decides how to merge it back to the main line. The difference is the merge cost. A read-only snapshot has no merge problem; a writable copy leaves conflicts for the main Agent to handle. So 'give every subagent its own workspace' is not free either. It moves conflicts from 'overwriting each other at run time' to 'a ruling by the main Agent at merge time' — and at least the second is explicit."
Key point
Multi-agent is a tool for concurrency and division of labor, not an automatic boost to intelligence. Independence, merge method, isolation, and acceptance: leave any one of the four out, and a single Agent is more controllable.
Summary
The value of multi-agent lies in breaking one large task into several subtasks that can advance at the same time, shortening total elapsed time — and the precondition is that the subtasks are independent of each other. Deciding whether to bring in multi-agent means answering four questions. Are the tasks genuinely independent, so one's output does not depend on another's? Can the separate outputs be merged without conflict? When something fails, can you locate which executor is responsible? Are each executor's permissions and isolation boundaries clear? If any one of these four cannot be answered, what multi-agent brings you is intermittent bugs that are harder to debug, and ownership that is harder to attribute.
Adding executors does not raise the intelligence of any single executor; it only adds coordination complexity. Two agents editing the same file at once means a merge conflict someone must rule on. One agent changes a configuration while another keeps deciding against the old value — whose error is that? These are problems a single Agent never meets and that appear only because you introduced multiple agents. Make the single Agent the default, and use parallelism only for the parts that genuinely parallelize, after independence, mergeability, and attributability have all been verified.
Each of the three structures has its own precondition and price: delegation buys parallel speed-up and pays aggregation cost; pipeline buys context focus and pays serial waiting; competition buys diversity of perspective and pays multiplied calls. Across all three, the most common failure is boundaries drawn in the wrong place: subtasks that look independent but share one output, handoffs that ship conclusion and process together, participants sharing material so their outputs correlate. The task card is the only way to write those boundaries down as fields: input, allowed tools, file ownership, output format, stop condition, failure mode, acceptance method — each one checkable, attributable, and auditable.
The control plane is the only party holding the global view: budget, task tree, ownership, and cancellation all belong to it. Failure propagates in three ways — isolated, blocking, terminating — and each must be written into the task card rather than improvised at run time. Cancellation can only be delivered best effort, so the task card must state how to wind down safely after it. In communication, pass only verifiable conclusions, evidence locations, and open questions; never drag whole passages of reasoning along. Control shared state with read-only snapshots, file ownership, or serialized writes — never with tacit agreement. Multi-agent is an additional engineering system: coordination cost, merge rules, isolation boundaries, failure semantics. Every one of them has to be designed explicitly, and if one is missing, a single Agent is more controllable.
Hands-on Verification
- Split one task into two subtasks that can run in parallel, and write for each its input, file ownership, permissions, and acceptance conditions.
- Stage an output conflict: two subagents disagree on the same conclusion. State who rules, and on what evidence.
- Record call count, elapsed time, and rework for one agent versus two subagents, then judge whether parallelism is worth it.
- Put one subagent on a timeout. Observe whether the control plane's cancellation lands immediately or waits for the subagent to reach a loop boundary, and record whether it is still writing files during that window.