Multi-Agent Systems
How to build AI teams: orchestrator + specialists, parallel vs. sequential agents, and real-world patterns from AGINE.
Multi-Agent Systems
An agent is Claude with access to tools and a clearly defined role. When a task is too big for a single context or needs parallel work, an orchestrator spins up specialists. Here's how it all fits together.
Who this guide is for
This one is about Claude Code, the terminal tool (claude.ai/code). Agents are launched via the Task tool inside a session. If you're just getting started, check out Claude Code features or the 10-step setup first.
What an agent is
Role + tools + isolated context.
Role A clearly scoped job: "you're a code-reviewer, you check only security and style." Not "do everything."
Tools MCP servers, bash, the file system: exactly what this particular agent needs. Not the entire stack at once.
Isolation The agent works in its own context. It doesn't pollute the main one. It returns only a summary of its results.
# Why agents instead of one giant prompt
- → Parallelism: code-architect and code-explorer work at the same time. The speed of one, the depth of two.
- → Specialization: an agent with a "security reviewer" role finds vulnerabilities better than "take a general look at the code."
- → Context under control: each agent carries only its own context. The main agent doesn't balloon from intermediate results.
- → Independent verification: different agents can check the same solution from different angles, free of first-answer bias.
4 core patterns
Every system is a combination of these four.
Orchestrator + Specialists
``
Orchestrator
├── Specialist A (parallel)
├── Specialist B (parallel)
└── Specialist C (parallel)
↓ summary x3
Orchestrator synthesizes → result
``
When: the go-to pattern for most tasks. One agent hands out the work and collects the results.
Example: /feature-dev: the orchestrator runs code-architect + code-explorer in parallel, then code-reviewer.
Each specialist sees only its own task and knows nothing about the others. The orchestrator synthesizes everything.
Pipeline (sequential)
``
Agent A
↓ output A
Agent B (receives output A)
↓ output B
Agent C (receives output B)
↓ final result
``
When: each step depends on the previous one. Can't be parallelized.
Example: /smm: trend-researcher → content-writer → art-director → publisher. Each one picks up where the previous left off.
A pipeline is slower than parallel work, but there's no way around it when output A = input B.
Verifier (double-checking)
``
Writer Agent
↓ draft
Reviewer Agent (independent)
↓ feedback
Writer Agent (final pass)
↓ result
``
When: critical tasks where the first draft can't ship without review. Security, finance, public-facing content.
Example: Generate documentation → an independent reviewer checks it for accuracy → the writer applies fixes.
The reviewer doesn't see the process, only the result. That sidesteps the orchestrator's confirmation bias.
Fan-out (bulk processing)
``
Orchestrator
├── Agent(item_1) ─→ result_1
├── Agent(item_2) ─→ result_2
├── Agent(item_3) ─→ result_3
└── Agent(item_N) ─→ result_N
↓
Orchestrator aggregates
``
When: the same type of task applied to many items. Translation, refactoring N files, generating content for N platforms.
Example: Localizing into 5 languages: 5 agents in parallel, each one takes the original and translates it.
The biggest speed win of all. N tasks in the time of one.
How we use this at AGINE
Real chains, not theory.
/smm: Pipeline
trend-researcher → content-writer → art-director → publisher
Why this way: Content can't be parallelized: you pick the topic before writing, and the visuals come after the text.
/feature-dev: Orchestrator + Specialists
code-architect + code-explorer (parallel) → code-reviewer
Why this way: Architecture and code exploration can happen at the same time. Review only comes once the code is written.
/review: Fan-out
security-agent + performance-agent + style-agent (parallel)
Why this way: The three review angles are independent. No point waiting on security results before style.
Explore agent: Orchestrator + Specialist
main → Explore(codebase search) → main gets a summary
Why this way: Code search is isolated in a subagent, so it doesn't clog the main context with massive grep output.
How to build your own system
Five questions before you start.
01. What do you repeat every day? Start with a task you do by hand on a regular basis. Agents = ROI only on repetitive tasks.
02. Do the steps depend on each other? Yes → Pipeline. No → Fan-out or Orchestrator+Specialists. This determines the architecture.
03. Do you need an independent check? For critical output (publishing, deploys, finance), add a Verifier agent. It hasn't seen the process, so it's unbiased.
04. What does each agent need to know? The minimum context. Don't hand the entire project's code to an agent that only checks one file.
05. How does the orchestrator get the result back? Every subagent returns only a summary, not its full context. Otherwise the main context balloons.