What is a multi-agent system?
A multi-agent system is a set of specialised AI agents that divide one piece of work between them and coordinate until it is done. Each agent owns a narrow responsibility, carries its own instructions and its own tools, and passes work on through a defined handoff. A multi-agent system is a design decision about division of labour, not a bigger model.
In a support build that looks concrete: a triage agent reads the incoming message and decides what kind of request it is, a lookup agent pulls the customer record and open orders, a drafting agent writes the reply, and a reviewer holds anything that touches money or personal data until a person approves it. A coordinator decides what runs next. We build systems like this in Cape Town on n8n, OpenAI, Anthropic Claude and the CRM a business already runs. The pattern is closely related to a multi-agent AI team, and it sits inside the wider practice of agentic AI.
When does one agent beat a multi-agent system?
One good agent beats five whenever the work is a single shape. If the task is answer this question from these documents, or read this form and write it into the CRM, splitting it across agents adds handoffs, latency and new places to fail without adding any capability. Every agent boundary is a message that can be dropped, delayed or misread.
Split only when the responsibilities genuinely differ. Different tools is a real reason: an agent that queries a ledger and an agent that writes customer copy need different access and different guardrails. Different risk is a real reason: a step that can send money should not share a scope with a step that summarises an email. A step that a human must sign off separately is a real reason. Wanting the diagram to look sophisticated is not. We start most builds as one agent, run it against real traffic, and split only where a structural limit actually shows up.
How do agents divide responsibility and hand off work?
Agents divide responsibility the way a team does: by what each one is accountable for and what it is allowed to touch. Every agent gets a written scope, a fixed set of tools, and permission to read or write specific systems and nothing else. An agent that cannot reach a system cannot break it.
Handoffs are structured rather than conversational. One agent passes a defined object carrying the fields the next agent needs plus a status, so the receiver never has to interpret prose to work out what happened. An orchestrator holds the run, decides which agent fires next, retries a failed step, and escalates to a person when the system runs out of confident options. That coordinating layer is the same job an AI workflow orchestration agent does across a business process. The agents themselves stay dumb about the wider plan on purpose, because an agent that tries to manage the whole run is an agent that will invent one.
What are the failure modes of a multi-agent system?
The failure modes live at the joins, not inside the agents. Agents call each other in a loop and burn an entire run without producing anything. Context is passed forward without the qualifier that made it true, so a guess from step two hardens into a stated fact by step five. Two agents write to the same record and the last one wins.
Errors are the quiet one. A tool times out four steps deep and the final answer comes back plausible, complete and wrong, because each agent did its best with what it was handed. We design against all of this directly: run budgets and loop limits, idempotent writes so a retry cannot double-book or double-send, structured handoffs that carry confidence and provenance, per-agent logs that let a run be reconstructed step by step, and a human approval gate on anything that spends money or leaves the business. Reliability here is engineering, not prompting.
How is shared context handled, and is it POPIA compliant?
Shared context is the state every agent reads from and writes to: the customer record, the documents in scope, what has already been decided, and what is still open. We keep it in one place, usually Supabase or PostgreSQL sitting alongside the CRM, so no agent carries a private copy that quietly drifts from everyone else's. One source of truth, many readers.
POPIA shapes what goes into that store and who can see it. Each agent is scoped to the fields its job actually needs, so a drafting agent does not hold identity numbers it never uses. Sensitive values are passed by reference where the work allows it. Retention windows delete state on time, access is controlled per agent and per person, and every read, write and handoff is logged so an audit can reconstruct exactly what a run saw and did. Data is encrypted in transit and at rest, and webhooks are signed.
How does a team start building a multi-agent system?
Start from the work, not the architecture. Map the process end to end and mark every point where it changes shape: a different system is touched, a different skill is needed, or a different person signs off. Those marks are the candidate agent boundaries, and most processes have fewer of them than the first whiteboard suggests.
Then build the single agent version and run it on real traffic. Where it fails for a structural reason rather than a wording one, split at that seam and give the new agent a scope, its own tools and a handoff contract. Guardrails and approval steps go in before volume does. Pilots run two to four weeks on the client's own systems, and the client owns the workflows, prompts and data at the end. We have built this way for 35+ companies across South Africa over 3+ years, including teams already running AI agents in South Africa that outgrew a single assistant.
Related capabilities. The same parts, your business.
Keep reading. Pages close to this one.
Tell us what the work looks like. We will tell you how many agents it needs.
Send one message describing the process and where it currently stalls. We reply with an honest read on whether this is a multi-agent system or one well scoped agent, and what building it would take.