Multi-agent system

A multi-agent system is a software system in which several AI agents, each with its own role, instructions and sometimes its own model or tools, work on parts of a task and pass results between them. In AI coding, the agents typically mirror a team: someone plans, someone builds, someone reviews, someone tests.

What it is

Each agent is usually a language model with a role-specific prompt. What makes it a system is the structure around them: who goes first, what each one sees, and how their outputs combine. Common shapes are a pipeline (each agent hands to the next), a review loop (one writes, another critiques), a debate (two propose, a third judges) and a fan-out (several look at the same thing from different angles, then a step merges them).

The orchestration layer decides that structure.

Why it matters

The main benefit for code is separation: the agent that checks a change isn't the one that wrote it, and each agent gets a narrow job with instructions tuned for it. That catches more than one model reviewing its own output. The costs are real too: more model calls, more tokens, and more places for a misunderstanding to propagate. Specialist agents help when the roles are genuinely different; they don't make a weak model strong.

In AI CodeOps

Every session runs a workflow: a fixed list of steps, each run by one agent. There are 16 built-in workflows and more than 20 built-in agents, from Architect and Builder to Security Auditor, Dependency Auditor and Site Reliability. Two examples:

Plan, Build, Review & Test (default)
  Plan (Architect) → Build (Builder) → Review (Reviewer) → Test (Tester)

Parallel Review
  Correctness review (Reviewer) → Security review (Security Auditor)
  → Test coverage review (Tester) → Merge findings (Architect)

Steps run one after another, and each sees what the earlier steps wrote, so a merge or synthesis step works from every review before it. Architecture Debate has two architects propose, a reviewer critique and the architect synthesise. Nothing is decided by vote.

The agents don't grade their own work at the end. After the change is written, your tests run in a sandbox, and a separate findings pass reads the actual diff with the review notes as context. Its findings are credited to the Security Auditor if that agent ran, otherwise to the Reviewer. Then a person approves or rejects.

The session page shows each step live, with its agent, status, and the tokens and cost so far.

Related terms

• Agent orchestration: how the steps are run, limited and checked.
• Human-in-the-loop: the person after the agents.
• Model Context Protocol (MCP): how agents reach outside tools.