Multi-agent systems: roles, handoffs and verification
A multi-agent system coordinates several agents that have distinct tasks, contexts or tools. Its design must specify how work is delegated, how results are passed back and how a final outcome is verified. More agents create additional coordination paths, so their value must be tested against the task's requirements.
Use this guide when a task has parts that can be investigated or checked independently. Our example divides a study-route draft into catalogue lookup, plan preparation and review. These are teaching roles, not claims that every application needs three agents.
Key ideas
- Define a role by its input and output, not a personality.
- A handoff needs evidence and status as well as text.
- Independent review must be able to reject a result.
- Compare coordination costs with a simpler implementation.
When independent work helps
Several agents may help investigate separate questions or check a draft against evidence. The important property is that each subtask can produce a useful, verifiable result without requiring the full evolving state of every other subtask. For our learning example, catalogue lookup can return a lesson identifier and prerequisites. A reviewer can then check whether the proposed plan uses that record correctly. Start with a single-system baseline so you can tell which part the separation actually improves.
Specify roles as contracts
Give the researcher a subject and approved catalogue, the planner a verified record and learner goal, and the reviewer the draft plus acceptance criteria. Each role returns an explicit status and the information the next role needs. A role called 'expert' gains no verified expertise from the label. Write down its permitted tools and require the same evidence standards you would apply to one agent. Clear contracts make it easier to locate a disagreement or missing input.
Make a handoff inspectable
A useful handoff contains the task identifier, source identifiers, result, unresolved questions and completion status. A summary saying 'everything is correct' does not provide enough evidence for another component to verify it. Pass only the relevant material and preserve access boundaries. When a lookup is empty, hand over the empty result as such. Let the planner pause or revise its proposal rather than converting the gap into an invented prerequisite or lesson.
Choose who can change the shared plan
A coordinator can assign tasks and combine results, but it needs a rule for conflicts. Two researchers may return different lesson versions. Compare record identifiers and update dates before merging their conclusions. Avoid several roles overwriting the same working plan without ownership. A stateful runtime can organise handoffs, yet the acceptance rule remains your design responsibility. Define what happens when one role times out, another is awaiting review and a third has already completed its part.
Evaluate the whole system
Test the final outcome, not only the quality of each role's message. Record the number of calls, elapsed time, unresolved handoffs and whether the result meets the original task. These are quantities to measure in your project, rather than published promises of improvement. Add a disagreement case and a missing-source case to the teaching exercise. If a smaller design handles them clearly, several roles may be unnecessary. If separation helps, keep the evidence that explains why.
In everyday language
Imagine preparing a school exhibition. One person collects material, another arranges it and another checks the labels. Their jobs are useful when handoffs include the source material and the checker can ask for corrections. Three confident messages alone do not make the exhibition accurate.
Try it yourself
Create three role cards for the catalogue example. Give each a permitted input, output format and failure status. Introduce two conflicting lesson records and write the rule the coordinator should use to resolve the disagreement.
Expected result
A small delegation design with explicit ownership, traceable evidence and a route for unresolved disagreement.
Check your answer: Can the reviewer verify a claim without seeing its evidence?
It can comment on the text, but it cannot reliably confirm the underlying claim. Include the relevant source record and acceptance check.
Questions
Are several agents always better than one?
No. They can divide independent work, but also introduce handoffs, duplicate searches and disagreement. Compare both designs on the same cases, including failures. Keep the multi-agent design when its measured benefits matter for the task and its coordination remains understandable.
Should every role have the same access?
Access should follow the role's work. A reviewer of a catalogue-based draft may need only the relevant records and the draft, while a researcher needs a lookup tool. Giving every role every tool makes responsibilities harder to inspect and can widen the consequences of a mistaken action.
Define the handoffs before multiplying roles. Judge the combined system by its checked outcome and the coordination it requires.
Sources and further reading
- Anthropic — How we built our multi-agent research system ↗Sources checked:
- Anthropic — Effective context engineering for AI agents ↗Sources checked:
- LangChain — LangGraph overview ↗Sources checked: