Multi-Agent Systems

Coordinated multi-agent workflows — manager+worker, debate, swarm patterns. CrewAI, AutoGen, Swarm.

Capability notes

Multi-agent systems in 2026 coordinate multiple LLM instances — each with its own role, goals, and tool access — to solve problems that exceed single-agent capability. Dominant frameworks: **CrewAI** (role-based agent orchestration, each agent has a defined role, goal, and backstory), **AutoGen** (Microsoft's conversational agent framework with group chat and nested chat patterns), and **LangGraph** (state machine with multi-agent subgraphs). Each targets different coordination complexity. Multi-agent architectures follow three patterns. **Hierarchical**: a manager agent decomposes tasks and delegates to specialist agents, who report back — the manager synthesizes. Used in CrewAI with a "manager" agent and specialist "crew." Strengths: clear accountability, manageable complexity, scalable to 10-20 agents. Weaknesses: manager becomes a bottleneck; if the manager hallucinates a task, N agents execute on a wrong premise. **Peer-to-peer**: agents communicate directly, forming ad-hoc teams based on task needs. Used in AutoGen's group chat. Strengths: flexible, no bottleneck, emergent collaboration. Weaknesses: coordination overhead grows O(n²) with agent count; agents can form "echo chambers" where they agree on wrong conclusions. **Market-based**: agents bid on tasks, compete for resources, and negotiate. Experimental — no production framework yet. Research systems (CAMEL, ChatDev) demonstrate the pattern but not at production reliability. [DeepSeek V4](/models/deepseek-v4) leads as the manager/coordinator model — its reasoning capability handles task decomposition and cross-agent synthesis. [Llama 3.3 70B](/models/llama-3-3-70b) and [Qwen 3 32B](/models/qwen-3-32b) work as specialist agents (research, writing, code review). A common configuration: one [DeepSeek V4](/models/deepseek-v4) instance as manager + 3-5 [Qwen 3 32B](/models/qwen-3-32b) instances as specialists. The specialists are ~3-5× cheaper to run per token than the manager. Emergent behavior — agents developing coordination patterns not explicitly programmed — is the promise and the peril. Systems demonstrate consensus formation (voting on competing interpretations), role negotiation (agents renegotiating their scope when tasks overlap), and specialization (agents gravitating toward subtasks matching their role description). The peril: these behaviors are unpredictable and can degrade system performance.

If you just want to try this

Lowest-friction path to a working setup.

Start with CrewAI using [Ollama](/tools/ollama) for all agents — zero API cost. CrewAI's role-based model is the easiest to reason about: define agents by name, role, goal, and backstory, then define tasks assigned to specific agents. ```bash pip install crewai crewai-tools ollama pull llama3.3:70b ollama pull qwen3:32b ``` ```python from crewai import Agent, Task, Crew from crewai import LLM manager = LLM(model="ollama/llama3.3:70b") specialist = LLM(model="ollama/qwen3:32b") researcher = Agent(role="Researcher", goal="Find information", backstory="Expert at online research", llm=specialist) writer = Agent(role="Writer", goal="Write clear summaries", backstory="Technical writer", llm=specialist) manager_agent = Agent(role="Manager", goal="Coordinate research and writing", llm=manager) task1 = Task(description="Research recent advances in solid-state batteries", agent=researcher) task2 = Task(description="Write a 500-word summary of the research findings", agent=writer) crew = Crew(agents=[researcher, writer], tasks=[task1, task2], manager_agent=manager_agent) result = crew.kickoff() ``` This 2-agent crew: researcher finds information, writer synthesizes it, manager coordinates. For 2 agents, the coordination overhead is 100-200 tokens per handoff — negligible. Scale to 5+ agents and overhead grows to 500-1000 tokens per handoff. Start with 2 agents, not 10. The beginner trap: designing a "company simulation" with 15 agents (CEO, CTO, CFO, engineers, marketers, etc.) that looks impressive but produces worse output than a single [Llama 3.3 70B](/models/llama-3-3-70b) doing the same work. Multi-agent benefits emerge at 3-5 collaborators with **distinct, complementary expertise** — not role-playing.

For production deployment

Operator-grade recommendation.

Production multi-agent systems face scaling challenges that single-agent systems avoid: coordination overhead, consensus failure, and resource contention. **Agent topology design.** For N agents with M tasks: hierarchical topology (1 manager, N-1 specialists) has coordination complexity O(N). Peer-to-peer topology has coordination complexity O(N²). Decision rule: if task decomposition is straightforward (manager can decompose without specialist input), use hierarchical. If tasks require dynamic team formation (agents discover who they need mid-task), use peer-to-peer but cap N at 5. Beyond 5 agents, peer-to-peer coordination consumes more tokens than task execution — the system spends more resources coordinating than doing useful work. **Consensus mechanisms.** When agents disagree (specialist 1 says "use PostgreSQL," specialist 2 says "use MongoDB"), the system needs a tiebreaker. Options: (1) Manager override — manager decides and specialists accept. Simple, fast, but manager bias compounds. (2) Voting — majority wins; ties escalate to manager. Democratic but slow (N agents must respond). (3) Evidence-based arbitration — agents must cite sources; an arbitrator agent evaluates source quality. Highest quality, slowest, most token-expensive. For production, use manager override with a "dissent log" — losing agents' arguments are preserved in the output for human review. **Agent specialization boundaries.** Each specialist agent has a defined domain. Overlap causes conflict: two agents both claim authority over "database design." Underlap causes gaps: no agent claims "error handling." Solution: define agent domains as mutually exclusive, collectively exhaustive (MECE) categories. The manager validates that every subtask maps to exactly one agent before dispatch. Unmapped subtasks → new specialist needed or manager handles directly. **Inter-agent communication protocol.** Agents communicate via structured messages (JSON): {`from`: agent_id, `to`: agent_id, `type`: "task"|"query"|"result"|"clarification", `content`: ..., `references`: [source_ids]}. Structured messages prevent the "telephone game" — unstructured text from agent A to B to C degrades with each pass. The manager optionally compresses multi-agent conversations into structured summaries before passing downstream. **Resource scheduling.** N agents on M GPUs: schedule LLM calls by priority (manager > specialists, blocking > non-blocking). Manager calls always take priority — if a specialist is waiting on manager output, the system is stalled. Use [vLLM](/tools/vllm) with request priority queues to implement. Monitor: agent idle time (% time waiting for another agent's LLM call). Idle time >30% → improve scheduling or add GPU capacity. For recommended models, see [Llama 3.3 70B](/models/llama-3-3-70b).

What breaks

Failure modes operators see in the wild.

- **Consensus failure / deadlock.** Symptom: two agents disagree on a design decision; neither concedes; the manager calls for more evidence; agents generate more arguments; manager still can't decide; the system stalls. Cause: neither agent's arguments are objectively stronger; the decision is subjective (design preference, not fact). Mitigation: set a decision deadline — if consensus isn't reached in 3 rounds, the manager makes an arbitrary decision and logs the dissent. Use a "tiebreaker" agent pre-configured with a bias (e.g., "prefer simpler solutions") to resolve subjective deadlocks consistently. - **Telephone game degradation.** Symptom: Agent A extracts data → passes to Agent B for analysis → B passes to Agent C for report writing. The final report has factual errors not present in A's original extraction. Cause: each handoff introduces small distortions — B paraphrases A's output, C paraphrases B's. After 3 handoffs, ~15-25% of facts are altered. Mitigation: pass raw data alongside summaries. Agent C receives both B's analysis AND A's extracted data. Use structured intermediate formats (JSON tables, not prose paragraphs) between agents. Minimize agent chain depth — no more than 3 sequential handoffs. - **Role confusion / boundary violation.** Symptom: the "Researcher" agent starts writing the final report because it judges the "Writer" agent's draft as inadequate. The "Writer" agent, receiving no task, generates unsolicited research to stay busy. The crew's output is a mess of overwritten, contradictory sections. Cause: agent roles overlap; agents lack enforcement of role boundaries. Mitigation: task-agent mapping is enforced at framework level — Agent A can only execute tasks assigned to Agent A. Agents cannot self-assign tasks. The manager validates task-to-agent mapping on every dispatch.

Hardware guidance

**Hobbyist ($2,000-$4,000).** Multi-agent needs concurrent model serving. [RTX 4090](/hardware/rtx-4090) 24GB fits: [Llama 3.3 70B](/models/llama-3-3-70b) Q4 (~20GB) + [Qwen 3 32B](/models/qwen-3-32b) Q4 (~6GB) = 26GB — tight but achievable with memory optimization (`--gpu-memory-utilization 0.95`). This supports 2 concurrent agents (1 manager + 1 specialist) or sequential execution of 3-5 agents. [RTX 5090](/hardware/rtx-5090) 32GB comfortably fits 70B Q4 + 32B Q4 simultaneously — supports 2-3 concurrent agents. Dual [RTX 3090](/hardware/rtx-3090) (48GB total) fits 70B Q8 on one card, 32B Q8 on the other — 3-5 concurrent agents. **SMB ($6,000-$15,000).** [NVIDIA L40S](/hardware/nvidia-l40s) 48GB runs [Llama 3.3 70B](/models/llama-3-3-70b) FP8 (~35GB) + [Qwen 3 32B](/models/qwen-3-32b) FP16 (~12GB) simultaneously — 3-5 concurrent agents with [vLLM](/tools/vllm) serving both models on one card. Or: 2× [NVIDIA L40S](/hardware/nvidia-l40s) — card 1 runs 70B for manager + reasoning agents, card 2 runs 32B for specialist agents. This handles 5-10 concurrent agents for production multi-agent workloads. **Enterprise ($25,000+).** [NVIDIA H100 PCIe](/hardware/nvidia-h100-pcie) 80GB runs [DeepSeek V4](/models/deepseek-v4) FP8 for manager + 2-3 [Qwen 3 32B](/models/qwen-3-32b) FP16 instances simultaneously — 5+ concurrent agents at frontier quality. [NVIDIA H200](/hardware/nvidia-h200) 141GB handles DeepSeek V4 FP8 + 5+ specialist models with 128K context — 10-20 concurrent agents. For 20+ agent systems: GPU cluster with tensor-parallel serving of large models + pipeline-parallel serving of specialist pools. **Concurrent agent capacity planning.** N agents each calling LLM every T seconds (average think time between calls). GPU throughput: R requests/second. Required: N/T ≤ R. Example: 5 agents at 1 call/3 seconds = 1.67 req/s. [NVIDIA L40S](/hardware/nvidia-l40s) with [vLLM](/tools/vllm) handles ~20 req/s for 70B — capacity for 60 agents. In practice, agent think time is 5-30 seconds (web search, code execution, wait states), so GPU concurrency is rarely the bottleneck. The bottleneck is coordination logic and serial dependencies between agents.

Runtime guidance

**If using CrewAI for role-based multi-agent** → [Ollama](/tools/ollama) for local, [vLLM](/tools/vllm) for production. CrewAI's LLM abstraction supports any OpenAI-compatible endpoint. Define agents with specific roles + tools (SerperDevTool for web search, FileReadTool, CodeInterpreterTool). For hierarchical mode: set `manager_llm` to a stronger model ([DeepSeek V4](/models/deepseek-v4)) and agent `llm` to efficient models ([Qwen 3 32B](/models/qwen-3-32b)). CrewAI's process types: `sequential` (tasks execute in order, simpler), `hierarchical` (manager delegates, more capable but more tokens). **If using AutoGen for conversational multi-agent** → AutoGen 0.4+ supports local models via OpenAI-compatible endpoint. AutoGen's group chat pattern: N agents + 1 manager in a shared conversation. Each agent can see all messages and choose to respond. Works for collaborative tasks where agents need shared context. For nested chat: agent A delegates to agent B in a private sub-conversation, then A returns the result to the group — reduces noise in the main conversation. **If using LangGraph for state-machine multi-agent** → LangGraph subgraphs: each agent is a subgraph (nodes + edges). The main graph routes between agent subgraphs based on state. This is the most flexible (arbitrary routing logic in Python) but most code-heavy. Best for production systems where you need full control over agent communication patterns. Use [vLLM](/tools/vllm) as the LLM backend for all agent subgraphs. **If agents need shared memory** → [Qdrant](/tools/qdrant) or [pgvector](/tools/pgvector) for vector memory shared across agents. Each agent can write findings/decisions to shared memory; all agents can query it. Implement with [BGE-M3](/models/bge-m3) for embedding and [BGE Reranker V2 M3](/models/bge-reranker-v2-m3) for retrieval quality. Shared memory reduces redundant work (agent B doesn't re-research what agent A already found) but introduces the "poisoned memory" failure mode (an incorrect finding propagates). **If experimenting with multi-agent without infrastructure** → Run agents sequentially on a single [Ollama](/tools/ollama) instance. Agent A → wait for response → Agent B → wait → Agent C. Sequential execution is 3-5× slower than concurrent but requires no concurrency infrastructure. Use for prototyping multi-agent patterns; switch to concurrent [vLLM](/tools/vllm) serving when the pattern is validated.

Setup walkthrough

Install Ollama → ollama pull llama3.1:8b (~5 GB — works for agent roles that don't need coding).
pip install crewai (CrewAI — role-based multi-agent orchestration).
Define a multi-agent team:

from crewai import Agent, Task, Crew, Process
researcher = Agent(role="Market Researcher", goal="Find data on topic", llm="ollama/llama3.1:8b")
analyst = Agent(role="Data Analyst", goal="Analyze findings", llm="ollama/llama3.1:8b")
writer = Agent(role="Report Writer", goal="Write final report", llm="ollama/llama3.1:8b")

research_task = Task(description="Research the top 5 local AI hardware trends in 2026", agent=researcher)
analysis_task = Task(description="Analyze the research findings and identify key patterns", agent=analyst)
writing_task = Task(description="Write a 500-word executive summary with 3 key recommendations", agent=writer)

crew = Crew(agents=[researcher, analyst, writer], tasks=[research_task, analysis_task, writing_task], process=Process.sequential)
result = crew.kickoff()

Each agent runs its task, passes output to the next agent. A 3-agent pipeline completes in 1-3 minutes on 12 GB GPU.
For debate/consensus patterns: CrewAI supports hierarchical (manager delegates) and sequential (pipeline) processes.
Use cases: content creation pipelines, research synthesis, code review teams (reviewer + security auditor + style checker).

The cheap setup

Used RTX 3060 12 GB (~$200-250, see /hardware/rtx-3060-12gb). Runs CrewAI with 3-5 Llama 3.1 8B agents running sequentially. A typical 3-step pipeline completes in 1-3 minutes. For small teams automating content creation, research synthesis, or document review: $400 handles 20-50 pipeline runs/day. Pair with Ryzen 5 5600 + 16 GB DDR4 + 512 GB NVMe. Total: ~$360-405. Multi-agent systems are GPU-efficient — agents run sequentially (one GPU, one at a time) or in parallel on CPU for text-only roles.

The serious setup

Used RTX 3090 24 GB (~$700-900, see /hardware/rtx-3090). Runs CrewAI with 5-10 agents using Llama 3.3 70B Q4 for reasoning-heavy roles (analyst, strategist) and 8B models for simpler roles (researcher, formatter). For enterprise multi-agent systems (legal document review with 3 specialized agents, financial analysis with analyst + auditor + writer): the 70B model dramatically improves reasoning quality in complex agent roles. Total: ~$1,800-2,200. For parallel multi-agent execution: 2× RTX 3090 runs two 70B agents simultaneously.

Common beginner mistake

The mistake: Creating a 10-agent system where every agent is the same model with a different system prompt, expecting dramatically better output than a single agent. Why it fails: Same model + same knowledge cutoff + different prompt = the same agent in cosplay. The "researcher" and "analyst" both have identical knowledge and reasoning patterns — the "analyst" can't find insights the "researcher" couldn't. The output is just the same answer rewritten 3 times. The fix: Use different models for different roles. Researcher = 8B (fast, broad search). Analyst = 32B (deeper reasoning). Writer = 8B (fluent output). Different model architectures bring different strengths. Or: give agents access to different tools/data — the researcher has web search, the analyst has a database, the writer has style guides. Differentiated inputs + differentiated models = true multi-agent value. Same model + same data = one agent with extra steps.

Recommended setup for multi-agent systems

Recommended hardware

Best GPU for local AI →

All workloads ranked across VRAM tiers.

Recommended runtimes

Browse all tools for runtimes that fit this workload.

Budget build

AI PC under $1,000 →

Best GPU for this task

Best GPU for local AI →

Reality check

Local AI workloads have real hardware constraints that vary by task type. VRAM ceiling decides what model fits; bandwidth decides decode speed; compute decides prefill speed. Pick the GPU tier that fits your actual workload, not the spec sheet.

Common mistakes

Buying for spec-sheet VRAM without modeling KV cache + activation overhead
Underestimating quantization quality loss below Q4
Skipping flash-attention support (real perf gap on long context)
Ignoring sustained-load thermals (laptops thermal-throttle within 30 min)

What breaks first

The errors most operators hit when running multi-agent systems locally. Each links to a diagnose+fix walkthrough.

Before you buy

Verify your specific hardware can handle multi-agent systems before committing money.

Buyer guides

Compare hardware

Troubleshooting

Specialized buyer guides

Updated 2026 roundup

Best free local AI tools (2026) →