Research report · ai-agents
What 'Multi-Agent' Actually Means: Six Shapes, 36 Tools
36 of the 95 listings in The Agents Index carried our multi-agent tag on 28 August 2026. We sorted the sourced facts into six different shapes.
On this page
36 of the 95 listings published in The Agents Index carried our multi-agent tag on 2026-08-28, spanning seven of our eight categories, and they do six structurally different things. “Multi-agent” shows up on more product pages in our index than almost any other capability claim, and it is also one of the least precise terms in the category: a developer choosing a framework to build a multi-agent system, a buyer evaluating a voice agent that hands off mid-call, and a team comparing coding agents that run copies of themselves in parallel are all reading the same word for three unrelated capabilities. We went through the sourced product facts already published on our own listings for all 36 tagged tools and sorted them by what they actually do, not by the tag alone. Six distinct shapes came out.
Correction, 11 September 2026. This report originally read “36 of the 94 AI agent tools in The Agents Index carry our multi-agent tag, counted on 2026-08-28.” Those two figures were read a day apart and never belonged to one reading of the index: on 26 August 2026 we held 94 published listings of which 35 carried the tag, and on 27 August we held 95 of which 36 carried it. The 94 is the earlier day’s population under the later day’s roster, so the pair is withdrawn. This page is restated to the single reading that produces every figure on it at once, 28 August 2026: 95 published listings, 36 of them tagged multi-agent, spanning seven of our eight categories. Only the population moves, from 94 to 95. Every category figure, both named rosters and all six shape counts are that reading’s own. If you cited the earlier 36-of-94 figure, this is the correction.
Shape 1: Composable frameworks, where you design the multi-agent system
Eleven of our fourteen frameworks listings are tagged multi-agent, and this is the shape most developers mean when they say the word: a library or SDK that gives you the primitives to wire multiple agents together yourself, and gets out of the way. LangChain and LangGraph are indexed separately and both carry the tag. LangChain’s own description points at LangGraph for “stateful multi-agent control,” and the LangGraph listing sets out what that means: an implementation of the Pregel algorithm that models agents as graphs with cycles rather than DAGs, so they can loop, retry and revisit steps, supporting single-agent, multi-agent and hierarchical control flows in one framework. CrewAI has you define role-based agents that collaborate on tasks, with “Flows” for tighter, event-driven control. Microsoft AutoGen coordinates message-passing between named agents with prebuilt patterns: two-agent chat, group chat, round-robin teams. Its successor, Microsoft Agent Framework, generalizes that into graph-based orchestration patterns (sequential, concurrent, handoff, group-collaboration) plus native support for the Agent2Agent (A2A) interop protocol. LlamaIndex’s Workflows is an event-driven abstraction for “multi-step and multi-agent processes with state.” OpenAI Agents SDK and Pydantic AI both center the pattern on explicit handoffs: one agent routes a request to a specialist, carrying context along. Google ADK adds a Task API for “structured multi-turn delegation between agents” on top of its own graph runtime. Agno has you define Teams of agents that collaborate and share context directly in Python, alongside built-in memory and knowledge primitives. Claude Agent SDK is the outlier in this group: its Subagents feature spawns focused specialists from within one session rather than composing a standing multi-agent graph, closer in spirit to Shape 4 below, but built as a general-purpose SDK primitive like the rest of this group.
Three of our fourteen framework listings are not tagged multi-agent, and in each case the omission is deliberate rather than an oversight: Letta’s whole pitch is durable single-agent memory (versioned, git-like “Context Repositories”), with no multi-agent orchestration primitive in its own published feature set; Mastra unifies typed agents, workflows, memory and observability behind one API, but its own description doesn’t claim an agent-to-agent handoff or coordination primitive the way LangGraph or AutoGen do; AgentsKit’s published feature set is a breadth story, 25 model adapters, 50 integrations, a 17-backend memory layer, UI bindings for seven frontend frameworks, about what one agent can reach rather than about agents coordinating with each other. None of the three facts is a knock on any of the tools. They’re simply answering a different question.
Shape 2: No-code workforce builders, where your end users assemble the team
Three of our sixteen agent-platforms listings are tagged multi-agent. Lindy has “Agent teams” of Lindies that “trigger and delegate to each other to cover an end-to-end workflow.” Relevance AI markets the pattern directly as “workforces”: a researcher agent enriches a lead, a writer drafts outreach, a scheduler books the meeting, each a separately configured agent in one visual builder. Vecbase ships the same idea as a shared workspace, where users spin agents up from pre-built Researcher, Coder, Writer and Operator roles that share memory, files and tools while each runs in its own sandbox, with repeated workflows captured once as a reusable Skill. This is the framework pattern’s no-code mirror: instead of a developer writing handoff code, a non-technical operator wires named, role-specific agents together in a UI.
The other thirteen agent-platforms listings in our index (n8n, Dify, Sierra, Botsify, Moveworks, Salesforce Agentforce, Glean, Vellum, MindStudio, Sim, OpenClaw, Botpress and ElevenLabs Conversational AI) are workflow, personal-assistant or single-agent-configuration tools by their own published descriptions, not platforms whose headline pitch is coordinating several distinct agents against one another. Botpress’s own feature set centers on one Autonomous Engine (LLMz) that plans and executes multi-step actions from a single instruction rather than a roster of cooperating agents, and ElevenLabs Conversational AI wraps a voice/LLM orchestration layer around one agent definition per deployment. Vellum is a single persistent personal assistant rather than a team of named agents, so it joins this list rather than Shape 2’s.
Shape 3: Vendor-built agent teams, where the agents are the product
Four listings ship multiple specialized agents as the product itself, with no assembly required from the buyer, though only three name each agent individually. Crescendo runs four: a Concierge Agent (customer-facing resolution), Agent Assist (real-time guidance to human reps), a Quality Agent (scores 100% of conversations, not a sample) and an Applied Insights Agent (turns that scoring into KPI reporting). Cresta runs an AI Agent for resolution alongside Agent Assist and a newer Knowledge Agent that proactively surfaces answers to human reps mid-call; its Conductor tool separately generates “subagent orchestration” code from a natural-language use-case description for a developer to review. Factory calls its version Droids: a code droid, review droid, test droid, docs droid and knowledge droid, coordinated by a router rather than one generalist agent handling the whole software development lifecycle. Lead Scorer, this edition’s new listing and the first from sales & marketing agents to carry the tag, doesn’t name its agents individually but chains the same shape: a discovery stage sourced from the French SIRENE and INPI RNE state registries, a two-level ICP-scoring stage that rates each account and each decision-maker separately, and a drafting stage that queues LinkedIn and email copy for human approval before anything sends. In all four cases, the vendor decides the roster and the coordination logic; the buyer configures behavior, not architecture.
Shape 4: Parallel fan-out, one task split across copies of the same job
This is the largest bucket after frameworks, and the shape you’ll hit most often in coding agents and research agents: a single task gets split across multiple agent instances working simultaneously, then the results are merged or simply run to completion in parallel. Muse Code, Meta’s own terminal coding agent, fans a large job out to sub-agents that work simultaneously in isolated git worktrees, and Meta demoed building six game features concurrently with no merge conflicts. Devin can run “a fleet of parallel Devins” on independent tickets or a multi-repo migration, because each session gets its own cloud machine. Zot’s “Swarm” runs background subagents in parallel on the same repository. Antigravity CLI’s Subagents split a larger job into concurrent background tasks inside one session. Google’s own transition announcement cites this directly as the reason it rebuilt Gemini CLI. OpenHands’ Large Codebase SDK “orchestrates changes so multiple agents can work in parallel without stepping on each other’s edits.” Augment Code’s Cosmos runtime runs agents in isolated sandboxes that share a file system, so several can work on the same project at once, and its loops start from GitHub, GitLab, Slack, Linear or Jira triggers rather than from a person launching each one by hand.
On the research side, Manus’s “Wide Research” fans a job out across many parallel sub-agents to cover a topic broadly; GPT Researcher runs a planner agent that writes sub-questions, executor agents that search and summarize in parallel, and a publisher agent that stitches the result together; and GC AI’s Research Agent runs specialized legal-research agents in parallel across jurisdictions, agencies and courts before reconciling the findings.
Codex CLI is the weakest case for this bucket and worth stating precisely, because it shows where the tag’s edge actually sits. Its published feature set delegates focused sub-tasks to subagents from within a session, and codex cloud hands a task to OpenAI’s hosted infrastructure to run asynchronously instead of on your own machine, but its own text describes delegation to specialists rather than claiming those subagents run concurrently. It sits here on delegation, not on measured parallelism. None of these tools expose the sub-agent choreography to the buyer the way a framework does: you get one task in and one deliverable out, faster or more thorough than a single linear agent would manage alone.
Shape 5: Sequential handoff mid-conversation, voice’s own version of the pattern
Five of our twelve voice agents listings carry the multi-agent tag, and all five implement it as an in-call handoff. Vapi calls this “Squads,” multiple specialized agents that hand off to one another within a single phone call. LiveKit Agents, Synthflow AI and Deepgram Voice Agent API all describe the same shape: one call starts with a general or triage agent and transfers to a specialist (a booking agent, a qualification agent) with conversation context intact, rather than one agent trying to do everything. Cartesia’s Line SDK implements the same idea through a documented agent_as_handoff() primitive, letting a main agent transfer a caller to a specialist mid-conversation. This is structurally closer to Shape 1’s “handoff” pattern than to Shape 4’s parallel fan-out: it’s sequential, not simultaneous, and the point is specialization mid-conversation, not throughput. VoiceAgent runs a single Nigerian-language agent per call with no documented handoff to a second specialist, so it does not carry the tag.
Shape 6: Multi-vendor hosting, other companies’ agents as the product
The least obvious shape, and arguably the most useful one to know about if you’re choosing a coding environment rather than a single agent: three editors let you run other vendors’ coding agents side by side, as a selling point in itself. Warp’s terminal can “host and coordinate other vendors’ coding agents (Claude Code, Codex) in the same session” alongside its own Warp Agent. Windsurf (now Devin Desktop) ships the open Agent Client Protocol (ACP) so “third-party agents such as Devin Cloud, Devin Local, Claude Agent and Codex can run as first-class citizens inside the editor.” Zed authored ACP itself and runs Claude Code, OpenAI Codex, Gemini CLI, GitHub Copilot and OpenCode as native “External Agents” inside its Agent Panel, a standard JetBrains has since adopted for IntelliJ IDEA, PyCharm and WebStorm. None of these three are coordinating agents that cooperate on one task the way Shapes 1-5 do; they’re giving you a single place to run whichever competing agent product you’d rather use that day, and switch without leaving the editor.
Why the distinction matters when you’re buying
If you’re evaluating tools on a “supports multi-agent” checklist item, the six shapes above answer different questions and aren’t substitutes for each other. A team that wants to build a custom multi-agent pipeline needs Shape 1. Shapes 2 through 6 won’t expose that control. A team evaluating a voice agent for a support line cares whether it does Shape 5’s mid-call handoff, not whether some coding agent elsewhere in our index runs parallel sub-agents. A developer choosing an editor because they want the freedom to switch between Claude Code and Codex without switching apps is really shopping for Shape 6, a fundamentally different thing from the orchestration engines in Shape 1 despite both wearing the same tag. The tag tells you a tool does something with more than one agent; only the underlying facts (which we keep on each tool’s own listing) tell you which of the six things it actually is.
How we counted
Counted on 2026-08-28 against the index as it stood that day: 95 published listings, of which 36 carried our multi-agent tag, spread across seven of our eight categories (frameworks 11 of 14, coding agents 11 of 25, voice agents 5 of 12, research and data agents 3 of 11, agent platforms 3 of 16, support agents 2 of 9, sales and marketing agents 1 of 8; agent tools alone had none). Ninety-four of those 95 listings sat in the eight product categories the tag is read across; the ninety-fifth was our one agencies listing, Agentix Labs, a build partner rather than a product, which sat in no product category and carried no tag. Those seven category figures account for all 36 tagged tools with none counted twice. The six shapes are a second, independent cut of the same 36 tagged tools: composable frameworks 11, no-code workforce builders 3, vendor-built agent teams 4, parallel fan-out 10, sequential voice handoff 5, multi-vendor hosting 3. Both cuts sum to 36, and a reader can check that arithmetic without access to our database.
The tag is our own classification, not a vendor’s. We apply it when a listing’s sourced product facts describe more than one agent, and the six shapes are our reading of those facts. It can come off as well as go on: a tool that routes one request across several underlying models is doing something real, but it is not running several agents, and we untag it when a re-read of the sourced facts says so. Membership moves in both directions independently of the total, which is why we re-derive the roster rather than the headline count: since the last count, one listing joined the index, Lead Scorer, and it qualifies, becoming the sales-and-marketing category’s first multi-agent entry and pushing the roster from six categories to seven. That’s a different result from the previous update, where two new listings joined and neither qualified; this time the denominator and the roster moved together because a genuinely new pipeline shape entered the sample, not just a new product that missed the bar. The figures above are the count on the date named, and this page is rebased when it changes.
Every fact above is drawn from the sourced product descriptions already published on each tool’s own listing page: see Frameworks, Coding agents, Agent platforms, Research & data agents, Support agents, Sales & marketing agents and Voice agents for the full researched detail behind every tool named here.
Get the next report
New agents and articles, by email, at most once a week. One-click unsubscribe.