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.