Single-Agent vs Multi-Agent: Decide and Design
A decision flow for the most expensive architecture choice in agent systems - grounded in what actually ships versus what demos well.
The route
4 steps to Done
- 01
Analyze the workload for separability
The architecture question is really a workload question.
Preview prompt + verify gate ▾ Hide ▴
Analyze my agent workload before choosing an architecture. Answer in writing: (1) Can the work be split into subtasks that do NOT need to share intermediate state? (2) Do subtasks need different tool sets or different permission levels? (3) Is there a natural review/producer split where one context should not contaminate the other? (4) What are my latency and cost budgets per task? (5) What is the blast radius if two workers act on stale views of shared state? Produce a one-page workload profile with these answers and concrete examples from my actual use case: [DESCRIBE YOUR USE CASE].
- ✓ All five questions answered with specifics
- ✓ Shared-state needs are named explicitly
- ✓ Budgets are numbers, not adjectives
- 02
Score the three architectures
Make the trade-offs visible before intuition locks in.
Preview prompt + verify gate ▾ Hide ▴
Build a decision matrix scoring three architectures against my workload profile: (A) single-loop agent with tools; (B) single main agent with dispatched sub-agents for bounded research/review tasks; (C) full multi-agent with peer roles and message passing. Score each 1-5 on: implementation complexity, debuggability, context efficiency, failure containment, latency, cost, and fit to my separability answers. Research context to apply: production coding agents overwhelmingly ship as (A) or (B); (C) earns its cost when subtasks are truly independent (pipelines, simulations, review boards). Show the scored matrix and declare a winner with a two-sentence justification.
- ✓ All 21 cells scored with reasons
- ✓ Debuggability and failure containment included
- ✓ Winner follows from scores, not vibes
- 03
Sketch the chosen architecture
A design you can draw is a design you can build and debug.
Preview prompt + verify gate ▾ Hide ▴
Produce the architecture sketch for the winning option. Must include: components (agents, tools, stores), the exact communication paths (who sends what to whom, in what format), where state lives and who owns writes, the failure story for each component (timeout, garbage output, crash), and the observability plan (transcripts, correlation IDs across agents). If multi-agent: define the coordination protocol precisely - task handoff format, acknowledgment, and what a supervisor does when a worker stalls. Keep it to one diagram plus one page of notes.
- ✓ Every arrow has a message format
- ✓ State ownership is single-writer
- ✓ Each component has a failure story
- 04
Define revisit triggers and validate cheaply
Architectures are bets - set the tripwires that tell you the bet went bad.
Preview prompt + verify gate ▾ Hide ▴
Finish the decision responsibly. (1) Define revisit triggers: measurable conditions under which I would re-run this decision (e.g. context regularly exceeding 70% budget, task mix shifting to parallel-friendly work, quality plateau attributable to context contamination). (2) Design the cheapest possible validation: a one-day spike implementing the riskiest interaction in the chosen design (for sub-agents: dispatch and report; for multi-agent: one full handoff with a failure injected). (3) Run the spike and record whether the design survived contact. Document triggers and spike results at the bottom of the architecture doc.
- ✓ Triggers are measurable, not moods
- ✓ Spike targeted the riskiest interaction
- ✓ Spike result recorded honestly
Research-backed
Sources behind this flow
Tier 2 · harness-engineering
ai-coding-agent-open-source-analysis
A comparative research repository on AI coding agents, full-source scanning, spec-driven development, and LLM wiki/RAG trends, with analysis reports, category READMEs, CSV tables, and a data/source-inventory.json cataloging the analyzed agents. Useful as the index that cross-references the Tier 4 agents.
Tier 4 · coding-agents
CrewAI
A popular multi-agent orchestration framework organized around role-playing crews: agents with roles, goals, and tools collaborating through defined tasks and processes.
Tier 4 · coding-agents
AutoGen
Microsoft's multi-agent framework built on conversational agents: agents (and humans) converse to solve tasks, with group chats, tool use, and code execution woven into the conversation model.
Tier 4 · coding-agents
MetaGPT
The multi-agent 'software company' framework: SOPs encoded as agent roles (PM, architect, engineer, QA) that transform one-line requirements into specs, designs, and code.
Tier 4 · coding-agents
ChatDev
A virtual software company of communicating agents organized in a waterfall of chat chains (design, coding, testing, documentation) - a research-grade study of communicative multi-agent software development.
Tier 4 · coding-agents
LangGraph
LangChain's low-level orchestration framework modeling agents as stateful graphs: nodes, edges, checkpoints, and human-in-the-loop interrupts - the infrastructure layer many production agents standardize on.
Tier 6 · agent-research
DyLAN
Official implementation of Dynamic LLM-Agent Network (paper): agent-team collaboration where the network topology and team composition are optimized dynamically per task.
Tier 6 · agent-research
agentUniverse
A multi-agent framework (from Ant Group) centered on domain-expertise patterns: PEER (plan/execute/express/review) and DOE collaboration modes proven in financial-industry deployments.
Tier 1 · claude-code-internals
Deep Dive: Multi-Agent Dispatch - Spawn, Fork, Direct
Source-level analysis of the three ways Claude Code dispatches work: Spawn (a named sub-agent with a fresh context, its own tool pool, permission mode, and model), Fork (a synthetic agent that inherits the parent conversation byte-for-byte so parallel workers share the prompt cache), and Direct (the main agent just does the task itself). Covers sync-to-background promotion via a promise race, recursion guards on forking, git-worktree isolation, and a decision matrix for picking a strategy per task.