What are multi-agent systems and agent fleets?
By ContextClone, Systown AI LAB · Last updated
Key points
- A multi-agent system gives agents different roles: planner, worker, verifier or judge, and reconciler.
- An agent fleet is a team of agents managed as a unit: which models, how many, what budget, what each may see.
- A hybrid fleet mixes models: a few strong expensive ones for planning and merging, many small cheap ones for the wide work.
- A judge from a different model family than the workers is less likely to share their mistakes. This is a reasoned design choice, not yet a measured result.
- Seven orchestration patterns cover most use cases, from map-verify-reduce to tournament.
What is a multi-agent system?
A multi-agent system is software in which several AI agents work on one job. Each agent is a language model with instructions, some context and usually some tools. What makes it a system is the division of labour: agents have different roles, and the output of one becomes the input of another, or is merged with the others at the end.
The term is older than language models. It comes from a field of computer science that studied cooperating software agents long before today's AI. In current use it almost always means a team of language-model agents. An agent swarm is a multi-agent system with many parallel workers. An agent fleet is a multi-agent system seen from the operator's chair: a set of agents you staff, budget, monitor and swap, like a fleet of vehicles.
What roles do agents play in a team?
Most teams use some version of four roles. One model can play more than one, and a small team may fold two together.
| Role | What it does | What it needs |
|---|---|---|
| Planner | Reads the goal, decides whether and how to split it, and creates the tasks | Strong reasoning. Used sparingly, so an expensive model is affordable |
| Worker | Does one task with the context it was given and returns a result with its evidence | Speed and low cost. There are many of them |
| Verifier or judge | Checks a result before it is accepted: does the quoted passage exist, does it support the claim? | Independence from the worker, and a clear yes or no |
| Reconciler | Merges accepted results into one answer and keeps disagreements visible | Strong reasoning over a compact set of checked results |
The verifier is the role most often left out, and the one whose absence does the most damage. A controlled study of agent architectures found that designs lacking centralized verification propagate errors more readily [1]. A separate study of more than 1,600 annotated traces lists verification as one of three groups of failure, next to system design and misalignment between agents [2].
What is a hybrid agent fleet?
A hybrid fleet mixes models instead of using one model for every role. The mix runs along several lines: large and small models, open-weight and closed models, different vendors, and in time different kinds of model.
The reasoning is economic. Roles need different things. Planning and reconciling need the strongest reasoning but happen only a few times per job. The wide floor of worker tasks happens hundreds of times, and each task is small when the worker receives only the context it needs. Capable models differ widely in list price, so using the expensive model only where it matters is where much of the saving comes from.
Single-family or mixed-family: which is better?
A single-family team uses models from one vendor's family for every role. It is the simplest to set up: one account, one API, one set of behaviours to learn. The published multi-agent research system from Anthropic is of this kind, with a larger model leading and smaller models of the same family as workers [3].
A mixed-family team draws roles from different families. The case for it is a hypothesis with two parts. First, different families tend to fail differently, so a judge from another family may catch an error that a sibling model would repeat. Second, mixing lets each role run on the cheapest model that can do it, and avoids depending on one vendor's prices and availability.
The costs are real too: more accounts and keys, models that format output differently, and behaviour that is harder to predict. Neither claim for mixed-family teams is established by the research cited here. They are reasons to test, not findings. The honest position is to run both arms on the same task and compare.
What are the common orchestration patterns?
An orchestration pattern is the shape of the collaboration: who talks to whom, in what order, and who decides. The seven below are the ones used in the ContextClone template library, where each of the 120 templates names its pattern. The patterns themselves are general and can be built with any framework.
| Pattern | How it works | Typical use |
|---|---|---|
| Map, verify, reduce | Split a wide pile into units, give each worker only its unit, check every claim, merge what holds | Extracting terms from hundreds of contracts |
| Cross-examination | Two different model families answer the same question independently; a judge from a third settles disagreements or keeps them open | High-stakes reading where one opinion is not enough |
| Hierarchical decomposition | A planner breaks a large goal into a tree of sub-goals; leaves run in parallel; each level is verified before it rolls up | Audit plans, migration impact maps |
| Specialist panel | Several reviewers with different briefs (legal, financial, technical, safety) read the same scoped material and report against their own checklist | Design reviews, vendor assurance |
| Adversarial review | One team builds the case, another tries to break it; only claims that survive are kept | Stress-testing a forecast or a threat model |
| Watchtower | Many sources are re-checked on a schedule; when one changes, only the work that depended on it is redone | Regulation, sanctions and supplier risk monitoring |
| Tournament | Many candidates are produced cheaply in parallel, then scored and narrowed in rounds by independent judges | Drafting clauses, test cases or copy variants |
One of these, sampling many answers and choosing among them, has direct research support: a study of sampling and voting found gains that depend on how hard the task is [4]. That is a narrow result about answer selection, not proof that every pattern pays for itself.
How would you staff a fleet for a real job?
A company must review the security documents of 60 vendors against its own policy: certificates, questionnaires and audit reports, several per vendor.
The pattern is a specialist panel inside a map, verify, reduce. One planner, on a strong model, creates a task per vendor and per brief. Three kinds of worker, on small models, read the same vendor pack with different checklists: data protection, access control, business continuity. Each returns findings with the quoted passage.
A judge from a different model family checks each finding: does the passage say what the worker claims? Findings that fail are retried or dropped, never quietly kept. One reconciler, on a strong model, builds the vendor-by-vendor report and lists where reviewers disagreed.
The fleet is two strong models used a handful of times, many small workers, and an independent judge. A person still owns the decision to approve or reject each vendor. This is the shape of the vendor assurance panel template.
What tools exist for building multi-agent systems?
Several open frameworks help developers build agent teams. Described by their own documentation: LangGraph offers stateful workflow and agent orchestration with persistence and human intervention [5]; AutoGen AgentChat offers agent teams, shared-context coordination and graph workflows [6]; CrewAI runs tasks through crews of coordinated agents [7]; and the OpenAI Agents SDK provides code-owned agent loops, tools and tracing [8].
These are building kits, not benchmarks. None of their overviews sets out a built-in protocol for comparing a team against a single agent under one budget, so that experiment is left to the builder. That is a statement about what the inspected overviews establish, not a claim that the capability is absent.
When is a multi-agent system the wrong approach?
Roles and fleets add moving parts. They are the wrong approach when the job is narrow, when the steps must happen one after another, or when the job is so small that planning and merging cost more than the work itself.
A mixed-family fleet is the wrong approach when your organization is only permitted to use one vendor, when you cannot manage several sets of keys safely, or when you have no way to measure whether the mix helps. In those cases a single-family team, or one strong agent, is the better start. The single agent versus multi-agent checklist helps decide.
About ContextClone
Everything above this box is vendor-neutral. This section describes our own product, including what is not built yet.
How does ContextClone handle fleets and roles?
ContextClone is built to orchestrate beyond any single model family. Models are reached through OpenRouter or an OpenAI-compatible endpoint and are chosen by role: a strong model for planning and reconciling, small fast models for workers, and a decision model as the judge.
- Roles with boundaries. Each agent receives the minimum context its task is authorized to see. What was left out is recorded.
- An independent judge. After evidence checks, a decision model gives a typed yes or no, with a probability, on whether a claim is supported. It does not write text.
- One worker per task. Leases with fencing tokens make sure two workers cannot both commit the same task, and a worker that lost its lease cannot commit late.
- Patterns as templates. The template library holds 120 use cases in 20 categories. Each names its pattern, the fleet it is designed for, what to measure, where a swarm is the wrong tool, and an honest readiness level.
Agent counts in the templates are what each pattern is designed for, not what runs today. Whether a mixed-family fleet beats a single-family one is a hypothesis the first live benchmarks are meant to test.
What exists today. The full loop (ask, plan, distribute, work, verify, answer with proof) runs end to end in the cloud on a simulator, with sign-in, workspaces and tenant isolation. The engine runs up to four agents. Mixed providers are configured through OpenRouter, but no paid model call has been made, so there are no results from real models, and none are claimed here. A library of 120 use-case templates, each with a decision tree and a "not for" line, is published. An open-source release is planned.
What is planned. Live benchmarks against a single-agent baseline, including the cases where the team loses; scale beyond four agents; on-premise and your own hardware through any OpenAI-compatible endpoint; and physical AI models for sites, machines and video. These are plans, not features.
Frequently asked questions
What is a multi-agent system in AI?
A multi-agent system is software in which several AI agents work together on one job. Each agent is a language model with its own instructions, context and tools. Typically a planner splits the work, workers handle the parts in parallel, a verifier checks the results, and a reconciler merges them into a single answer.
What is an agent fleet?
An agent fleet is a team of AI agents managed as a unit, the way a company manages a fleet of vehicles. The operator decides which models fill which roles, how many agents run, what each may see and how much the run may spend. The term stresses operation and control more than the agents themselves.
What does the planner do in a multi-agent system?
The planner reads the goal and decides how to split it into tasks, which tasks depend on each other, and what each worker needs to know. A good planner also decides when not to split: if the job is narrow, handing it to one agent is cheaper. Planning usually runs on a strong model because it happens only a few times.
Why use a judge from a different model family?
Models from the same family are trained in similar ways and tend to make similar mistakes. A judge from another family is less likely to repeat the worker's error, so it has a better chance of catching it. This is a reasoned design choice and a hypothesis under test, not a result established by published measurements.
What is the difference between orchestration and a workflow?
A workflow is a fixed map of steps written by a person. Orchestration is the broader job of coordinating agents at run time: assigning tasks, passing context, handling failures, enforcing budgets and merging results. An orchestrator may follow a fixed workflow, or it may let a planner model decide the steps for each job.
Related guides and links
- What is an agent swarm?A definition, how a swarm differs from one model with tools, from a workflow and from a chain, and when it is the right or the wrong shape.
- How do you make agent swarms reliable?Seven practices anyone can apply, from scoped context to measuring against a single-agent baseline, and how ContextClone implements them.
- What are the challenges of multi-agent AI?Ten real failure modes, each with a plain example: duplicated context, error propagation, coordination overhead, unverifiable output, runaway spend and more.
- Agent swarm and agentic AI glossaryShort, neutral definitions of 58 terms, each with its own link: agent, agentic, swarm, fleet, judge, lease, fencing token, receipt, replay, BYOK and more.
Templates and tools
- Template: vendor assurance panelSpecialist panel, as in the worked example.
- Template: change-of-control cross-examinationTwo families answer, a third judges.
- Template: fallback clause tournamentMany candidates, narrowed in rounds.
- Template: sanctions and ownership watchWatchtower pattern on changing sources.
- Template library120 use cases, each with its pattern, fleet design and a "not for" line.
- Use casesWhere wide, checkable work shows up in practice.
- DocsQuickstart and methodology.
- ROI calculatorArithmetic on your own numbers, not a measurement.
Sources
Findings are attributed to their authors. None is a ContextClone measurement unless it says so. Points without a citation are reasoning or common practice, not findings.
- Kim et al.. Scaling agent systems study (arXiv 2512.08296, version 3). Version dated . Accessed .What it does not show: Does not establish a universal gain, an optimal number of agents, or an equal-dollar advantage with current models.
- Cemri et al.. The MAST study of multi-agent system failures (arXiv 2503.13657, version 3). Accessed .What it does not show: Does not establish a population-wide failure rate, causal proof that a particular fix works, or the performance of current models.
- Anthropic. Multi-agent research system (engineering report). Accessed .What it does not show: An internal evaluation. The token multiple is measured against chat, not against a strong single agent, so it does not prove a budget-matched advantage.
- arXiv paper. More Agents Is All You Need (the Agent Forest method, arXiv 2402.05120). Accessed .What it does not show: Sampling and voting is not collaboration, and no equal-dollar advantage follows from the abstract alone.
- LangChain. LangGraph overview (official documentation). Accessed .
- Microsoft. AutoGen AgentChat user guide (official documentation). Accessed .
- CrewAI. Crews (official documentation). Accessed .
- OpenAI. Agents SDK overview (official documentation). Accessed .