Multi-Agent Systems

A multi-agent system uses several agent roles to work on a shared objective. It is useful when work can be separated into meaningful investigations, permissions or contexts and then recombined reliably. It is a poor default when the agents need the same information, repeatedly wait for each other or merely rewrite one another's answers.

For an engineering lead, the design question is whether decomposition creates measurable value after coordination, extra model work and failure handling are included. This guide develops an illustrative tender-response preparation system. Specialist workers collect evidence and identify gaps; one coordinator assembles a review pack. Authorised staff retain responsibility for commitments and final submission.

Distinguish multiple agents from multiple model calls

A fixed pipeline that extracts requirements, checks a schema and formats a document can make several model calls without being a multi-agent system. The application defines the sequence. A multi-agent design assigns bounded goals to workers that may choose their own permitted steps before returning results.

That distinction matters because delegation introduces another contract. The coordinator must specify the worker's scope, provide sufficient context, limit authority and judge the returned evidence. Simply giving different prompts role names does not create useful specialisation or independent verification.

Anthropic's account of its research system describes parallel agents with separate contexts and coordination challenges. It supports considering decomposition for suitable work, not a universal performance claim for every business workflow. See the primary engineering account.

Decompose by outputs that can be checked

In the tender example, dividing work into “researcher”, “thinker” and “writer” is vague. A stronger division assigns concrete artifacts: a requirements-to-evidence map, a review of supported delivery assumptions and a register of missing or conflicting source material. Each output has a defined schema and acceptance criteria.

Keep the shared baseline explicit. All workers receive the same approved tender version and the same scope of response. Otherwise, one may assess an amended requirement while another uses an older document, creating disagreements that look like reasoning problems but are actually version mismatches.

Choose parallelism where dependencies allow it. Evidence mapping and source-quality review can sometimes proceed independently after the baseline is set. Drafting a final compliance statement depends on those findings. Starting it too early can create rework or encourage the coordinator to fill gaps before the evidence arrives.

Design a delegation contract

A worker assignment should state the objective, permitted inputs, permitted tools, expected output, exclusions, execution budget and stopping conditions. It should also explain how uncertainty is reported. The worker needs enough context to do its task, without receiving unrelated confidential material merely because the coordinator has access to it.

Illustrative contracts for tender-response preparation workers

Worker	Required artifact	Authority limit
Requirements mapper	Requirement identifier, proposed evidence reference and uncovered obligation	Cannot mark an unsupported claim as satisfied
Delivery assumption reviewer	Dependencies, proposed milestones and unresolved owner questions	Cannot promise dates or resource availability
Source quality reviewer	Version conflicts, withdrawn documents and unverifiable statements	Cannot replace approved sources with convenient public claims
Coordinator	Consolidated review pack with explicit conflicts and gaps	Cannot submit the tender or approve commitments

These are proposed responsibilities, not evidence that the workflow has been deployed or evaluated. A customer can choose a narrower division if a single agent or fixed workflow handles the task adequately.

Make the coordinator resolve evidence, not vote on prose

If workers disagree, the coordinator should inspect the underlying sources and the scope of each claim. A majority of generated answers is not authority. Workers may share the same model, source error or ambiguous instruction, so agreement alone is weak evidence of correctness.

For example, the requirements mapper may identify a document supporting a capability while the source reviewer finds that the document has been withdrawn. The correct consolidation preserves the requirement as unresolved and explains why the proposed evidence is unusable. It does not average the two opinions into “partially compliant” without a defined meaning.

Require source references to survive every handoff. A worker summary should include enough provenance for the coordinator and human reviewer to inspect consequential claims. If a summary loses the relevant qualification, ask for a narrower evidence extract rather than letting the final writer reconstruct it from memory.

Separate a factual conflict from a policy decision. Two sources may state different delivery conditions, requiring source-owner resolution. Or the evidence may be clear while the organisation must decide whether to accept an obligation. The coordinator can expose that decision but should not invent the organisation's commitment.

Use one owner for shared writes

Parallel research does not require parallel authority over the final artifact. A simple design gives workers separate output areas and lets the coordinator own the consolidated response. This reduces competing edits and makes the relationship between a worker result and a final statement easier to trace.

If workers must update shared state, define conflict rules, version checks and ownership by field or artifact. “Last write wins” may be unacceptable when a later summary silently overwrites a reviewed limitation. Concurrent work needs application-level consistency rules, not conversational instructions to cooperate.

External actions need an even clearer boundary. If several workers can create the same case or contact the same party, duplicate operations become possible. Prefer a single controlled execution path where practical. The orchestration guide explains how to coordinate durable actions and recovery.

Keep permissions narrower than the shared objective

A worker reviewing delivery assumptions may need approved resource information but not customer personal records. A source reviewer may need document metadata without permission to change the repository. Assign tools and data access according to each task rather than inheriting the coordinator's full capabilities by default.

Check whether a framework actually enforces the intended separation. Separate prompts or context windows are not equivalent to separate credentials or application permissions. The receiving tools must validate authority, including the relevant user and tenant scope.

Treat delegated results as information to validate. A worker can return mistaken content or instructions copied from an untrusted source. The coordinator should not execute a new action merely because a subagent recommends it. The guardrails guide addresses this boundary.

Set a budget for coordination and exploration

Define limits for worker creation, tool use, elapsed execution and repeated attempts. In an illustrative configuration, a coordinator receives 2 retrieval calls and each of 3 workers receives 4, giving 2 + 3 × 4 = 14 permitted retrieval calls. This is a design example, not a recommended universal budget or a measured performance result.

The budget should reflect the task's value and evidence needs. A worker that cannot complete within its allowance should return partial evidence and a clear reason, not silently spawn more work. The coordinator can then request an authorised extension or route the unresolved item to a person.

Parallel execution can reduce elapsed time for independent work, but shared rate limits, slow sources and coordination may reduce that advantage. Measure actual end-to-end latency, including consolidation and review. Do not estimate completion by dividing one agent's runtime by the number of workers.

Handle missing and stale worker results

A worker may fail, time out or return after the task has changed. Give every assignment a case identifier, version and status. The coordinator should reject results from an obsolete assignment when they no longer match the current baseline, while preserving an appropriate record for investigation.

Decide whether the final pack can be produced with a missing worker result. If it can, label the uncompleted check explicitly. If it cannot, stop at a clear incomplete state. A beautifully formatted answer should not conceal that an intended evidence review never occurred.

Cancellation must propagate to outstanding work where technically supported, and the system must still reconcile any actions already accepted elsewhere. Reassigning a failed worker should not create duplicate external side effects. Keep the retry policy separate from the model's decision to explore another source.

Evaluate whether the extra agents earn their place

Compare the proposed system with a strong single-agent or fixed-workflow baseline on the same cases. Measure supported requirement coverage, missed qualifications, false claims, conflict handling, reviewer effort, latency and resource use. More output is not necessarily better coverage.

Use fair budgets when investigating the reason for an improvement. If the multi-agent design receives much more model and tool work, the comparison should show that difference. It may still be worthwhile, but the evidence should not attribute every improvement to coordination alone.

Evaluate the final artifact and the handoffs. A correct worker finding that disappears during consolidation is an end-to-end failure. A coordinator that repeatedly asks workers to redo already completed work may have a delegation problem. The evaluation guide covers task-level and trajectory-level evidence.

When a single agent is the stronger design

Prefer a simpler design when the task is short, the evidence fits comfortably in one working context, the steps are tightly dependent or the main challenge is an unreliable source. Multiple agents do not make missing evidence available or resolve unclear authority.

Introduce another worker only for an identified benefit: independent investigation, context separation, specialist tools or genuine parallel work. Remove it if evaluation shows no meaningful improvement. The architecture guide helps place delegation within the wider system, while planning and reasoning covers how each worker chooses steps.

Open for AI can scope single-agent or multi-agent development according to the task. To assess whether your workflow benefits from several agents, bring the proposed work packages, their dependencies and an example of a conflict that consolidation must preserve. Those details reveal whether delegation adds substance.