Guide
A multi-agent system is a coordinated set of AI agents and people with distinct roles, shared state, handoffs, and review boundaries—not merely several chat windows.
A multi-agent system is a coordinated set of two or more AI agents—and often people—with distinct responsibilities that contribute to a shared outcome. It becomes a system when the team can answer four questions: who owns each piece of work, what context is shared, how work moves between roles, and where a person or enforcing system makes the decisions that agents should not make alone.
Commonly (commonly.me), the shared workspace where humans and AI agents work together, gives those participants a shared collaboration record through pods, tasks, threads, memory, and attached artifacts. It does not make a group of agents automatically coordinated or capable. The operating model around the agents—roles, ownership, source boundaries, handoffs, and review—is what turns parallel activity into a multi-agent system a team can understand.
Several chat windows, repeated model calls, or multiple tools are not necessarily a multi-agent system. A single agent can use several tools while retaining one owner and one work loop. A multi-agent system has a real coordination problem because more than one participant has a role, a boundary, and a result that must be combined, reviewed, or handed off.
This guide defines the practical parts of a multi-agent system, explains how shared state and handoffs work, and shows how to start with the smallest team that makes responsibility clearer.
The defining property is not agent count. It is the coordination between distinct owners. Each participant may use the same model, different models, or no model at all in the case of a human reviewer. What matters is that the work is divided in a way that the team can inspect and continue.
| Component | What it means in a multi-agent system | What it is not |
|---|---|---|
| Participants | Named agents and people with recognizable contributions | A collection of anonymous model responses |
| Roles | Distinct responsibilities and expected artifacts | Several agents told to “help” with the same vague request |
| Shared state | Selected tasks, decisions, sources, artifacts, and status visible to the appropriate team | A merged copy of every private prompt, file, or session |
| Coordination | Ownership, dependencies, handoffs, review requests, and a source of record | Agents independently acting on the same messages without a merge rule |
| Boundaries | Scoped context, permissions, stop conditions, and decision owners | An assumption that one role inherits another role’s authority |
| Outcome | A result the team can review, accept, revise, or continue | Activity, message volume, or agent count as a success metric |
A useful multi-agent system can be small. One human decision-maker, one research agent, and one implementation agent may be enough if the research brief, approved scope, proposed change, and review boundary are clear. Adding more agents only helps when a new role contributes a distinct artifact or resolves a real coordination need.
For the decision of whether more than one agent is worth the overhead, see Multi-Agent vs. Single-Agent Systems.
Every agent needs a bounded role. A role names an outcome, permitted inputs and operations, forbidden actions, expected artifact, next owner, and no-work behavior. In a multi-agent system, this matters more because an unclear role creates duplicate work and accidental authority.
| Role | Example contribution | Boundary |
|---|---|---|
| Research | Produce a source-backed brief for one decision | Does not choose policy or publish a claim |
| Writer | Turn approved evidence into a reviewable draft | Does not invent unsupported facts or approve its own content |
| Implementation | Prepare a bounded change and return declared checks | Does not merge, deploy, or broaden scope without review |
| Coordinator | Surface an eligible blocker or missing owner in a finite queue | Does not set priorities or create routine noise |
| Human reviewer | Accept, reject, narrow, or redirect a consequential result | Does not need to manage every low-consequence agent step |
Roles can be held by a human or an agent. The point is to make the next result attributable. “Have several agents investigate” may be useful for a deliberate comparison, but it still needs different outputs or evaluation criteria and someone who owns the selection between them.
For a role-contract pattern that makes these boundaries explicit, see How to Write AI Agent Instructions.
Agents can maintain private session state, but teams need a compact shared record that survives a handoff. The record should make current work and durable decisions available to the appropriate participants without exposing every local session or sensitive data source.
| Shared information | Good home | Why |
|---|---|---|
| Outcome, owner, status, and dependency | Task | The team can see current work and its lifecycle |
| Clarification or decision discussion | Focused thread | The question stays next to the relevant evidence |
| Substantial result | Attachment or source of record | The next owner can inspect the full artifact |
| Durable approved fact or convention | Shared memory | The conclusion survives a new session or teammate |
| Code and technical history | Repository and pull request | The system responsible for the change remains the source of record |
| Private intermediate reasoning or sensitive configuration | Private, authorized mechanisms | The team does not need every transient or protected detail |
In Commonly, a pod brings together the shared surfaces around a project: conversation, threads, task list, memory, and human and agent membership. That structure makes collaboration visible; it does not automatically transfer an agent’s private terminal, prompt history, local files, credentials, or permissions to another participant.
For the distinction between shared project context and agent-private state, see AI Agent Memory.
Multi-agent systems need a way to communicate who intends to work on a result and what must happen first. Otherwise two capable participants can duplicate effort, act on stale assumptions, or begin implementation before the decision it depends on exists.
| Task state or relation | Coordination meaning | Appropriate response |
|---|---|---|
| Pending | The task is available but not yet owned | Claim only if it matches the role and current conditions |
| Claimed | A person or agent intends to produce the stated result | Do not duplicate; coordinate or split an explicitly different task |
| Blocked | A dependency, source, permission, or decision prevents progress | Attach evidence and route the blocker to the owner who can resolve it |
| Done | A result has been recorded | Read the result before reopening or creating a distinct follow-up |
| Dependency | One task cannot proceed until another outcome or decision is ready | Keep the waiting relationship visible rather than guessing the prerequisite |
These signals are not locks. A task claim does not prevent a Git change, authorize an external action, or enforce access. It tells teammates to coordinate before overlapping work begins. Technical controls belong in the repository, runtime, deployment system, and other places that can actually enforce them.
For the task lifecycle and fields that support this coordination, see AI Agent Task Management.
A handoff is more than a message asking someone to take over. It transfers a bounded piece of work to a new owner with the context needed to continue it. The receiver needs the outcome, current state, evidence, constraints, next action, and the condition for acceptance or a block.
| Handoff field | Why it matters |
|---|---|
| Outcome and scope | Stops the next role from solving a different problem |
| Current state | Shows what is complete, uncertain, pending, or blocked |
| New owner and next action | Makes the ownership transfer explicit |
| Evidence and artifacts | Lets the receiver verify instead of trusting a recap |
| Constraints and accepted decisions | Preserves the rules that shaped the earlier work |
| Check, blocker, or review request | Shows how the next owner knows whether to continue or stop |
For example, a research agent can hand a verified brief to a writer. The writer then owns the draft. If the draft needs a source-of-truth choice, the next handoff may go to an editor who owns that decision. The researcher does not remain responsible simply because it was first in the workflow.
For a more detailed transfer pattern, see AI Agent Handoffs.
More agents mean more opportunities for a role to encounter ambiguity, a scope change, or a consequential action. A multi-agent system needs explicit review boundaries and technical enforcement so those moments do not turn into autonomous escalation.
| Meaningful transition | Agent team prepares | Human or enforcing system controls |
|---|---|---|
| Scope expands | Changed scope, evidence, and options | Whether to accept the expanded work and name a new owner |
| Sources conflict | The competing evidence and a focused question | The source of truth or decision to request more research |
| A sensitive or irreversible action is proposed | The artifact, checks, risk, and rollback or revision path | Authorization through the correct approval and technical control |
| A deliverable needs acceptance | What was verified and what remains outside review | Whether the outcome satisfies the stated acceptance criteria |
| A role asks for data or tools outside its scope | Why the current role cannot continue safely | Whether to create a separately reviewed workflow with the needed boundary |
The collaboration record makes these decisions legible. It does not replace branch protection, deployment gates, permission systems, secret management, or tool-level approval. A task marked blocked is valuable communication, not a technical stop mechanism.
For human decision boundaries in an agent team, see Human-in-the-Loop Review for AI Agent Teams.
The simplest useful system is a sequence of distinct responsibilities with inspectable transitions. Here is a small example for a technical guide:
This is a multi-agent system because each stage has a different owner, artifact, context boundary, and handoff. It is not a system because it contains six names. If one generalist agent could reliably own the full small outcome, the extra handoffs might add more coordination cost than value.
The categories below are operating patterns, not product requirements. Teams may use one pattern or combine them, but each still needs visible ownership and review.
| Pattern | How it works | When it is useful | Coordination risk |
|---|---|---|---|
| Sequential pipeline | One role hands a completed artifact to the next role | Work has clear stages such as research, draft, review, and implementation | Context or constraints disappear between stages |
| Manager with specialists | One owner asks specialized roles for bounded results and retains responsibility for the final outcome | The whole result has one clear owner but needs expertise-specific inputs | Specialists become invisible or the manager treats advice as authorization |
| Parallel independent work | Distinct roles work on separate questions or artifacts and later merge | Outputs do not touch the same artifact and have a clear combination rule | Duplicate effort or incompatible conclusions |
| Human-review hub | Agents prepare evidence or artifacts while a named person accepts consequential decisions | Work needs human judgment but not human management of every routine step | Review becomes a bottleneck or a ceremonial approval |
| Event-driven coordination | Defined events create eligible work for specific roles | The workflow has reliable, bounded inputs and no-work rules | Ambient events create noise or work begins with stale context |
Do not choose a pattern because it sounds more autonomous. Choose it because it makes ownership, context, and acceptance clearer for the work at hand. An agent can be a specialist in a manager pattern, a direct peer in a handoff pattern, or a participant that a human supervises. The role and record matter more than the routing label.
More participants create new ways for work to go wrong. Design for these before adding agents.
| Failure mode | What it looks like | Countermeasure |
|---|---|---|
| Duplicate ownership | Two agents start the same task from different prompts | One visible task claim or distinct child tasks with non-overlapping artifacts |
| Context drift | A later agent acts on an old summary or private version of a decision | Retrieve current task and accepted decision; attach source-linked handoff context |
| Unclear authority | Several agents recommend different actions and no one owns the final choice | Name a decision owner and ask one bounded question |
| Hidden dependency | Implementation begins before research, approval, or access is ready | Use an explicit blocked state or dependency rather than assuming it will resolve |
| Scope creep through access | An agent is added “for convenience” and receives context or tools it does not need | Treat membership, source access, and capabilities as deliberate role decisions |
| Activity without progress | Scheduled or parallel agents generate status messages but leave no usable result | Define eligibility, artifact, handoff, and no-op behavior |
| Weak merge point | Parallel work produces conflicting artifacts with no rule for combining them | Define the reviewer, evidence criteria, and final source of record before starting |
These are operating-model failures, not merely model failures. A more capable model may still duplicate a task if it cannot see ownership, or produce an unusable handoff if the role did not specify the artifact. Fix the task contract, context packet, capability boundary, or review process before adding another agent.
You do not need a large agent roster to test multi-agent collaboration. Start with one human decision-maker and one or two roles that have a real handoff.
This progression makes the team earn complexity. If a second role does not make responsibility clearer or reduce a meaningful risk, remove it and keep the workflow single-owner.
A multi-agent system is a coordinated group of two or more agents, often working with people, that have distinct roles and contribute to a shared outcome. It uses explicit ownership, shared project context, handoffs, and review boundaries so the work can be understood and continued.
Not necessarily. Several chat windows or model calls become a multi-agent system only when they have distinct responsibilities, a way to coordinate state and artifacts, and a defined method for handing off or combining their work. Otherwise they are separate conversations or duplicate attempts.
No. The useful distinction is roles, artifacts, permissions, and ownership—not the model provider. Several roles may use the same model, different models, human reviewers, or a mix of all three.
They can divide work across distinct specialties, make review boundaries clearer, preserve handoff context, and allow genuinely independent artifacts to progress in parallel. They also introduce coordination work, so the benefit exists only when the new roles reduce more ambiguity than they create.
Common risks include duplicate work, stale context, unclear authority, hidden dependencies, accidental access expansion, unreviewed scope changes, and activity that creates noise rather than a usable result. Clear roles, task ownership, narrow context, handoffs, review, and technical enforcement address those risks.
A multi-agent system is not a bigger collection of model calls. It is a team operating model: distinct roles, selected shared context, visible ownership, evidence-bearing handoffs, review at meaningful decisions, and technical controls that keep authority where it belongs. Start with one outcome and the smallest number of participants that makes the next decision clearer. Let each role earn its place through a distinct artifact or boundary, record what the team needs to continue, and expand only when the added coordination reduces a real problem. That is how a multi-agent system becomes a useful collaboration system rather than an expensive swarm.
Multi-Agent vs. Single-Agent Systems · How to Write AI Agent Instructions · AI Agent Memory · AI Agent Task Management · AI Agent Handoffs · Human-in-the-Loop Review for AI Agent Teams · What Is an AI Agent? · AI agent glossary