Multi-agent orchestration and integration

Establish a measurable single-agent baseline before splitting into independent reasoning loops. Compute parallel limits from dependencies, define inputs, artifacts and commit ownership, and handle late results and recovery. Judge the change by complete-task quality, latency and cost.

From Workflows to Multi-Agent

A single Agent can also call independent tools in parallel; therefore, "needing to read multiple files simultaneously" does not necessarily require multiple reasoning loops. Multi-Agent is better suited for sub-tasks that require longer individual analysis, different information scopes, or independent workflows. Once each Worker forms its own context, returning compressed results and evidence locations to the Coordinator can reduce the amount of raw material the main context has to bear.

Multiple model calls do not automatically equal Multi-Agent. Fixed extraction, validation, and formatting pipelines can be implemented by standard workflows; dynamically decomposing tasks and allowing branches to proceed independently based on tool feedback is closer to the collaborative Agents discussed here. Building effective agents

Multi-Agent dialogue frameworks demonstrate the ability to combine roles, tools, and communication patterns, but providing a dialogue mechanism does not automatically ensure task correctness. When deciding which structure to adopt, refer to the AutoGen paper. First, identify the specific limitations of the current single-Agent approach, then verify whether adding collaboration improves it.

Map Dependencies First, Then Calculate Benefits

Assume a task consists of Preparation A, Implementation B, Independent Compatibility Check C, and Summary D. Both B and C require A's interface contract; D must receive results from both. If B and C can indeed proceed independently, the following parallel structure holds:

Serial time is 2+4+6+3=15 minutes; ideal parallel time is 2+max(4,6)+3=11 minutes, saving 4 minutes. If delegation, queuing, and merging conflicts take an additional 5 minutes, the total time becomes 16 minutes. Launching two Workers does not mean the task is twice as fast.

If C checks patches that B has not yet produced, C depends on B, and this diagram needs to be changed to serial; alternatively, C can first independently organize the check standards, and then verify after the patches are completed. Changing the task definition can create some parallel space, but you cannot use model guesses to eliminate real data dependencies.

duration = {"A": 2, "B": 4, "C": 6, "D": 3}
deps = {"A": [], "B": ["A"], "C": ["A"], "D": ["B", "C"]}
finish = {}
# This dictionary lists nodes in topological order of dependencies, not a general scheduler.
for node, minutes in duration.items():
    finish[node] = max((finish[x] for x in deps[node]), default=0) + minutes
assert finish["D"] == 11
assert sum(duration.values()) == 15
print("Ideal parallel minutes:", finish["D"])
print("Plus 5 minutes coordination overhead:", finish["D"] + 5)

Costs must also include the main Agent, all Workers, repeated reads, tool calls, and failed attempts. Using cheaper models for suitable sub-tasks may save money, but multiple independent windows will also redundantly load constraints and materials; whether prefix caching hits depends on the service, model, and input. It is not guaranteed that "opening sub-Agents is always cheaper than switching models in the main loop."

Engineering reports from actual Multi-Agent research systems discuss context isolation, independent research, and higher token consumption, while also pointing out coordination limitations for tightly dependent tasks. The benefits of such systems should be understood as specific cases, not as a universal acceleration factor for all tasks. Anthropic Multi-Agent Research System

Why does parallelism not scale by headcount?

Draw dependencies before estimating parallel benefits. Dependencies determine start times and merge consumes time too. Total work is 15 while the default critical path is 9: resource use and completion latency are different quantities.

$$T_{\mathrm{parallel}}=\underset{p\in \mathrm{paths}}{\max }\sum _{i\in p}{t}_i+T_{\mathrm{coordination}}$$

Delegation is Delivering a Task Contract

"You are responsible for checking compatibility" is too vague: which version to check, which interfaces, whether modifications are allowed, and what evidence is required are all undefined. The Coordinator should deliver complete information necessary for the Worker to complete the task, while avoiding dumping the entire main session history.

Whether tools, history, and file systems are shared depends on the runtime environment. Even with shared directories, Workers may not have read the files; even without shared history, necessary context can be restored through explicit inputs. Delegation messages should specify actually accessible resources, rather than assuming the other party "knows what was discussed earlier."

If the main task requires "only change Chinese first," this constraint must be passed to all Workers that might modify documents. The Main Agent's authorization is also not a reason to arbitrarily expand tool permissions: a read-only check task should receive the capabilities it needs, and out-of-scope findings should be returned to the Coordinator for decision.

Artifact Ownership and Result Acceptance

Define Boundaries for Writes

In a shared workspace, two Agents modifying the same file simultaneously may overwrite content; assigning different files does not necessarily mean independence, as they might jointly change an interface contract. You can choose to divide work by directory or artifact, use independent branches or working copies, and then have a clear Integrator merge them.

Isolated copies reduce direct overwrites but cannot avoid semantic conflicts. For example, if B renames a field to item_id, C's test might still assume the field is called sku; even if the patch texts can be automatically merged, integration will fail. Fixing interface versions in the contract and propagating changes to dependent parties first can reduce such wasted effort.

Summaries for Location, Evidence for Confirmation

A Worker returning "check passed" is insufficient. Results should include the input version targeted, the method used, accessible artifacts, and uncovered items. The Coordinator first checks goal coverage, then verifies versions and evidence, and finally decides to accept, supplement, or re-divide.

Independent review helps identify omissions, but another Agent using the same model might share the same bias. "Separating author and reviewer" provides role and context differences, but does not equal statistical independence or proof of correctness. Combining explicit standards, independent testing, actual execution, and necessary human review creates verifiable boundaries.

Why reject a successful worker result?

Archive all attempts, but integrate only results satisfying the current contract. Keep worker completion, result receipt and accepted integration as separate states, rather than overloading one success field.

Orchestration Requires Recovery Semantics

The Coordinator should save the task ID, attempt number, input version, status, and artifact location for each sub-task. Status should distinguish at least between queued, running, completed, accepted, failed, cancelled: Worker completion only means a result was produced; accepted means the Coordinator has confirmed it is available for overall delivery.

Assume Attempt 1 times out, and the Coordinator launches Attempt 2; later, the stale result from Attempt 1 arrives. If you only accept based on sub-task name, the old content will overwrite the new one. You need to verify late results against attempt numbers and input versions, and if necessary, keep them as references without automatically publishing them.

Cancellation does not guarantee that old Workers stop writing immediately. In shared resource scenarios, control commit permissions, for example, by having the Integrator verify the current valid attempt or version before writing to the authoritative artifact; otherwise, a Worker displayed as cancelled in the interface might still overwrite files in the background. Cross-executor state rules echo the conditional updates in Memory and State.

How to Judge if Multi-Agent Actually Provides Benefits

Compare single-Agent, single-Agent parallel tools, and Multi-Agent using the same task set, keeping tool permissions, input evidence, and acceptance criteria as consistent as possible. In addition to task success rate and total latency, record the Main Agent's coordination time, proportion of duplicate work, number of conflicts, failure retries, and total costs.

If Workers are fast but the Main Agent spends a long time clarifying and merging, the bottleneck is task decomposition or result contracts; if two Workers always query the same materials, the scopes might overlap; if integration always fails after merging, check shared interfaces and integration tests. If single-Agent batch tools achieve the same effect, there is no need to increase maintenance costs just for the sake of having more roles.

More detailed metrics and per-task tracking are expanded in Evaluation and Observability. The unit of evaluation should be the user's complete task, not just counting how many Agents were started or how many messages were generated.

Continue with：Evaluation, trials and observability。