Multi-agent systems use multiple AI agents that collaborate on tasks. Instead of one model doing everything, specialized agents handle different parts of a workflow. Here’s when this works, when it doesn’t, and how to build it.

When multi-agent makes sense

Good use cases:

• Different parts of a task need different expertise (research agent + writing agent + review agent)
• Tasks are parallelizable (Kimi’s Agent Swarm refactoring 50 files at once)
• You need different models for different subtasks (model routing at the agent level)
• Workflows span multiple systems (support agent → billing agent → shipping agent)

Bad use cases:

• Simple tasks that one model handles fine (don’t add complexity for no reason)
• Tasks with heavy dependencies between steps (agents spend more time coordinating than working)
• When you don’t have the infrastructure to manage multiple agents

Architecture patterns

Pattern 1: Sequential pipeline

Agent A (research) → Agent B (draft) → Agent C (review) → Output

Each agent processes the output of the previous one. Simple, predictable, easy to debug.

When to use: Content generation, data processing pipelines, code review workflows.

Pattern 2: Parallel fan-out

                    → Agent B1 (file1.ts)
Task → Agent A  → Agent B2 (file2.ts) → Agent C (merge)
                    → Agent B3 (file3.ts)

A coordinator splits work across parallel agents, then merges results. This is what Kimi’s Agent Swarm does.

When to use: Batch refactoring, multi-file changes, independent subtasks.

Pattern 3: Hierarchical delegation

Manager Agent
  ├── Research Agent (uses web search MCP)
  ├── Coding Agent (uses filesystem MCP)
  └── Review Agent (uses git MCP)

A manager agent decides which specialist to delegate to based on the task. Each specialist has its own MCP tools.

When to use: Complex workflows where different steps need different tools and expertise.

Pattern 4: Peer collaboration (A2A)

Agent A ←→ Agent B ←→ Agent C
(each is independent, communicates via A2A protocol)

Agents from different vendors/teams communicate as peers using A2A. No central coordinator.

When to use: Cross-organization workflows, enterprise integrations.

The protocol stack

Layer	Protocol	Purpose
Agent ↔ Tools	MCP	Each agent accesses its tools
Agent ↔ Agent	A2A	Agents communicate with each other
Orchestration	Your code	Manages the workflow

See our MCP vs A2A comparison for when to use each.

Building it in practice

Simple: Sequential with different models

# Research with cheap model
research = call_llm("deepseek-chat", f"Research: {topic}")

# Draft with medium model  
draft = call_llm("claude-sonnet-4.6", f"Write article based on: {research}")

# Review with best model
review = call_llm("claude-opus-4.6", f"Review and improve: {draft}")

This is multi-agent in the simplest form — different models for different steps. No framework needed.

Medium: Parallel with MCP

import asyncio

async def refactor_file(filepath, instructions):
    """Each 'agent' is an MCP-connected LLM call."""
    content = await mcp_read_file(filepath)
    refactored = await call_llm("claude-sonnet-4.6", 
        f"Refactor this file: {instructions}\n\n{content}")
    await mcp_write_file(filepath, refactored)

# Fan out across files
files = ["src/auth.ts", "src/api.ts", "src/db.ts"]
await asyncio.gather(*[refactor_file(f, "Use dependency injection") for f in files])

Advanced: A2A delegation

For cross-system workflows, use the A2A protocol to delegate between specialized agents. This is enterprise-grade and requires more infrastructure.

Common pitfalls

1. Over-engineering — Most tasks don’t need multi-agent. Start with one agent, add more only when you hit limits.

2. Coordination overhead — Agents spend tokens communicating. If coordination costs exceed the benefit of parallelism, use a single agent.

3. Error cascading — One agent’s bad output becomes another agent’s bad input. Add validation between steps.

4. Cost multiplication — N agents = N× the API costs. Use cheap models for routine agents.

5. Debugging complexity — When something goes wrong, which agent caused it? Use observability with per-agent tracing.

Tools

Tool	Multi-agent support
Kimi CLI	Agent Swarm (built-in)
LangGraph	Graph-based agent orchestration
CrewAI	Role-based multi-agent framework
MCP + custom code	DIY with full control

For most developers, start with sequential pipelines using different models. Graduate to parallel execution when you have parallelizable tasks. Use frameworks like CrewAI or LangGraph only when your workflow is complex enough to justify the abstraction.

Related: Kimi Agent Swarm Deep Dive · MCP Complete Guide · What is A2A? · Tool Calling Patterns