More agents do not automatically make a team

A team is created not by adding voices, but by combining complementary capabilities, clear ownership and verifiable integration.

The idea sounds immediately plausible: if one language model is helpful, five specialised models should be more helpful. One researches, one plans, one writes, one reviews and another chooses what happens next. On paper this resembles a well-organised professional group. In practice it can become a circular conversation that repeats the same assumptions, mutually confirms errors and consumes more context on coordination than on the task itself.

Multi-agent architecture is neither decoration nor a maturity badge. It is an answer to a specific structural problem. Value appears only when a task can be decomposed meaningfully, roles possess genuinely different capabilities or tools and outputs are integrated under control.

Role descriptions do not create specialisation

„You are the researcher", „you are the critic" and „you are the project lead" sound like division of labour. If all three use the same model, sources, context and evaluation logic, their diversity may remain superficial. Tone changes, but blind spots do not necessarily change.

Real specialisation comes from different access and accountability. The research agent may open primary sources and create evidence cards. The data agent can inspect structured files and reproduce calculations. The editor may formulate but may not invent facts. The evaluator receives test cases and acceptance criteria but cannot modify the artifact under review. A human owner resolves high-impact conflicts.

A role therefore becomes a contract of inputs, tool access, output schema, quality gate and boundary — not merely a persona. If two roles have the same contract, the design should question whether two agents are needed.

Design the task before the team

Good orchestration begins not with imaginative agent names but with task dependencies. Some work is independent: three well-separated source domains may be searched in parallel. Other work is strictly sequential: evaluation can begin only after cleaning and calculation. Some work requires feedback, such as drafting, testing and correction.

This structure becomes a task graph. Every node has expected inputs, an output, an owner and a completion criterion. Edges represent real dependencies. Only then should a designer choose rule-based code, one agent, parallel agents or a person for each node.

This avoids the most common failure: distributing a trivial linear procedure across several agents, making it slower, more expensive and harder to verify. A single agent with good tools is often the stronger architecture for a short, well-defined process.

The orchestrator is not an omniscient manager

Research systems such as Magentic-One use an orchestrator to decompose work, select specialists, track progress and replan after failure. The pattern is useful, but the orchestrator is still probabilistic. It can cut the task poorly, assign the wrong role or believe an optimistic status report.

It therefore needs structured ledgers rather than conversational memory alone. A Task Ledger stores task, dependency, owner, state and acceptance. An Evidence Ledger connects claims to sources and checks. A Decision Ledger records choices, alternatives and rationale. The orchestrator may append or update controlled fields but should not silently rewrite history.

The orchestrator itself needs evaluation: decomposition quality, assignment accuracy, unnecessary delegation, repetition, integration errors and safe stopping. More communication is not evidence of better coordination.

Shared context can connect and contaminate

A fully shared chat appears transparent because everyone sees what others produced. It also promotes convergence. One early false assumption can spread across every role. Repeated intermediate output starts to look true. Long dialogue displaces primary data and precise instructions from usable context.

Complete isolation creates a different problem. Separate agents duplicate work, use incompatible terminology and miss central decisions. Selective communication is the better pattern. Specialists receive only the sources, rules and predecessor outputs needed for their task. Instead of full transcripts, they receive structured handoffs: objective, valid inputs, claims with evidence, open uncertainty and expected output schema.

The shared space contains controlled project state, not every reasoning fragment. Local scratch work may remain private; decision-relevant facts enter the ledger. This reduces context load while preserving provenance.

Messages need protocols

Free conversation is flexible but difficult to test. A dependable system defines message types. Delegation includes objective, scope, inputs and deadline. A result includes artifact, evidence, uncertainty and satisfied criteria. A question identifies the blocking ambiguity. An escalation describes risk, options and the decision required.

This prevents a polite response from being mistaken for completion. „Looks good" is not a test result. „Test case 4 failed; cause unknown; publication blocked" is a machine- and human-readable state.

Messages also carry identity, timestamp, task ID, artifact version and, where useful, a hash. The system can then reconstruct which agent transmitted which information on what basis. W3C PROV offers a formal model; smaller projects may use a lighter event record.

Parallelism pays only with real independence

Parallel agents can explore large search spaces faster. A research report may divide genuinely independent questions. An engineering account of a production multi-agent research system also shows that decomposition, delegation, synthesis and evaluation remain central engineering challenges.

Parallelism helps when subtasks share little intermediate state and outputs are clearly comparable or composable. It hurts when every step depends on the previous one, several agents modify the same file or synthesis becomes harder than the original task.

Define a conflict model before execution. Which artifacts are exclusive? Who may write? How are duplicates detected? What happens when findings disagree? Without ownership and merge rules, parallel work mainly creates integration work.

Criticism is not proof

A common pattern lets one agent write and another criticise. This can reveal weaknesses, but the critic is not automatically correct. It may reject valid claims, introduce new errors or present style preferences as quality defects.

An evaluator needs criteria and access to evidence. Facts are checked against primary sources, calculations reproduced, formats validated deterministically and safety boundaries attacked with negative tests. Subjective qualities such as clarity or tone use rubrics and examples. High-impact decisions receive escalation thresholds.

Independence does not come merely from a second model instance. It increases through separate evidence paths, different tools, blind review, deterministic tests and accountable expertise. If creator and reviewer rely on the same false source, consensus does not make the claim true.

Team errors can propagate

In a single agent, an error begins locally. In a network it can become a message, a decision and a new input. A compromised specialist may send manipulated data to the orchestrator, which distributes it as project state. OWASP therefore treats multi-agent systems as an expanded attack surface involving identity, messaging, memory and tools.

Every trust boundary needs validation. Agents must not adopt external content as system instruction. Tool outputs are checked for schema and plausibility. Roles authenticate, privileges remain minimal and sensitive data reach only necessary recipients. Critical messages may be signed or routed through a controlled broker.

„Trusted agent" is not a permanent property. Trust applies to a specific identity, version, task, source and authority. Change one condition and the assessment must be revisited.

Integration is the actual team performance

Several good partial results do not automatically form a good whole. They may use different definitions, dates and assumptions. Integration therefore checks semantics, not only file format. Are terms aligned? Are units consistent? Are source priorities compatible? Do recommendations conflict? Has one claim been counted twice?

A synthesis agent must not smooth over disagreement. It marks conflict, requests evidence or escalates. An artifact becomes valid project state only after integration passes. Previous versions and provenance remain available.

The key metric is not message volume but the proportion of correctly integrated, verifiable results. Cost, latency, human review effort, duplication and safe failure matter as well.

When one agent is better

Avoid multi-agent design when a task is short, unambiguous and solvable with one tool call; when output can be produced deterministically; when subtasks are tightly sequential; when roles have no real capability difference; or when the added risk cannot be observed and controlled.

Robust architecture grows incrementally. Build the simplest workflow first and measure bottlenecks. Split out a role only with a clear hypothesis: broader source coverage, independent verification, specialised tool access or genuine parallelism. The new system must outperform the simpler baseline, not merely look more sophisticated.

Worksheet: Design a verifiable agent team

Choose a complex but bounded task. Create a single-agent baseline, then a team design.

1. Draw the task graph with dependencies and independent subtasks.

2. Define each role's capability, tool, input, output, boundary and done criterion.

3. Create Task, Evidence and Decision Ledgers.

4. Design four message types: delegation, result, question and escalation.

5. Define shared and isolated context plus data-access rights.

6. Specify merge rules, conflict handling and human checkpoints.

7. Test an ordinary case, conflicting evidence, agent failure and manipulated message.

8. Compare team and baseline on quality, cost, time, duplication and review effort.

All materials to download — the topic overview and the worksheet:

Scope: A multi-agent system is not automatically more capable, safer or more independent than a single agent. Value depends on the task, decomposability, specialisation, communication cost, control architecture and evaluation. The patterns described here are architectural principles, not a universal performance guarantee.