How should multi-agent tasks be broken down? A collaboration method from dependency graphs to result aggregation
Adding more agents will not automatically make a task faster. What truly determines the quality of collaboration is whether subtasks are independent, inputs are fixed, writes are isolated, and aggregation follows a unified standard. If these boundaries are not clearly defined, parallel execution will only create duplication, conflicts, and rework.
Break down deliverables before assigning roles
“Research agent, writing agent, review agent” are merely role names. Writing depends on the research results, and review depends on the draft, so the three still form a sequential chain. A more effective approach is to list the final deliverables first, then specify the input, output, and completion criteria for each one.
| Subtask | Input | Output | Dependency assessment |
|---|---|---|---|
| Source verification A | Frozen list of questions | Conclusions, sources, and unconfirmed items | Can run in parallel with other source verification tasks |
| Source verification B | The same list of questions | Conclusions, sources, and unconfirmed items | Can run in parallel |
| Difference analysis | All verification results | Points of agreement and conflict | Must wait for verification to finish |
| Final drafting and acceptance | Difference analysis and formatting specifications | Final deliverable | Sequential finalization |
Draw a minimal dependency graph
- If B must read A’s result, A and B must run sequentially.
- If A and B only read the same frozen materials, they can run in parallel.
- If a decision can only be made after multiple branches finish, use parallel execution followed by centralized aggregation.
- If multiple branches need to write to the same object, first separate their write areas or switch to sequential execution.
This step retains the original three-part approach of “task decomposition—parallel scheduling—result aggregation,” but shifts the key assessment from platform capabilities to dependencies that users can actually inspect.
Four conditions that must be met before parallel execution
- Fixed inputs: They will not be rewritten by other branches during execution.
- Isolated writes: Each branch has its own file, record, or namespace.
- Standardized outputs: Field, format, and evidence requirements are consistent.
- Failure isolation: If one branch fails, the other results can still be retained and the failed branch rerun independently.
Give each subtask a task card
A task card does not need to be long, but it should include the objective, available materials, prohibited actions, output structure, completion criteria, timeout behavior, and failure response. For fact-based tasks, it should also require sources and uncertain items to be returned.
- Objective: Address only one verifiable question.
- Input: List the materials that may be read, and do not allow branches to expand the factual scope on their own.
- Output: Use a standardized JSON, table, or section structure.
- Completion criteria: Explain what counts as complete and how missing information should be marked.
- Prohibited actions: Do not publish, delete, or modify shared resources.
Aggregation is not simply stitching answers together
The aggregator must check for missing, duplicate, and contradictory information. When conclusions differ, compare their sources, dates, and criteria; if the evidence is insufficient, preserve the disagreement. Assign the final external write to only one executor, and perform it only after aggregation and confirmation.
- Check whether all expected branches have returned results.
- Deduplicate by unique identifier while retaining the sources.
- List conflicting conclusions separately instead of silently overwriting them.
- Generate the final version according to the acceptance criteria.
- If external effects are required, perform centralized confirmation and writing afterward.
When should you avoid using multiple agents?
- The task is very small, and the cost of decomposition and aggregation exceeds that of execution itself.
- The steps are strongly interdependent, making it impossible to fix the inputs in advance.
- Multiple branches must frequently modify the same resource.
- There are no clear acceptance criteria, so results can only be judged by vague preferences.
Small-scale failure drill
Start with a small number of low-risk branches, and deliberately make one of them time out or return results with missing fields. Check whether the other branches can finish, whether the failed branch can be rerun independently, and whether the aggregation accurately shows the missing items. Increase concurrency only after the drill succeeds. SmaugBrain can be used to organize such branches, but users must still define the task boundaries.
Frequently asked questions
Do more agents make tasks faster?
No. Total execution time is also affected by the slowest branch, concurrency limits, aggregation, and retries. Only independent tasks can potentially reduce waiting time through parallel execution.
How can multiple agents be prevented from overwriting one another?
Have each branch write to an independent target and use a unique identifier. Shared materials should be read-only, and the final merge should be performed by a single aggregator.
How can output consistency be ensured?
Standardize the task cards and output schema, then validate fields, evidence, and formatting during the aggregation stage. Shared prompts alone cannot replace acceptance criteria.