Multi-agent AI explained — what it actually is, and when it's useful

What “multi-agent” actually means

An AI agent is a software process that takes a goal, calls an LLM to plan, calls tools (file system, web, browser, shell) to act, and loops until the goal is met or it gives up. A multi-agent system is the same idea with more than one of these processes — usually because each one is specialised for a sub-task, and a coordinator routes work between them.

That's it. There's no magic. The agents don't have feelings, they don't “negotiate,” they don't form a society. What they do have is well-scoped roles, separate context windows, and different tool permissions. That separation is what makes the multi-agent framing useful, not the anthropomorphism.

Why bother with multiple agents at all?

Three concrete reasons people split work across agents instead of stuffing everything into one prompt:

• Context-window economy. Big agentic loops blow past context limits fast. Splitting work into a Planner agent (small, focused on decomposition) and a Coder agent (large context, focused on edits) keeps the right information close to the right model.
• Tool-permission separation. The agent that plans probably shouldn't have shell.exec. The agent that executes probably shouldn't be able to edit the plan mid-run. Per-agent tool grants are a security control, not an aesthetic.
• Different models for different jobs. A small local LLM is plenty for “decompose this task into 5 steps.” A 70B-parameter model is overkill for that and is the right call for the Coder. Routing makes the cost / latency math work.

The four agents in MultiAgentOS

MultiAgentOS ships with four built-in agents. They aren't sacred — you can add more or replace them — but they cover the dominant patterns:

• Planner — Decomposes a request into ordered steps, assigns each step to the right agent, decides what context each step needs. Tool families: llm.*, file.*, git.*.
• Coder — Reads files, writes code, runs tests, applies patches. Tool families: file.*, shell.*, git.*, python.exec, data.*.
• Reviewer — Reads diffs, surfaces concrete file:line findings (style, logic, safety), and decides “ship” or “send back to Coder.” Tool families: git.*, file.*, shell.*.
• Operator — Drives browser and desktop. Searches the web, opens apps, fills forms, takes screenshots. Tool families: browser.*, desktop.*, native.*, shell.*.

When multi-agent wins

Multi-agent setups beat single-prompt approaches when the task has three properties:

1. Multiple distinct sub-tasks with different optimal models, tool permissions, or context. (“Build a feature” → plan, code, test, review.)
2. A natural verification step that benefits from a fresh pair of eyes. (Reviewer agents catch bugs the Coder tunnel-visioned past — same model, different prompt, different context.)
3. Long-horizon work where keeping every step in a single context wastes tokens or causes drift.

When a single agent is the smarter choice

Multi-agent isn't free. You pay in latency (more round trips), tokens (more system prompts and handoff context), and complexity (more places for the orchestrator to fail). For the following shapes of task, a single LLM call usually wins:

• One-shot generations — “write a function that…,” “summarise this PDF,” “translate this string.” No verification needed.
• Pure conversation — chatting through an idea, asking for explanations, brainstorming. Adding agents adds friction.
• Tasks that fit comfortably in one context. If the whole problem (input + reference material + output) is under ~32K tokens, you're paying complexity for nothing.

The orchestration tax

The dirty secret of multi-agent systems is that orchestration is the hard part. Picking who handles what, deciding when to hand off, formatting context so the next agent doesn't lose the thread, handling failures — that's where most of the engineering goes. That's why frameworks (AutoGen, CrewAI, etc.) exist, and why MultiAgentOS bakes it into the runtime instead of asking each user to glue it together.

The bottom line

Multi-agent AI isn't a paradigm shift; it's a software-engineering pattern for cases where the work doesn't fit in one prompt. Use it when you have heterogenous sub-tasks, a real verification step, or long-horizon work. Don't use it when a single prompt would do. Either way, the model is the easy part — the orchestration is the craft.