---
name: multi-agent-orchestration
title: Multi-Agent Orchestration
description: "Pattern for decomposing complex tasks into parallel agent work. Instead of one AI doing everything sequentially, break the work into independent streams that run simultaneously. Covers task decomposition, dependency mapping, agent briefing, result synthesis, and conflict resolution. Turns 4-hour sequential work into 30-minute parallel execution."
category: agent
tags:
  - agenci
  - równoległość
  - orkiestracja
  - workflow
  - produktywność
  - dekompozycja
source: https://madejski.ai/promptoteka/multi-agent-orchestration
locale: en
license: MIT
---

# Multi-Agent Orchestration

## The Core Idea

One agent doing everything sequentially is slow and error-prone. Multiple agents working in parallel are fast and self-checking.

The key insight: **most tasks have independent subtasks that can run simultaneously.** A feature implementation has research, scaffolding, tests, and docs — these can all start at the same time.

## Decomposition Framework

### Step 1: Map the work

List all subtasks. For each one ask:
- Can this start without waiting for another subtask?
- Does this need output from another subtask?
- Can two agents work on this without conflicts?

### Step 2: Build the dependency graph

```
[Research API docs] ──→ [Implement service layer]
                                ↓
[Write test fixtures] ──→ [Write integration tests]
                                ↓
[Scaffold UI components] ──→ [Wire UI to service] ──→ [E2E tests]
```

Independent roots can launch in parallel. Dependent nodes wait for their inputs.

### Step 3: Brief each agent

Every agent gets:
1. **What to do** — specific, scoped deliverable
2. **What NOT to do** — boundaries (don't touch files X, don't make decisions about Y)
3. **Context** — just enough to do their job, not the whole project history
4. **Output format** — what artifact to produce and where to put it
5. **Success criteria** — how to know when they're done

## Agent Roles

### Research Agent
- Reads docs, searches for patterns, evaluates libraries
- Output: structured findings document
- Never writes production code

### Builder Agent
- Implements features in a scoped area
- Gets a clear spec, produces working code
- Commits to a branch, doesn't merge

### Test Agent
- Writes tests from the spec (not from the implementation)
- TDD orientation: tests first, builder implements to pass
- Independent from builder to avoid confirmation bias

### Review Agent
- Reviews code from builder, findings from research
- Security, performance, correctness audit
- No implementation — findings only

### Doc Agent
- Updates documentation based on what was built
- Produces API docs, migration guides, changelogs

## Orchestration Patterns

### Pattern 1: Fan-out / Fan-in
Launch N agents in parallel, collect results, synthesize.
```
Orchestrator → [Agent 1, Agent 2, Agent 3] → Collect → Synthesize → Output
```
Best for: research, code review, multi-file changes.

### Pattern 2: Pipeline
Each agent processes and passes to the next.
```
Research → Spec → Build → Test → Review → Deploy
```
Best for: sequential workflows where each step needs prior output.

### Pattern 3: Split-role Critique
Same input, different perspectives. Compare and reconcile.
```
Input → [Security reviewer, Performance reviewer, UX reviewer] → Reconcile conflicts
```
Best for: complex decisions needing multiple viewpoints.

### Pattern 4: Builder + Watcher
One agent builds, another watches in real-time (see: Dual-Thread Development prompt).

## Briefing Template

```markdown
## Agent Brief: {role}

**Mission:** {one sentence — what you're delivering}

**Scope:**
- DO: {specific tasks}
- DON'T: {boundaries}

**Input:** {what you're given to start}
**Output:** {exact deliverable, format, location}

**Context:**
{just enough background — 3-5 sentences max}

**Done when:**
- [ ] {criterion 1}
- [ ] {criterion 2}
```

## Conflict Resolution

When agents produce conflicting outputs:
1. **Fact conflicts** — verify against source, pick the correct one
2. **Opinion conflicts** — compare reasoning, pick the better-argued one
3. **Scope conflicts** — agents overlapped; merge non-conflicting parts, decide overlapping parts
4. **Style conflicts** — pick the one consistent with existing codebase

## Anti-Patterns

- Launching agents without clear scope boundaries (they'll duplicate work)
- Giving every agent full project context (wastes tokens, causes confusion)
- Not defining output format (you'll spend more time parsing results than the agents saved)
- Over-decomposing simple tasks (orchestration overhead exceeds the work itself)
- Ignoring dependencies (agent B needs agent A's output but both launched simultaneously)