Building Your First Multi-Agent System: A Practical Guide

Before you build: should this be multi agent at all?

A multi agent system splits one job across several AI agents, usually a coordinating agent (an orchestrator) and specialised agents (workers) that each handle part of the job. Anthropic's write up of its own research system describes exactly this orchestrator and worker pattern, and reports two facts worth keeping in view: the multi agent version performed much better on broad research questions, and it used roughly fifteen times the tokens of a chat interaction. Anthropic also notes the pattern suits work that splits into independent parallel strands and suits tightly interdependent work less well.

So the first rule is: build a multi agent system only when the job genuinely has parallel, separable parts and the value per task justifies higher cost. If a single well instructed agent or a fixed workflow can do it, stop there. Anthropic's broader guidance to builders is the same: find the simplest solution that works.

Good marketing candidates: researching many accounts or topics at once, producing several channel versions of one campaign, auditing many pages in parallel. Poor candidates: writing one email, answering one question, anything where each step depends tightly on the last.

The eight step build

Step 1: write the job as input, output and judge

One paragraph. What goes in, what comes out, who decides whether the output is good, and against what standard. Example: "Input: a company name and website. Output: a one page account brief with three talking points, each tied to a cited source. Judge: the sales lead, who marks each brief usable or not."

Step 2: build the single agent version first

Give one agent the whole job, with the tools it needs. Run it on ten real cases. This is your baseline, and it often turns out to be good enough.

Step 3: find where the single agent fails

Read the ten outputs. Typical failures are running out of context on long tasks, doing parts shallowly because it tries to do everything, or mixing up sources. Only failures that come from doing too many separable things at once are fixed by adding agents.

Step 4: split along independent parts

Split the job where parts do not depend on each other. In the account brief example, researching the company's news, its hiring and its website messaging are independent; each can be a worker. Synthesising them into talking points depends on all three, so it stays with the orchestrator.

Step 5: write a contract for every handoff

Most multi agent failures happen at handoffs: a worker returns something the orchestrator cannot use. Write each handoff down.

Handoff contract template

Field	What to specify	Example
Task	The one thing the worker does	Find news about the company from the last 90 days
Inputs	Exactly what it receives	Company name, website, country
Output format	Structure the orchestrator expects	Up to five items, each with date, headline, one line summary and source URL
Tools allowed	Minimum tools for this task	Web search only; no email, no CRM write
Stop condition	When it should stop and return	Five items found, or ten searches run
Failure return	What it returns when it cannot do the task	An empty list and a one line reason, never invented items

The failure return is the most important field. A worker told to always return five items will invent the fifth.

Step 6: limit permissions and add approvals

Give each agent only the tools its contract names. OWASP's security guidance on excessive agency recommends exactly this: the minimum tools, the minimum functions within each tool, and avoiding open ended tools. Any action that sends, publishes, spends or deletes should wait for a person. Several platforms support this directly; n8n's AI Agent node, for example, documents an option to require human approval before specific tools run.

Step 7: test against your real examples, every change

Keep the ten real cases (grow them to twenty or thirty) as a test set. After any change to prompts, tools or structure, rerun them and have the judge score the outputs. Without this, you will not know whether a change helped or broke something elsewhere.

Step 8: measure cost per task before scaling

Log model usage per run. Multiply by expected volume. Compare with the value of the task (time saved, or the value of a better outcome). Multi agent systems can become expensive quietly, because each worker makes several calls.

Worked build: an account brief system

Illustrative example for a hypothetical B2B firm that wants briefs on 50 target accounts a month.

• • Baseline: one agent with web search produced usable briefs for 6 of 10 test accounts. Failures: shallow research on larger companies and one invented news item.
• • Diagnosis: the agent tried to cover news, hiring and messaging in one pass and ran short of depth.
• • Split: an orchestrator plus three workers (news, hiring signals, website messaging), each with the contract above and web search only.
• • Guard: the orchestrator must cite a worker item for every talking point; items without a source URL are dropped.
• • Result on the same ten: say 9 of 10 usable. (All figures in this build are illustrative, not measured.)
• • Cost check: if the new version uses four times the model usage of the baseline, the team decides whether three extra usable briefs in ten justify it at 50 accounts a month.
• • Approval: briefs go to the sales lead; nothing is sent to prospects automatically.

Choosing where to build it

Code frameworks give full control but need a developer. Low code agent platforms such as Relevance AI let you build agents with tools and knowledge and combine them into teams, which Relevance calls workforces. Workflow tools such as n8n and Make now have agent steps inside workflows, which suits builds where most of the path is fixed. For a comparison of the two most common low code routes, see n8n vs Relevance AI.

AfM's published case records show the modest end of this: single agent steps inside fixed pipelines, such as the inbound lead enrichment system, work Jakub delivered in 2025 before founding AfM. For a content example with many agents, see multi agent systems for content marketing.

The mistakes that sink first builds

Starting with eight agents. Every agent adds handoffs, cost and failure points. Earn each one.

Agents with personalities instead of contracts. "You are a world class strategist" does less than a clear input, output and stop condition.

No test set. Without one, quality is a matter of opinion and changes cannot be judged.

Autonomy before track record. Keep a person approving outputs until the approval record shows the system is reliable, then relax approval one action at a time.

FAQ

Do I need to code to build a multi agent system?

Not necessarily. Low code platforms such as Relevance AI, n8n and Make let you build agents and connect them visually. You still need clear thinking about contracts, permissions and testing, which no platform does for you.

How many agents should a first system have?

As few as solve the failures you observed in the single agent version. For most first builds that is an orchestrator and two or three workers.

Which model should each agent use?

A capable model for the orchestrator, which plans and synthesises, and often a cheaper, faster model for narrow workers. Anthropic's own research system paired a larger lead model with smaller subagents. Test on your cases before deciding.

How do I stop agents inventing information?

Require a source for every factual item, give every worker an explicit failure return, and have the orchestrator drop anything unsourced. Then spot check outputs against sources regularly.