What Is a Multi-Agent System, in Plain Terms

Why this matters

• Understand what is being charged for when a quote lists "several agents" instead of one
• See which tasks get faster when roles are split, and which only get more expensive
• Ask the vendor for the role map and the control points before work begins

What a multi-agent system is, in plain terms

A restaurant kitchen works much the same way. One order comes in, but there are several stations: cold prep, grill, sauces. The chef hands out the assignments and plates the dish. Nobody cooks the whole thing alone.

A multi-agent system is built on the same principle. The task is broken into segments and handed to separate AI agents. Each has its own instructions, its own data access, and its own set of tools.

A coordinator assembles the result. It assigns subtasks, receives the answers, and decides what is still missing. That role is called an orchestrator, and the order in which work is passed along is called orchestration.

How it works

1. Roles are mapped out before any code. Take the real process and mark its steps: what to find, what to extract, what to verify, what to record. A new role appears wherever the data source or the permission level changes.
2. Each role gets a short instruction. The verification agent has no idea how to search for documents. The search agent cannot write to the system of record. A narrow instruction leaves fewer openings for error.
3. Write permission goes to a single participant. The rest only read and propose. That way every change in the system of record passes through one point, and that point can be put behind manual approval.
4. Results are passed in explicit form. What moves between agents is not free text but filled-in fields: contract number, amount, date, link to the source. Those fields show exactly where the chain broke.
5. A cap is set on the number of rounds. Without a limit, agents drift into corresponding with each other and the bill grows with nothing to show for it. The cap is expressed as a number of calls per task.

Text volume needs watching too. Each agent maintains its own context, and a single task turns into several model calls. Splitting the roles saves people time and adds token costs.

An example from practice

A procurement department processes incoming vendor quotes. The work falls into four segments: find the email and its attachments, extract line items and prices, check the terms against the master agreement, and open a request in the system of record.

A single agent struggles with a chain like this: by the fourth step it confuses suppliers and pulls a price from the previous document. So the roles are separated. The extraction agent works only with attachments. The verification agent sees the contract and the discount rules but never sees the mailbox. One participant opens the request, and a buyer approves that action.

The effect is measured on a fixed sample of one month's emails. Three figures are tracked: the share of requests that went through without edits, the average time from email to request, and the number of model calls per email. The same three figures are measured before the rebuild — otherwise there is nothing to compare against. The first two are weighed against the price of the third: the number of calls goes up, and the higher bill has to be covered by the hours saved.

What this gives a business

• Errors become traceable. The step where the task broke down is visible, and one participant's instruction gets rewritten instead of the whole system. The fix takes hours, not weeks.
• Permissions are split by role. Writing to the system of record stays with one agent, and that write is put behind human approval. The other participants physically cannot change the data.
• Heavy processes are tackled piece by piece. A ten-step chain launches segment by segment: extraction goes live first, then verification is added. The first working version ships before the full process is ready.
• Costs are calculable in advance. The number of model calls per task follows from the role map, so the monthly bill can be estimated before launch — with a budget calculator or by hand from the provider's rates.

When this can be skipped

A short process gains nothing from splitting roles. Two or three steps against a single data source are handled by one agent, and every extra participant only stretches out the response.

The split is also unnecessary where the steps are strictly deterministic: moving fields from a form into a database is cheaper to handle with a plain integration. What is left to an agent is the segment where the text is unstructured and a judgment call is required. If tasks arrive rarely, manual handling stays cheaper than any architecture.

What to check

First: how many model calls one task consumes in the worst case. It is the worst case that sets the ceiling on both the bill and the response time. Ask the vendor for that number before signing the quote.

Second: where the human sits. In a chain of several agents, one participant's error propagates further down the line. The approval point belongs before any irreversible action — a write, a send, a payment.

Third: whether the work is being logged. A log is needed that shows, for each task, which agent received what and returned what. Without it, investigating a customer complaint turns into guesswork, and there is nothing to measure quality against.