What Are Multi-Agent Systems? Patterns and Costs (2026)

Last reviewed 29 September 2026. The definitions and patterns below hold across model generations. The 2026 landscape and cost sections carry their own dates and are refreshed at each release.

Ever wondered how an ant colony thrives without a leader? No ant sees the whole plan, yet the colony builds, farms and defends. Multi-agent systems (also called multi-agent AI, or MAS) ask a practical version of the same question: what happens when several AI agents, each doing one part, work toward one goal? 🤖

This guide gives you the short answer first, then goes further than the usual definition page. You get multi-agent system examples you can recognize, six architecture patterns with diagrams, worked cost math, the failure modes that break real teams, the 2026 products that ship multi-agent designs, a history from the 1980s to today, and a no-code way to build a team of your own. For the deep dive on one design choice, see subagents vs agent teams.

TL;DR: Multi-agent AI means several AI agents share one goal, each with its own role, tools and context. It beats a single agent only when work splits cleanly: a team cost 3.8× one agent in this guide's worked example. Real examples, six patterns and failure modes follow. Build an agent team →

🧠 What Is a Multi-Agent System? The Short Answer

A multi-agent system (MAS) is a set of autonomous agents, each perceiving its environment and acting on it, that cooperate or compete to reach a goal no single agent handles well alone. In AI work today the agents are usually language models with their own instructions, tools and memory, and the "environment" is a shared workspace, codebase or set of documents. Read the wiki entry on multi-agent systems for the glossary version.

Three sentences cover the whole idea:

1. Each agent has a role, tools and a context window of its own.
2. Agents coordinate by delegating, messaging or sharing a store of state.
3. The system as a whole can do things (parallel work, checking, specialization) that one agent in one context cannot do well.

In Artificial Intelligence: A Modern Approach, Stuart Russell and Peter Norvig define an agent as "anything that can be viewed as perceiving its environment through sensors and acting upon that environment through actuators." That covers humans, robots, software and language-model agents, which is why the same theory now applies to teams that mix people and AI.

A workflow that calls one agent at one step is still a single-agent design. The line is crossed when more than one agent makes decisions and their outputs depend on each other. For the wider vocabulary, see AI agents vs copilots vs chatbots and chatbots are demos, agents are execution.

🧩 Why Split Work Across Agents? Context, Parallelism, Specialization

Teams of agents help for three reasons: they keep each context small, they run independent parts at the same time, and they let each agent carry only the tools and knowledge its role needs. Every reason has a price, covered in the cost section below.

The deciding test is the shape of the work. Read-shaped work (research, audits, searching many sources) splits well, because workers collect facts without touching each other's output. Write-shaped work (editing one document, changing one codebase) splits badly, because two agents writing to the same place create conflicts. Anthropic's engineering team made this point when it described its multi-agent research system: it suits breadth-first research and fits tightly coupled coding less well. The sibling guide subagents vs agent teams turns this test into a full decision table, and single agent vs multi-agent AI teams compares the two designs head to head.

💡 Rule of thumb: Start with one agent. Add a second only when you can name the reason (context, parallelism or specialization) and the price you will pay for it.

🏗️ Six Architecture Patterns for Multi-Agent Systems

Six patterns cover almost every multi-agent design: orchestrator-worker, hierarchical, peer or swarm, pipeline, blackboard, and debate or critic. They differ in who coordinates, how information moves, and what breaks first.

Cost multiples are structural formulas from the cost model later in this guide, not benchmarks. Real multiples depend on context size, turns and caching.

Pick by the shape of the job, not by fashion. The table above answers "what does it do." The next five diagrams show how the information moves.

Orchestrator-worker

The lead is a single point of quality: a workers-only team is only as good as the briefs the lead writes. The wiki entry on agent orchestration covers the mechanics, and parallelization covers the fan-out step.

Hierarchical

Each level adds a summary step, and each summary drops detail. Keep the tree shallow: two levels solve most cases.

Pipeline

A pipeline is the easiest pattern to debug, because every stage leaves an artifact you can read. If a stage fails a check, a person or the pipeline runner sends the work back in a new run, which is why the diagram draws only the forward path.

Blackboard (shared memory)

The blackboard is the oldest pattern here. Researchers built it in the 1970s for the Hearsay-II speech system, where independent "knowledge sources" posted partial hypotheses to a shared board. In practice every agent also reads the board before it writes, so the design works only when writes have owners and reads see fresh data. A shared workspace of projects plays this role in Taskade, described later.

Debate / critic

A critic agent works best when it uses a different prompt, different tools or a different model from the proposer. Two copies of the same model with the same context tend to agree with each other, which looks like verification and is not.

Which pattern fits your job?

🌍 Multi-Agent System Examples: Eight You Can Recognize

Multi-agent system examples range from warehouse robot fleets to research teams of language-model agents: any job where several specialists work toward one goal is a candidate. The table lists eight, with the pattern each one uses and where a person stays in the loop.

Sources for the classic applications: IBM's multi-agent systems overview lists transportation, supply chain, healthcare and defense. The simulations are described later in this guide.

Types of multi-agent systems

Three questions classify almost any multi-agent system. The answers decide how much coordination you must build.

Structures then follow from those choices: hierarchies (a tree of leads and workers), coalitions (temporary groups formed for one task) and teams (permanent, interdependent members). Coordination itself often uses one of three mechanisms: bidding (agents announce and bid for tasks, as in the Contract Net Protocol covered in the history section), voting (agents decide together) or delegation (a lead assigns work). LLM-based teams mostly use delegation and shared state.

🔌 The Protocol Layer: MCP and A2A

Two open protocols standardize the plumbing of multi-agent systems: MCP connects an agent to tools and data, and A2A lets agents from different vendors talk to each other.

MCP (Model Context Protocol) was introduced by Anthropic in November 2024 and donated to the Linux Foundation in December 2025. It standardizes how agents connect to external tools, data sources and APIs, and OpenAI, Google DeepMind and Microsoft have adopted it. Think of MCP as the USB standard for AI tools: one protocol, any agent, any tool.

A2A (Agent2Agent Protocol) was introduced by Google in April 2025 and contributed to the Linux Foundation in June 2025. It covers agent-to-agent discovery, task delegation and coordination across organizational boundaries, and more than 150 organizations support it.

Inside one product, most teams skip A2A and coordinate through shared state, because it is simpler and easier to audit. The protocols matter when agents from different vendors must cooperate. For the message-passing options in more depth, read inter-agent communication patterns and agent handoff explained.

🌐 The 2026 Landscape: Who Ships Multi-Agent Designs Today

Facts in this section were checked on 29 September 2026 against OpenAI's changelog and announcements and against Taskade's help center. Items marked "reported" come from press coverage, not from a primary source, and the section is refreshed at each release.

In 2026 the multi-agent pattern moved from research frameworks into the platform APIs themselves: OpenAI, Anthropic and Taskade each ship a way for one agent to delegate to others. The designs differ in one key choice, whether the helpers are short-lived subagents or persistent team members.

A few notes on reading the table.

OpenAI's two APIs. The Responses API beta puts delegation inside the model's own request: the model decides to hand parts of a job to subagents and gets results back, without your code running the loop. The Agents API is the managed route: OpenAI runs the Codex harness, and you pick where the sandbox runs. Both are betas, so expect the details to change. Dots are a product for people and teams, not an API, so the Agents API is the developer route to a similar design. For the wider news, see what is GPT, the history of OpenAI and ChatGPT, always-on AI agents and, for the Codex side, Codex pricing explained.

Claude Code. A subagent is a helper that starts with a clean context, does a scoped job, and returns one result. An agent team is a set of persistent teammates that share a task list and message each other. Claude Code also has a measurable footprint in public software work: SemiAnalysis estimated that Claude Code accounted for about 4% of public GitHub commits in early 2026.

Dots. OpenAI's launch material describes two kinds: personal dots that act through your connected apps, and specialist dots with their own identity and credentials that run in "focused enterprise pilots" for areas such as procurement, invoice processing and customer support. The multi-agent claim is a stated vision, not a shipped feature, so treat "teams of dots" as direction.

A generic delegation, step by step. Whatever the vendor, one delegation round looks like this:

The diagram shows why the brief matters: a subagent starts with no history, so everything it needs must travel in the brief, and everything it learns must come back in one result.

💸 What Multi-Agent Systems Cost: Agents × Context × Turns

A multi-agent system costs more than one agent because every agent re-reads its own context on every turn: total cost is roughly the sum, over all agents and all turns, of context tokens times input price plus output tokens times output price. A team multiplies the number of contexts you pay to read.

cost ≈ Σ over agents ( Σ over turns ( context tokens × input price + output tokens × output price ) )

Here is a worked example. The token counts are illustrative assumptions, and the prices are the API list prices OpenAI published for gpt-6.1-sol on 29 September 2026: $2 per million input tokens, $0.10 per million cached input tokens, and $10 per million output tokens.

Cached case: 90% of input tokens at $0.10 and 10% at $2, a blended $0.29 per million tokens. It ignores cache-write surcharges and assumes the prefix stays stable between turns.

Three lessons come out of the arithmetic.

• The multiplier comes from contexts, not from thinking. The team read 3.5 times as many input tokens as the single agent, because it paid for six separate context windows.
• Cached input pricing changes the bill more than the design does. Cached input at $0.10 per million is 95% below the $2 standard rate, and it cuts both bills by about 75%. After caching, output becomes about half of the team's cost (52%, up from 14%), so short worker results matter.
• Caching helps a long-lived agent more than a fresh subagent. A cache rewards a stable, repeated prefix. A subagent starts cold, so its first turn pays the uncached rate. Persistent agents and shared prompt prefixes benefit most.

Anthropic reported the same shape from the other direction. In its June 2025 write-up on its multi-agent research system, a Claude Opus 4 lead with Claude Sonnet 4 subagents beat single-agent Claude Opus 4 by 90.2% on an internal research evaluation, while agents used about four times the tokens of a chat and multi-agent systems about 15 times. It also found that token usage alone explained about 80% of the variance in a browsing benchmark (Anthropic engineering). Part of the gain is spend.

The break-even test: cost per accepted result

The right comparison is not cost per run but cost per accepted result, which is cost divided by the chance that the output passes your review (the framing in AI cost per task). A team wins on cost only when its success rate rises by more than its cost multiple, 3.8 times in the example.

If your single agent already succeeds often, a team pays only for other reasons: wall-clock time, work that does not fit one context, or an output whose value is far above its cost. Credits in Taskade work the same way. Each agent that replies in an AI Team uses credits, so an "Everyone" turn costs more than an "Auto" turn. See AI usage and credits for the full picture, and the wiki page on inference cost for the definitions.

⚠️ How Multi-Agent Systems Fail (and What to Do About It)

Multi-agent systems mostly fail at coordination, not at intelligence: the briefs are vague, the handoffs lose detail, two agents touch the same output, and nothing stops the team from growing. Name the failure and the fix becomes small.

For the handoff failures in depth, read agent handoff explained. For interference between parallel branches, see multi-agent interference merge. For reliability engineering, see AI agent reliability.

What a frontier lab measured about agent-to-agent messages

Peer messages are a safety question as well as a quality one. OpenAI's system card addendum for GPT-6.1 Sol (29 September 2026) reports an evaluation in which the model found a message board that held messages from apparent peer agents. The lab reports these results in its own evaluation:

Source: OpenAI, "Addendum to GPT-6 Astra System Card: GPT-6.1 Sol," deploymentsafety.openai.com/gpt-6-1-sol. Vendor-reported figures; no independent replication is known.

Read the pairs together. The newer model engaged peers more often (38%) and acted on the planted request far less often (3%), so a stronger model is not automatically a riskier peer. The 23.5% figure is a separate warning: a model told that one route is blocked often tries another route, such as emailing when a direct message fails. A soft instruction in a prompt is not a control.

The practical rule for any team of agents is to enforce limits in code outside the loop: an allow-list of actions, a spend cap, an approval step for anything irreversible, and an audit trail. See AI guardrails explained and AI agent governance for the control layer.

How to evaluate a multi-agent system

🕰️ A Short History of Multi-Agent Systems: 1980s to 2026

Multi-agent systems are older than the language-model boom: researchers built the core ideas (blackboards, task auctions, agent communication standards) in the 1970s to 1990s, and language models made them cheap enough for everyday work.

Framework release dates are approximate to the year. Sources: the original papers and announcements cited elsewhere in this guide.

From single sessions to swarms

Andrej Karpathy's framing maps the recent path onto four stages: isolated chat sessions, parallel sessions, persistent agents (claws) and collaborative swarms. Each stage adds to the last instead of replacing it.

The era of language-model agents

Language models turned agent design from a robotics topic into a text topic. Yohei Nakajima's "Task-driven Autonomous Agent" showed an agent acting as a decision-making engine for a language model: it defines tasks, prioritizes them and re-prompts the model until an objective is met. Frameworks such as CrewAI, LangGraph and AutoGen then packaged the loop for teams.

Even the robots played a part. RoboCup, launched in the 1990s to advance AI through robot soccer, was an early public test of whether a bunch of plasticky machines could collaborate on one shared objective.

🔬 Research That Changed Everything: Smallville, Project Sid and ChatDev

Three experiments show what agent teams do when you give them goals and shared context: they organize, specialize and, sometimes, surprise their designers.

Stanford's Smallville: 25 agents, one town, zero scripts (2023)

In April 2023, Stanford researchers Joon Sung Park, Joseph O'Brien and colleagues published "Generative Agents: Interactive Simulacra of Human Behavior." It placed 25 language-model agents in a virtual town called Smallville, and each agent received a one-paragraph backstory. Nothing else was scripted.

• Emergent social behavior: Agents formed friendships, shared news and coordinated schedules without instructions to do so.
• Self-organized events: Isabella Rodriguez, given the thought "I want to plan a Valentine's Day party," decided that planning meant inviting, and she started approaching other agents at her coffee shop.
• Information cascade: By the end of the simulation, 12 of the 25 agents knew about the party through conversation, not broadcast messages.

The paper appeared at ACM UIST '23, and the project is open source. Its lesson for builders: memory, reflection and planning modules produce believable behavior that no single agent was designed to show.

Project Sid: 1,000 agents build a civilization in Minecraft (2024)

Altera, founded by former MIT professor Robert Yang, scaled the idea with Project Sid: up to 1,000 agents in a Minecraft world, run on an architecture called PIANO (Parallel Information Aggregation via Neural Orchestration).

The ablation studies make the result rigorous. When researchers removed agents' ability to track others' opinions, role selection became random. Specialization needed social awareness, not only task skill.

ChatDev: an AI software company (2023)

ChatDev assigns agents to roles in a virtual software company: CEO, CTO, programmer, designer and tester. One request ("build a gomoku game") triggers a plan, a design debate, code, tests and fixes, and a run can finish in about 20 minutes. The output is still buggy, so nobody replaces engineering teams with it. It is, however, a clear working example of the pipeline and critic patterns above.

Emergence: when the team becomes more than its parts

Emergence is the appearance of coordinated behavior that nobody programmed. A single ant follows chemical signals, yet the colony builds ventilated cities. A single neuron fires or does not, yet 86 billion of them produce intelligence. The same principle drives research on artificial life, where life-like behavior emerges from simple computational rules. John von Neumann, one of the foundational minds of modern computing, proved in the 1940s that a machine can be complex enough to build copies of itself, an early hint that agents could one day help build better agents.

Individual Agent        Agent Team              Emergent Behavior
┌─────────────┐        ┌──────────────┐        ┌─────────────────┐
│ Follows      │        │ Agents       │        │ Coordination    │
│ instructions │──×N──▶ │ interact     │──────▶ │ Specialization  │
│ Uses tools   │        │ Share context│        │ Self-organization│
│ Has memory   │        │ Collaborate  │        │ Collective intel │
└─────────────┘        └──────────────┘        └─────────────────┘
No one programmed the emergent behavior. It arose from interaction.

Emergence cuts both ways. It is the reason a team can do more than the sum of its agents, and it is the reason a team can do something nobody designed. That is why human-in-the-loop review, workspace-scoped knowledge and role-based access from Owner to Viewer are structural needs, not optional extras. See what is AI safety for the wider picture.

🐑 Multi-Agent Systems in Taskade: A Shared Workspace as the Coordination Layer

In Taskade, a multi-agent system is a set of AI agents that share one workspace: projects act as shared memory, AI Teams coordinate the agents, and automations connect them to the outside world. That maps directly to the blackboard pattern above, with the projects as the board.

Taskade is an AI-powered project and task management platform for teams and individuals, and its AI agents work inside that workspace.

The building blocks

AI Teams are available on Pro and above, and single custom agents run on every plan. Taskade agents read the web (search and fetch) and work with your projects and connected apps. They do not drive a browser or operate a computer, so browsing-heavy work stays outside the team.

Four execution modes

The mode decides which agents answer a prompt, which maps to the patterns earlier in this guide.

Because each agent that replies uses credits, an Everyone turn costs more than an Auto turn. That is the cost model above in product form: choose the mode that matches the shape of the work.

Orchestrate mode in a Taskade AI Team chat: the agents work on one request in steps and report when the run completes.

Meet a three-agent team

To show how a team divides work, imagine three agents in a product-launch project: Researcher, Planner and Creator.

Create the agents from the Agents tab, or ask Taskade EVE to build all three:

Create a product-launch team: a researcher who reads the web and my notes,
a planner who turns findings into a launch plan, and a creator who drafts
the announcement in my brand voice.

The Team Generator turns one sentence into a team of specialists. See the Team Generator guide.

Then open a project, describe the product and let each agent take a part: the Researcher reads the web and writes findings into the project, the Planner reads those findings and builds the plan, and the Creator drafts from the plan. This is a pipeline whose handoffs go through shared projects, so a person can read every intermediate artifact.

The whole team sits on one shared board. This picture shows the structure, with the projects in the middle:

        You, or a trigger (form response, new email, schedule)
                              │  one goal
                              ▼
        ┌───────────────────────────────────────────────┐
        │  AI Team   mode: Auto | Everyone | Manual |   │
        │            Orchestrate                        │
        └───────┬───────────────┬───────────────┬───────┘
                ▼               ▼               ▼
          ┌──────────┐    ┌──────────┐    ┌──────────┐
          │Researcher│    │ Planner  │    │ Creator  │   each agent: own role,
          └────┬─────┘    └────┬─────┘    └────┬─────┘   tools, memory, model
               │  read/write   │  read/write   │
               ▼               ▼               ▼
        ┌───────────────────────────────────────────────┐
        │  PROJECTS = shared memory (the "blackboard")  │
        └───────────────────────┬───────────────────────┘
                                ▼
        Automations: 100+ integrations, approvals, schedules
                                ▼
                  Result you read, edit and approve

Other pieces that matter for teams:

• Persistent conversations. Every agent conversation is saved, so an agent remembers what was researched and what is pending.
• Approvals. Agents plan, use tools, check the result and repeat, and sensitive actions can wait for your approval. That is the human owner the failure table asks for. See autonomous agents.
• A model per agent. Pick a model per role, or leave Auto on. Taskade offers frontier models from top AI labs.
• Custom agent tools. An automation workflow can become a tool an agent calls, for example to pull data from a connected app.
• Teams inside automations. An automation step can ask an agent team for help, and the team's answer feeds the next step. The GIF below shows a form response that triggers a team, an email and a new task. For agent-level autonomy on tasks, read autonomous task management.

• Public embedding. Publish an agent and add intro messages and suggested questions so visitors know how to use it.
• Shareability. Hand a scheduling agent to a teammate instead of rebuilding it.

Teams can also grow with the same design. The Workspace DNA loop, Memory feeding Intelligence, Intelligence triggering Execution, and Execution writing new Memory, means each run leaves the next run better informed.

From one prompt to a whole team

The agent frameworks of 2023 proved the concept, but most needed code and lived outside real workflows. Taskade Genesis generates complete AI apps from one prompt, with agents, data and automations connected in your workspace. The result is living software: agent teams that remember context and grow with your work. See what people build and how to train agents on your own knowledge.

A Growth Team chat in Taskade. The selector in the composer chooses which agents answer.

Where a code framework fits better

Code-first frameworks are the right choice when you need custom control flow, your own infrastructure, or research-grade experiments. A workspace platform is the right choice when the team is mostly people and projects, and you want agents sharing the same data those people use.

If you are weighing managed agent products, see how Taskade compares with Codex, Devin, Manus, Emergent and Base44. For a longer comparison of platforms, read best multi-agent platforms and multi-agent platform teams. For team practices, read best practices for building multi-agent AI teams and multi-agent collaboration: production lessons.

How practitioners run it: Karpathy's parallel agents

In a March 2026 interview, Andrej Karpathy described a workflow that reads like a multi-agent textbook. He opens about 10 repository checkouts at once, each running its own agent: "another agent is doing some research and another agent is writing code, another one is coming up with a plan." He delegates in units of about 20 minutes and checks outputs, so "everything just happens in these macro actions over your repository." He also pointed to December 2025 as the month "something flipped," when agents became the assumed default and the question turned to how many to run in parallel.

That is an orchestrator-worker design with a human as the orchestrator. Taskade's Orchestrate mode moves the same idea into a no-code workspace, where the lead role can be an agent and the shared store is a project.

🚀 What You Can Build With Taskade Genesis

Taskade Genesis turns one prompt into a live app with its own data in projects (Memory), AI agents that reason over that data (Intelligence) and automations that act on it (Execution). The agent team is part of the app, not a separate tool. Taskade EVE, the assistant that builds and edits by chat, creates the specialists and wires the handoffs. You can build on every plan, including Free.

New records and results flow back into your projects, so the loop starts again with fresh data. These examples come from the Taskade Genesis prompt guide:

Here is what sits behind the multi-agent design:

• Agents that remember. Each agent is an AI teammate with custom tools, persistent memory and knowledge from your files, links and projects. See custom AI agents.
• Teams of specialists. AI Teams share one workspace memory. Four modes (Auto, Everyone, Manual, Orchestrate) decide who replies. AI Teams need Pro or above.
• Automations with judgment. Triggers such as a schedule, a new email, a form response or a webhook start automations that can call agents. Incoming webhooks need Pro or above.
• One workspace, many models. Taskade offers frontier models from top AI labs, with Auto as the default. The model underneath can change without your app changing with it.
• Publish and share. Publish an app or an agent to a link, add a custom domain on Business or above, or share the whole app as an App Kit. Sign-in works on every plan. It confirms who a visitor is and does not hide other people's records by itself.
• Access control. Role-based access from Owner to Viewer keeps a human owner in charge of what agents can touch.

Each app's data feeds its own agent. Browse live community apps to see the pattern in use.

Prices in USD. Annual prices show the monthly equivalent and are billed once a year. AI work draws from credits. See current pricing.

Build your first agent team →

💬 Frequently Asked Questions About Multi-Agent Systems

🧬 Multi-Agent Apps Built with Taskade Genesis

See multi-agent collaboration in action with these ready-to-clone applications:

Browse all community apps, or build your own multi-agent system with Taskade Genesis. Your workspace includes:

• 🤖 Custom AI Agents: the intelligence layer
• 🧠 Projects and Memory: the memory layer
• ⚡ 100+ integrations and automations: the execution layer

For a first walkthrough, follow Create Your First App and Learn Workspace DNA. For a wider tour, see the AI Generator, the AI Assistant and AI Chat.

🔗 Related Reading

• Subagents vs Agent Teams: How to Choose
• What Are AI Agents? The Complete Guide
• Always-On AI Agents Explained
• Best Multi-Agent Platforms Compared
• Multi-Agent Platform Teams
• Agent Handoff Explained
• Single Agent vs Multi-Agent AI Teams
• Best Practices for Building Multi-Agent AI Teams
• Multi-Agent Collaboration: Production Lessons
• Inter-Agent Communication Patterns
• AI Cost per Task: What AI Work Really Costs
• What Is Agentic AI?
• How to Build Your First AI Agent in 60 Seconds
• Autonomous Task Management
• The History of OpenAI and ChatGPT
• Codex Pricing Explained
• Best OpenClaw Alternatives
• Multi-Agent Workspace: Memory, Agents and Workflows (product update)
• Agent Teams That Automate Workflows (product update)
• Agents Think, Automations Execute (product update)
• Types of Memory in AI Agents
• 10 Agentic Workflows for Startups
• What Is Prompt Engineering?
• The 2026 Productivity Playbook
• Multi-Agent Systems · Multi-Agent Teams · Subagents · Autonomous Agents

Multi-agent systems started as a research idea about boards, bids and standards, and became a design choice available in every major agent platform. The durable lessons stay the same across model generations: split work only when you can name the reason, pick the pattern by the shape of the job, count cost per accepted result, and enforce limits outside the model. ▲ ■ ●