Explainer

What is Multi-Agent AI

Multi-agent AI is more than one AI specialist handing work to each other — the way legal already reviews a go-to-market draft — with a shared job, a stop, and a person who must approve before a live system changes.

Multi-agent AI is more than one AI specialist handing work to each other, the way legal already reviews a go-to-market draft. They share a goal, pass intermediate work, and stop for a human when duties collide.

It is not “more than one model call.” If you can rename your agents to “saved prompts” and nothing breaks, you do not have multi-agent AI. You have prompt folders. Three chat tabs labelled Research, CRM, and Legal are still one person copying between windows.

Companies already hand work between departments. Multi-agent AI is useful when those hand-offs are the job. It is not useful as a prestige multiplier on a task one specialist should finish. Anthropic’s note on building effective agents is mostly about workflows and stops, not about collecting a zoo of bots.

Words you’ll hear

  • Single-agent. One policy, one tool set, one conversation. The human is the only coordinator. Right for many tasks: rewrite this email, explain this clause.
  • Multi-agent. Role specialisation, shared state scoped to the job, arbitration when agents disagree, and a stop — including “wait for approval.”
  • Orchestrator. A coordinator that assigns work to specialists. Not a licence to give every specialist the same production login.
  • Agent team. Nimbus’s product name for a department-shaped specialist group (finance, revenue, operations) that persists, rather than a zoo of user-owned bots.
  • Separation of duties. The specialist that recommends a CRM update is not the same principal that executes it without a quote.
  • Shared state. The job’s brief, wiki sections, and artefacts — not a pile of private chats. At work, this is the workstream.
  • Arbitration. What happens when specialists disagree. At work, legal’s “do not send” should beat go-to-market’s “looks fine,” and a named human still releases.
  • Cast versus brain. Several agents is a cast. Model routing is which brain each step pays for.

Tools are hands. They are not roles. A common plug so AI apps can use the same tools is useful plumbing — see What is Model Context Protocol — and it is also how a “multi-agent” demo quietly becomes one actor with every tool on the belt.

An agentic workflow is the sequence. Multi-agent AI is the cast. Mixing those words is how vendors sell extra model calls as organisation design.

Why you should care

Coordination is an org-chart problem, not a model problem.

It affects you if:

  • one “god agent” would need every production login
  • legal must review a draft before anyone writes CRM
  • next quarter, “why did we change this?” must still be answerable

Known failure modes:

  1. Parallel single-agent. Three chat tabs. No shared state. The user is the message bus.
  2. Agent sprawl. Dozens of custom agents with overlapping tools and unclear write rights.
  3. Orchestration without memory. A beautiful run that discards the outcome when the worker exits.

Multi-agent does not reduce accountability. It concentrates it on the release gate. See What is human-in-the-loop AI.

Do not think in “number of agents.” Think in jobs that already have hand-offs.

What changes by role

Finance. A finance-shaped agent team can draft a journal against the close checklist without inheriting GTM’s CRM write connector. Separation of duties is the point. Finance should still be the named signer on the ledger. Extra agents are not extra authorisation.

Legal. Review-before-send is a real hand-off. Legal-shaped specialists should not need People Ops files “for context.” Legal also cares that internal agent debate is not treated as a signature. The lifecycle graph should show the human at release.

Operations. Persist teams, do not spawn a bot per user. Ops should refuse sprawl, insist on shared workstream state, and keep fail-closed writes outside the cast. Incident reviews need one chain, not three private transcripts.

Go-to-market. Cross-functional launches already look like this: GTM drafts, legal redlines, finance checks the discount. Encode that. Do not encode a god agent that can do all three logins. Time-to-approved-write still beats number-of-agents as a metric.

Security. Sprawl is an identity problem. Each specialist with overlapping write tools is another path to production. Prompt injection that turns one specialist into a tool-caller should still die at the gate. Least privilege applies per role, not “the swarm is trusted.”

What people get wrong

Saved prompts as agents. If renaming them changes nothing, they were prompts.

Chat tabs as multi-agent. The user is still the bus.

More agents as more quality. Coordination cost is real. Start from existing hand-offs.

Agents as signers. Internal critics reduce garbage. They are not the named human.

Every specialist gets every tool. That recreates the god agent with extra steps.

Orchestration without a workstream. No scope, no budget, no memory.

Good looks like: department-shaped teams that persist, inherit workstream scope (wiki, connectors, NTU budget), disagree in the open, and stop for a named signer. Failure looks like a folder of user-owned bots and a demo where five helpers share one production key.

A useful test: draw the analogue hand-off first. If legal already reviews a go-to-market draft before a customer sees it, you have a candidate for two specialist roles on one workstream. If one analyst extracts a table, you have a candidate for a single tool-using agent. If nobody can name the hand-off, you are inventing a cast for a play that does not exist — and you will invent overlapping tools to keep them busy.

Spend follows the same test. Extra specialists mean extra model calls. Without routing and an NTU ceiling, “let them debate” is an unbounded loop. Debate that never reaches a named signer is also not human-in-the-loop; it is theatre with more speakers.

Memory is the other test. If the hand-off is not on the lifecycle graph, next quarter’s question — “why did we change this?” — has no answer except whoever still remembers the swarm. That is not multi-agent AI. That is parallel chat.

Agent teams in Nimbus are meant to look like the departments you already have, not like a prompt gallery. If your org chart does not contain a role, do not invent an agent for it. If your org chart does contain a role that must review before release, do not skip it because a single flagship model offered to “do it all.” Number of agents is a vanity metric. Named hand-offs are not.

How this shows up in Nimbus

Nimbus implements multi-agent AI as agent teams, not as a folder of user-owned bots. Teams persist. They inherit workstream scope — wiki sections, connectors, spend budget — and they participate in the same release process as any other actor.

Connectors stay read-only by default. Agent teams can draft. They cannot waive the gate. The Lifecycle Graph records the hand-offs as work, not as a swarm mystery.

See Agent teams. An agentic workflow is the sequence. Multi-agent AI is the cast. The OS around them is What is an enterprise AI operating system.

Questions people actually ask

Isn’t this just several ChatGPTs talking?

Not if they share one job, one scope, and one stop. Several chats with no shared state is still you, copying.

Do we need multi-agent AI for everything?

No. A single tool-using agent is enough for many tasks. Add specialists when duties already split in the organisation.

Does each agent need its own model?

Often yes for cost and quality. Classification rarely needs the flagship. Tricky policy interpretation often does. See What is model routing.

Who is accountable when several agents worked on it?

The named human at release — not “the swarm.” Internal critics can reduce garbage that reaches the person. They are not the signer.

How is this different from an agentic workflow?

The workflow is the sequence of steps and stops. Multi-agent is whether more than one specialist role executes those steps. You can have a workflow with one agent.

What is an agent team in Nimbus?

A department-shaped specialist group that persists and inherits the workstream’s wiki, connectors, and budget — not a user-owned custom GPT.

Can agents approve each other’s writes?

They can flag problems. Execution still needs a named signer and a fail-closed gate. See What is write-back governance.

Why not one god agent with every connector?

Because least privilege and separation of duties already exist in the company. Encoding the org chart is safer than encoding a superuser.

How do we avoid agent sprawl?

One team per function that already exists, assigned onto jobs, with overlapping tools treated as an incident. Do not let every operator publish a bot.

Does MCP make us multi-agent?

No. MCP is how a host calls tools. Many helpers on one belt can still be one actor. See What is Model Context Protocol.

How do disagreements get recorded?

On the decision chain: what was proposed, what was objected to, what the human signed. If disagreement evaporates with the session, you have orchestration without memory.

Will more agents stop hallucinations?

They can catch some errors the way a second reader can. They do not replace asserted wiki, citations, or a person on commitments. Air Canada-style fiction is a gate problem, not a cast-size problem.

What is an AI workstream and What is an enterprise AI operating system.

Sources

See what governed AI looks like on your stack.

Connect your tools, run a workstream, and keep every decision on your ledger - free for 7 days.