Multi-agent systems - when they are worth it

A multi-agent system is a set of collaborating AI agents that independently pursue assigned goals and pass results to one another. Not every chain of model calls is multi-agent: when all steps and transitions are set in advance, it is more accurately a workflow. Split work only when measurement demonstrates an advantage over a simpler solution.

This distinction is practical. Anthropic describes workflows as predefined paths and agents as systems in which a model dynamically directs the process and tool use. It also recommends starting with the simplest solution and adding complexity only after assessing results. Source: Building effective agents — Anthropic.

We write from direct experience: our own work uses several parallel agents to distil material, an independent-draft panel with a deciding judge, and adversarial review. It is a working system, not a slide — described in our laboratory.

When one agent stops being enough

Check four signals in the evaluation of one agent:

1. The task has stages of different character. Gathering data, analysis, editing, and verification can require different instructions, tools, and quality criteria.
2. The instruction is difficult to maintain. When rules for many cases begin to conflict, dividing responsibilities can make testing simpler.
3. Independent control is needed. A separate verifier can catch errors if it has measurable criteria and does not judge only another model’s opinion.
4. The result is unstable. The same case is handled well once and poorly another time, with no understandable reason.

Four orchestration patterns

1. Chain (sequence)

Component A completes a step and passes its result to B. This is usually a workflow, not a multi-agent system. It fits a fixed order: extract data, verify format, enter the result.

2. Role division with a coordinator

A coordinator assigns work to specialists and combines the outcome. This works when needed subtasks cannot be predicted in advance. Roles need clear boundaries, handover format, and a completion criterion; partial overlap can be deliberate when it provides independent comparison.

3. Parallel work with adjudication

Several agents perform the same task independently, while another role compares, chooses, or merges the results. It increases calls but can expose divergence where there is a good decision criterion. Agreement among models does not prove correctness, so evaluate the outcome on reference cases. We used this pattern when planning this website.

4. Executor-verifier loop

One agent performs the task and another checks it against criteria, returning it for correction. The loop fits when the verifier can identify a specific error and an attempt limit prevents unproductive cycling. It is especially useful where a clear test exists, such as schema validation or running tests. We discuss it further in AI hallucinations.

What you actually pay for

• More model calls. Four roles mean at least several operations, though cost need not grow linearly: roles can use different models and context lengths.
• Orchestration work. Handoffs, handling a role that fails to return a result, and time and cost limits.
• Harder diagnosis. When output is wrong, you must find which role failed. Without input, output, and handoff logs, diagnosis is severely limited.
• Loop risk. Two roles can keep returning a task until the budget is exhausted. Set attempt, time, and cost limits plus a safe stopping condition.

Our August 2026 ranges are 15,000–40,000 PLN net for a pilot on one process, 40,000–150,000 PLN net for a production system with integrations, and 3,000–8,000 PLN net/month for maintenance and evaluation.

When it is overkill

• When the process has one well-defined step. First test email classification as one task; extra roles are justified only if they improve a measured result.
• When steps are known and fixed. That is automation, perhaps with one model call: cheaper and more predictable.
• When you have no quality-evaluation set. Without measurement, you cannot tell whether a third role helped; you pay for a feeling.
• When nobody maintains the first agent. More roles add handoffs, alerts, and diagnosis cases, so assign an owner and response process first.

Practical rule: start with one agent and add roles where measurement shows a weakness. Systems designed “just in case” are more expensive and harder to repair than those that grow from a real problem.

How we implement it

1. Map the process into roles. Decide what is a separate stage and what only appears to be one.
2. Design orchestration. Define order, handoffs, checkpoints, and limits.
3. Implement logging at every stage. Without it, there is no diagnosis.
4. Add verification loops where stakes are high.
5. Evaluate on a real-case set after every change.
6. Deploy with monitoring and a hard cost limit.

Moving from demonstration to production is a separate stage. It needs cost and time limits, error handling, permission control, monitoring, and a manual takeover procedure. Without those safeguards, even a promising prototype is not ready for a real process.

Frequently asked questions

Must every agent use the same model?

No. A routine role can use a cheaper model and a role needing complex reasoning a stronger one. Confirm the choice by evaluation, because a cheaper model may increase corrections or errors — see what an LLM is for criteria.

How many roles make sense?

As many as tests justify. There is no universal good number. Each additional role should improve a concrete metric on a reference set enough to justify its cost and harder maintenance.

Is a human needed?

In high-stakes processes, a person should approve consequential actions or cases outside tested scope. The boundary depends on reversibility, legal requirements, measured quality, and the ability to stop safely.

---

We build multi-agent systems for ourselves every day, so we can show a working example rather than a concept. See multi-agent systems and our AI research workflow, or describe a process that needs several stages.