Multi-agent Systems: Organizing Complex Tasks with Boundaries, Parallelism, and Independent Verification

Copying the same prompt to five Agents does not automatically produce a team. Five Agents that read the same input, hold the same permissions, and give similar answers have a 'division of labor' that exists only in their role names, not in the actual work. Real division of labor comes from differences in input, permissions, completion conditions, or verification perspectives, rather than from different role names: an Agent deserves to exist because it receives different materials from others, can do things others cannot, is asked to deliver different results, or independently verifies others' conclusions.

Therefore, deciding whether to introduce a multi-agent system should start from a clear bottleneck in a single Agent, not from the intuition that 'more people means more strength'. If a single Agent's context window can hold all the materials, the steps are strongly dependent and must run strictly sequentially, and each step's tool calls are very short, then a multi-agent architecture brings no benefit—it merely adds repeated reading of the task, message passing, and arbitration on top of the same task. Each Agent has to re-understand the task background, and the coordinator still needs time to summarize and adjudicate, so on simple tasks this overhead is pure waste.

Conversely, several signals indicate that splitting is worthwhile. First, there are mutually independent data sources that can be read and processed in parallel. Second, different subtasks require different permissions and must be isolated; an Agent with write permission should not simultaneously hold resources that should be read-only. Third, candidate solutions can be independently generated and independently verified—multiple Agents each provide a plan, and another perspective checks it. Fourth, a single context becomes polluted with irrelevant material; stuffing in too much content unrelated to the current step actually harms accuracy at each step.

The essence of a multi-agent system is to split a task among multiple boundary-constrained Agents, with a coordinator responsible for merging and verification. Its inputs are a single Agent's clear bottleneck, task dependencies, and an acceptable interface; its outputs are role-based subtasks and a unified result. The trade-off of the whole system is: using communication cost to buy parallelism, permission isolation, or independent review. When task steps are strongly dependent, tool calls are short, or interfaces between subtasks are poorly defined, adding Agents only replicates context and replicates errors, making results worse rather than better.

The topology of a multi-agent system describes how Agents are connected, who assigns tasks, how messages flow, and how results are merged. Topology selection does not change the capabilities of a single Agent; it changes the control problem: where to place responsibility, where to place parallelism, and where to place conflict. Each of the four basic topologies corresponds to one advantage and one primary failure mode.

The Manager-worker topology concentrates responsibility and budget in the hands of a manager Agent. The manager decomposes tasks, assigns sub-tasks, collects results, and makes the final decision; workers only handle execution. Its advantage is clear responsibility and controllable budget—every expense and every conclusion has a clear owner. Its failure mode is equally clear—the manager itself becomes the bottleneck. When the number of sub-tasks increases, or when every result requires manager adjudication, the manager becomes the upper limit on throughput, and the system degenerates into a serial narrow channel.

The Pipeline topology cuts a task into stages, where the output of the previous stage is the input of the next, and stage interfaces are clear. Each stage's Agent only needs to care about its own input contract and output contract, so individual stages can be deeply optimized and independently replaced. Its main failure is the layer-by-layer amplification of upstream errors: because each step trusts the output of the previous step, early deviations are processed downstream as facts, eventually amplifying into completely wrong conclusions that are difficult to trace back to the source.

The Peer-to-peer or Debate topology gives multiple Agents equal status; each independently produces candidate answers, and a winner is selected through comparison or debate. Its advantage is producing diverse candidates and avoiding premature convergence on a single viewpoint. Its failures are round inflation and herd behavior: debate can continue indefinitely, consuming budget in each round; and when some Agents are more articulate, the correct minority opinion may be overwhelmed by the majority or by more forceful expression.

The Blackboard or shared-state topology lets all Agents read and write a shared state; each asynchronously takes tasks and writes results, naturally supporting asynchronous collaboration and recovery from failures—if one Agent fails, it does not block other Agents, which can continue working on the shared state. Its main failures are stale writes and conflicts: two Agents each write based on the same old version, and the later overwrite loses the earlier work, or produces mutually contradictory intermediate states.

These topologies can be mixed; for example, a stage within a pipeline can use peer debate internally. However, regardless of composition, four elements must be unique and explicit: a unique task ID, the owner of each sub-task, termination conditions, and the final acceptor. The task ID ensures every message can be attributed to a specific task; the owner ensures every result has someone responsible; termination conditions define when the system stops; the final acceptor defines whose conclusion counts. Free-form dialogue is not a coordination protocol—discussions without an ID, owner, and termination conditions only postpone uncertainty rather than solve the control problem.

The inputs to topology selection are the task's dependency structure, degree of control centralization, parallelism requirements, and shared-state approach; the output is one of Manager-worker, Pipeline, Peer-to-peer, or Blackboard, or a combination. Each topology works with different messaging rules and ownership rules, but all must specify the task ID, termination conditions, and acceptor. Note that topology names only describe the coordination structure itself; they do not guarantee informational independence among participants, nor do they guarantee that the final conclusion is correct.

A concrete example makes the upper bound of parallel benefit and the real overhead clear. Suppose a task contains three mutually independent research items, each taking 20 minutes, and after the research is complete it takes 10 minutes to combine the results. In single-agent serial execution, they can only be done one after another: 20 + 20 + 20 + 10 = 70 minutes. This is the baseline without parallelism.

Now let three workers execute the three research items in parallel, with each worker responsible for one. The three research items run concurrently, and the user's waiting time no longer accumulates; instead, it is the longest branch—the critical path. All three research items take 20 minutes, so the critical path is max(20, 20, 20) = 20 minutes, plus the 10-minute merge that must be done serially, for a total of 30 minutes. The ideal speedup is 70 ÷ 30 ≈ 2.33×.

This 2.33× is an ideal value; it assumes the three branches are completely independent, resources are ample, and the merge cost is unchanged. Real-world parallelism introduces additional overhead. Suppose each worker needs 5 minutes before starting to reread the task background—because every agent has to re-understand the problem—then the actual duration of each branch becomes 25 minutes. And suppose that conflicts arise from parallelism, increasing the merge time from 10 minutes to 20 minutes. The total parallel duration is then 25 + 20 = 45 minutes, and the speedup is only 70 ÷ 45 ≈ 1.56×. More notable is total work time: serial execution has 70 minutes of total work time, while in parallel the three workers each work 25 minutes and the merge worker works 20 minutes, totaling 25 × 3 + 20 = 95 minutes, which is 25 minutes more than serial.

This reveals the nature of parallel optimization, which can be expressed with two formulas. The lower bound for parallel wall-clock time is: T_parallel ≥ max(T₁, T₂, …, Tₙ) + T_merge, where T_parallel is the wall-clock time the user actually waits, Tᵢ is the duration of the i-th branch, T_merge is the merge duration that must be completed serially, and n is the number of branches. Total work cost is: Work = W₁ + W₂ + … + Wₙ + W_merge, where Wᵢ is the workload of the i-th branch and W_merge is the merge workload. Wall-clock time is determined by the slowest branch plus the serial merge, while total cost is the sum of the workloads across all branches.

Taken together, the two formulas show a key point: parallelism optimizes wall-clock time—that is, the time the user waits—and does not necessarily reduce token consumption or cost; in fact, it often increases total cost. Parallelism makes users feel it is faster because it spreads the work that would otherwise accumulate serially across multiple branches running at the same time; but none of this work disappears, it just changes location. Strong dependency chains cannot bypass the critical path—if the second step must wait for the result of the first, then no matter how many agents are added, the shortest time for this chain will not become shorter. Therefore blindly adding agents only pushes up total cost, while the wall-clock time benefit may be substantially eroded by repeated preparation and merge conflicts.

The inputs to this example are the durations of the three branches, the repeated preparation cost, and the merge cost; the outputs are the critical-path wall-clock time, total work time, and speedup. 70 ÷ 30 ≈ 2.33× is the ideal speedup; after adding the overhead of repeated background reading and merge conflicts, it is only 1.56×. The calculation holds under the premise that resources are ample and branches are mutually independent; once strong dependencies or queueing occur, actual benefits decline further.

A single sentence like “go research competitors” is difficult to merge because it doesn’t specify anything that can be accepted: which competitors to research, what materials are allowed, what form the result should be returned in, how much budget to spend, and what counts as done. When multiple agents each execute such a sentence according to their own understanding, the results they return differ in format, standards, and coverage, and the merger has to reread every long chat transcript to guess what they actually did. Task contracts exist to solve this problem: before delegating each subtask, write down the boundaries necessary for acceptance.

A task contract must declare the following: the scope of the subtask, the materials allowed, the output schema (i.e., the fixed structure of the returned result), budget, deadline, explicitly prohibited actions, source requirements, and machine-checkable completion conditions. The former items define “what to do, what to use to do it, and what the result should look like,” and the last item defines “how to determine that it is done.” Completion conditions must be machine-checkable, not something a person reads and then judges subjectively, so that merging and acceptance can be automated and repeatable.

The division of labor between manager and worker under the contract becomes clear as well. The manager delivers minimal sufficient context, rather than stuffing the entire historical chat transcript into the worker—extra history only contaminates judgment and wastes budget. The worker returns four things: results, evidence, unresolved issues, and confidence bounds, rather than returning unstructured long chat transcripts. Results answer “what did I conclude,” evidence answers “on what basis,” unresolved issues answer “what is still missing,” and confidence bounds answer “how reliable is this conclusion.” With these four items, the merger can judge whether the results can be used without reconstructing the worker’s thought process.

Permissions must be assigned by role; this is the source of the isolation value in a multi-agent system. Researchers have read-only access, executors can write but cannot self-approve, and verifiers cannot modify the artifact being verified. These three rules separate “doing” from “approving”: those who can modify the artifact have no authority to declare it qualified, and those responsible for declaring it qualified have no ability to change the artifact. Only when permissions are truly isolated does the isolation brought by multiple agents become real control, rather than multiple people in name only.

The inputs of a task contract are the subtask scope, materials, schema, budget, permissions, and completion evidence; the output is a delegation order that can be executed independently and merged. The manager provides minimal context, and the worker returns structured results, sources, gaps, and confidence bounds. It is necessary to clarify the boundary of the contract: contract approval only means that the handoff is checkable; it does not guarantee that the research facts are correct—a perfectly formatted result may have entirely wrong content. What the contract guarantees is the ability to be accepted itself, while content correctness still depends on permission separation and subsequent independent verification. Write permission and self-approval must be separated; this cannot be omitted just because there is a contract.

The task dependency graph answers “which steps can be done at the same time,” and verification gates answer “which results can be trusted to be merged together.” On the diagram, the two appear as two completely different arrows: dependency edges represent causal constraints that must be waited for, and verification edges represent trust permission to enter merging.

The structure in the diagram is as follows: the manager splits the task into three parallel subtasks and assigns them to three workers. The three workers execute independently and write their results into a versioned shared state—versioning means each write carries a version number, and later writes do not silently overwrite earlier work. After each worker's result is written and before it enters merging, it must undergo independent verification. Only artifacts that pass verification are accepted by the merger and merged into the final result.

The first message this diagram conveys is: parallelism is proven by the dependency graph. If there is no dependency edge between Task A and Task B, they can run in parallel—here “parallel” is scheduling permission, meaning the system allows them to run at the same time, not that it forces them to run at the same time. If A's result is B's input, then there is an edge that must be waited for between them; no matter how many AI Agents you add, the order of this edge cannot be bypassed. Therefore, judging parallel capability depends on whether the dependency graph has shared predecessors, not on how many AI Agents there are.

The second message is: trustworthiness is established by independent verification. Parallelism can only ensure results arrive quickly, not that they are correct. Three workers based on the same incorrect material may give the same incorrect answer; parallelism only makes errors arrive quickly as well. The role of the independent verification gate is to block untrusted artifacts before merging, so that the merger accepts only verified results. Trusted merging depends on verification gates, not on the number of participants.

The inputs of the dependency graph are subtasks, ordering constraints, shared state, and verification gates; the outputs are parallelizable branches, edges that must be waited for, and the final merging path. Dependency-free branches write to the versioned state in parallel, and the merger accepts only verified artifacts. This diagram also delineates the boundary of capability: chat count is not system capability, and a few more back-and-forth conversations cannot replace the dependency graph and verification gates; when independent evidence is lacking, multiple branches will still make mistakes together—they are each busy, but may trip at the same place. Parallelism addresses wall-clock time, verification addresses trustworthiness, and the two must be guaranteed by different mechanisms.

When two workers update the same conclusion at the same time, the last writer's version is not necessarily correct. The order only shows who pressed save last, not whose conclusion is more reliable. What shared state needs to solve is precisely this problem that "order does not equal correctness."

What is written to shared state should be structured content: tasks, facts, decisions, artifacts, and verification results, each with a version number. The purpose of versioning is that any update can be traced back to which old version it was based on and what changes it introduced, rather than silently erasing the old content. Message passing here only plays the role of notification: it only carries the task ID and a summary of the changes, telling other Agents "something has changed and what changed", while the actual data body resides in shared state. Messages should not carry the full content; otherwise the message flow itself becomes another unreliable, easily lost shared state.

Concurrent writes are constrained by one of three mechanisms: owner, optimistic locking, or event log. The owner mechanism stipulates that only a certain Agent has the right to write a particular record; optimistic locking requires that a write include the version number that was read, and if the version number has already changed, the overwrite is rejected; the event log appends all changes in order, preserving history by appending rather than overwriting. When a conflict actually occurs, the rule of "last writer wins" must not be adopted; instead, both candidates must be retained and handed to an arbiter for adjudication. In this way the conflict itself is recorded, rather than being silently eliminated by some overwrite.

Each conclusion must also be accompanied by metadata: source, producer, time, applicable scope, and status. Source answers "where the conclusion came from"; producer answers "who produced it"; time answers "when it was produced"; applicable scope answers "under what conditions it holds"; status answers "whether this is a draft, verified, or deprecated." With these five items, a merger can judge whether a conclusion is still usable now.

Retries also need state coordination: when a worker retries, it uses an idempotent task ID, ensuring that repeated execution of the same task will not produce duplicate branches or duplicate side effects. If the task ID already has a completion result recorded in shared state, the retry simply reads the old result and does not execute again.

The input to shared state is tasks, facts, decisions, artifacts, and versions; the output is recoverable records with owner, source, and conflict status. Messages only notify the ID and change summary; writes use optimistic locking or event logs to detect concurrent conflicts. Last write does not mean more correct; conflicts must retain candidates and be arbitrated; and the idempotent task ID is only responsible for preventing duplicate side effects—it does not resolve real conflicts between two different tasks.

Five agents using the same model may give a consistent answer and still all be wrong. Because “agreement” only means they made the same mistake, not that the answer is correct. Independent agents and independent evidence are two different things: an agent is the role that executes the task, and evidence is the basis that supports a conclusion. No matter how independent the roles are, if the information behind them comes entirely from the same source, then their conclusions are just five copies of the same error.

The correlation of errors comes from shared underlying conditions: the same model, the same prompt, the same retrieval corpus, and the same training data can all cause different agents to produce highly correlated errors. Changing the persona—making one agent pretend to be a “cautious analyst” and another a “radical critic”—does not increase mechanistic diversity, because they still read the same materials and run on the same reasoning. True independent verification must come from different information or verification mechanisms: different data sources, different tools, executable tests, formal rules, or genuinely independent models and people. Running an executable test once is more persuasive than having ten agents recite verbally, because the test result does not depend on any agent’s “judgment.”

During verification, you also need to guard against anchoring: if a verifier collects evidence only after seeing the candidate answer, it will be led by the candidate answer and only look for supporting material while ignoring refutations. Therefore, the verifier should work independently under conditions uncontaminated by the candidate answer, or at least fix the evidence first before comparing it with the conclusion.

The point beginners most easily confuse is this: calling the same model multiple times only starts multiple processes, it does not obtain multiple independent knowledge sources. These processes share the same parameters and training data, and their “consensus” is essentially a repetition of one sample under different prompts. Consensus only counts after being verified by external evidence; majority voting itself is not evidence.

The inputs of independent verification are the candidate conclusion, data sources, tools, and the verifier’s perspective; the output is one of three judgments: the external evidence supports the conclusion, contradicts it, or is “uncertain.” Different model calls increase independence only when the information or verification mechanism is genuinely different; merely changing the name or persona does not constitute independence. Shared training data, prompts, and retrieval corpora cause correlated errors, and correlated errors cannot be masked by majority voting—because every vote in the majority comes from the same source of error. To judge whether a multi-agent system is truly “independent,” you need to look at whether the evidence behind it is independent, not how many agents it has.

Agent A asks B to check, B then asks A to supplement, A again asks B to review—if such back-and-forth is not constrained by rules, it will never stop on its own. Termination, retries, and loop prevention are not after-the-fact remedies, but part of the control protocol and must be defined before the system starts.

The control protocol needs to define five types of boundaries: delegation depth, per-role budget, maximum number of rounds, no-progress criterion, and a single completion status. Delegation depth limits how many levels a task can be delegated downward, preventing tasks from being endlessly split into smaller pieces; per-role budget limits the amount of resources each Agent can spend; maximum number of rounds sets a hard upper limit on back-and-forth interactions; the no-progress criterion defines what counts as "going in circles"; the single completion status stipulates that a task has only one way to be marked complete, avoiding multiple Agents each announcing completion and causing inconsistent status.

The most critical rule among them is: every return must point out a new gap and a verification method. When B returns the task to A, B cannot just say "take another look"; B must explain what the previous round's result lacked and what method can verify the supplemented content. This rule turns "discuss again" into directed progress: each time the task is returned, the problem must become more specific, rather than spinning in place. If a return cannot identify a new gap, that is no progress and should be terminated.

Different types of failures need different handling paths, not blanket retries. Tool errors use bounded retries—for example, if a query times out, retrying two or three times is reasonable, but cannot retry indefinitely. Logical conflicts go to arbitration—when two conclusions contradict each other, a role with adjudication authority decides. Unverifiable conclusions are escalated to a human, or explicitly returned as "incomplete"; unlimited "discuss again" is not allowed to cover up verification failure.

The inputs to the control protocol are delegation depth, budget, number of rounds, progress evidence, and tool errors; the output is one of five actions: continue, retry, arbitrate, escalate to human, or stop. Terminate when there is no progress or the budget is exhausted. It is necessary to distinguish "stop" from "success": stop means the system no longer works automatically; it does not mean the task has succeeded. A task that stops because the budget is exhausted may have failed, but the system merely reports the failure truthfully. Unverifiable conclusions should be explicitly returned as "incomplete", rather than giving a seemingly complete wrong answer. Letting the system stop when it should stop and truthfully explain the reason for stopping is itself part of the multi-agent system's capabilities.

Improved success rate doesn't directly mean the multi-agent structure is better—it could just be because four times the tokens were spent. When evaluating multi-agent systems, you must exclude the confounding factor of “spending more money” to attribute gains to the structure itself.

Baselines cannot be just one. At minimum, include four types of comparisons: single agent, single agent with equal budget and multi-sampling, deterministic parallel workflow, and multi-agent. The single agent is the lower-bound baseline; single agent with equal budget and multi-sampling answers “If I give all the budget spent by multi-agent to one Agent for repeated attempts, what happens?”; deterministic parallel workflow answers “If I use a script instead of an Agent to do the parallel work, does the benefit remain?”; multi-agent is the system under evaluation itself. Only when multi-agent surpasses the preceding baselines under the same budget does its structural advantage hold.

Evaluation must report not only the final success rate, but also task success, critical path latency, total token/tool cost, redundant work, handoff loss, conflict rate, ineffective turns, verification detection rate, and human intervention. Success rate only says whether the result is correct; critical path latency says how long users wait; total cost says how much resources were spent; redundant work says how much budget was wasted re-reading the task; handoff loss says how much information was lost between Agents during transfer; conflict rate and ineffective turns say how inefficient the coordination itself is; verification detection rate says how many errors the verification gate actually caught; human intervention says how many times the system was forced to hand back to humans. Only by looking at quality, latency, cost, and coordination overhead together can we judge whether multi-agent is worth it.

Ablation is a method for locating the source of benefits: remove role isolation, shared state, independent verification, or parallelism one by one, and see which one causes a significant performance drop when removed. If removing independent verification gives equally good results, it means the verification gate contributed nothing; if removing parallelism makes results better instead, it means parallelism is pure overhead on this task. Ablation turns “the structure is good” from a vague statement into “exactly which component is useful.”

Evaluation data should also be sliced by degree of parallelism, dependency depth, and task length to avoid using a few cases most suitable for parallelism to represent all tasks. A highly parallelizable research task can achieve a nice speedup, but that does not mean a strongly dependent writing task can too. Report the hardest-to-parallelize and easiest-to-parallelize tasks separately to see under what conditions the structure is effective and under what conditions it fails.

The inputs to multi-agent evaluation are single Agent, multi-sampling, deterministic workflow, and multi Agent schemes under the same task and same budget; the outputs are quality, critical path, total cost, handoff, and verification metrics. Ablate role isolation, shared state, and parallelism to locate the source of benefits. Two conclusions must be upheld: if the success rate improves only because more tokens were spent, it cannot be attributed to structure; a few highly parallelizable cases also cannot represent all tasks.

If total token usage suddenly doubles, it could be normal parallelism or an Agent stuck in circular delegation. To distinguish the two, cost and observability must be attributed by task tree—every cost must be traceable to the exact node on the exact task tree it belongs to.

Building the task tree starts with a trace ID: each root task generates a trace ID, and each subtask records parent ID, role, input version, start/end time, model, tokens, tools, retries, and artifact hash. The parent ID lets a subtask attach back to the parent node; the role explains who is doing the work; the input version ensures the result maps to the specific input; timestamps give the time order; tokens and tools record actual consumption; retries record wasted effort; and the artifact hash makes results locatable and verifiable. With this set of fields, any cost can be attributed to a specific subtask rather than being recorded at the whole-system level.

Observability must show two durations at the same time: critical path time and total work time. The former explains user waiting—users care how long the slowest branch plus serial merging takes; the latter explains cost—billing cares about the sum of work across all branches. Looking at only one leads to misjudgment: high total work time and low critical path time indicate excessive parallelism, with many Agents doing duplicated or ultimately discarded work; low critical path time alone may seem efficient, but the bill may have quadrupled. Showing the two metrics side by side lets you see both speed and savings.

Costs must also be broken down by work type: research, merging, verification, and rework. Only by separating them can you discover that the merger is over-summarizing or that workers are repeatedly retrieving. When merging cost exceeds branch cost, it often indicates inconsistent output contracts, forcing the merger to do extensive parsing and conflict arbitration; a high rework ratio indicates that work before the verification gate was not done correctly the first time. Breaking down by type translates "the system is busy" into "which type of work is heaviest and why."

Budget control must also be layered: set branch budgets and a global budget. When a subtask exceeds its budget, it must not delegate further on its own—that would push budget pressure onto deeper nodes—but should report current evidence, gaps, and the marginal benefit of continuing work to the owner, who decides whether to approve additional budget. For shared caches, record hits and sources to avoid misattributing savings from cache hits to the multi-agent architecture: cache speedup is an engineering optimization, not a structural advantage.

Diagnostic signals correspond to possible problems: high total work time and low critical path point to excessive parallelism; you should compare idle artifacts and duplicate artifacts. A continuously growing return-delegation depth points to unclear completion conditions; you should check whether each return delegation produced new evidence. Merging cost exceeding branch cost points to inconsistent output contracts; you should count parsing attempts and conflict types.

The inputs to task-tree observability are trace ID, parent-child relationship, role, version, tokens, tools, retries, and artifact hash; the outputs are critical path duration and total cost broken down by research, merging, verification, and rework. The former explains user waiting; the latter explains cost; only by reporting both together can excessive parallelism be identified. Cache hits and external queueing must be attributed separately: cache savings must not be credited to the multi-agent approach, and external queueing delays must not be blamed on the multi-agent approach.

Connect the entire causal chain together: the design and operation of a multi-agent system follows a path from problem to verifiable practice, with each step providing input for the next, and finally returning to evaluation to check whether the original problem was actually solved.

First, prove the single-agent bottleneck. The reason for splitting must come from evidence—insufficient context, the need for permission isolation, candidates needing to be produced or verified independently, a single context contaminated by irrelevant material—not from an intuition of "more hands make light work." Without a clear bottleneck, multi-agent systems only duplicate context and errors.

Second, map task dependencies and the critical path. Decompose the task into subtasks, marking which edges must wait and which branches can run in parallel. The critical path determines the lower bound on wall-clock time: the slowest branch plus serial merging. The dependency graph justifies parallelism and also reveals which chains cannot be accelerated.

Third, choose the topology and define role contracts. Based on the dependency structure, degree of control centralization, parallelism requirements, and how shared state is handled, choose a manager-worker, pipeline, peer-to-peer, or blackboard topology, and for each subtask write clear scope, materials, output schema, budget, deadline, prohibited actions, and machine-checkable completion conditions.

Fourth, allocate minimal context and permissions. The manager delivers only the context needed to complete the task, not a dump of the entire history; permissions are isolated by role—researchers have read-only access, executors can write but cannot self-approve, verifiers cannot modify the artifacts being verified. Permission isolation makes multi-agent a real control mechanism rather than nominal division of labor.

Fifth, execute in parallel and write versioned state. Branches without dependencies run in parallel, and results are written to versioned shared state, with concurrent writes constrained by ownership, optimistic locking, or event logs; on conflict, keep the candidate rather than letting the last writer overwrite.

Sixth, independently verify results and evidence. Verification comes from genuinely different information or verification mechanisms—different data sources, tools, executable tests, or independent models—not from a consistent vote count of same-source Agents. Verifiers avoid being anchored by candidate answers.

Seventh, arbitrate conflicts and send back specific gaps. Logical conflicts go to arbitration, and each reassignment must identify a new gap and a verification method, preventing an infinite loop of "let's discuss it again."

Eighth, terminate according to completion conditions and compare against baselines. Terminate when the budget is exhausted or there is no progress, and truthfully report whether the task is incomplete or failed; finally compare against single-agent, multi-sample, and deterministic workflow baselines with the same budget, using indicators such as critical path, total cost, handoff loss, and verification discovery rate to judge whether the structure actually brought benefits.

These eight steps form a closed loop: starting from the bottleneck, through dependency graphs, topology, contracts, permissions, parallelism, verification, and termination, each step answers the question left by the previous step, and finally using baseline comparison returns to the starting point to check whether the originally identified bottleneck was truly alleviated, and whether the cost paid for it was worth it.