# Process 2 — agent orchestration

> **What you will learn**
> How role-separated agents collaborate, and why transplanting a human team
> structure is a mistake.

## Split the roles

One agent does not do everything. Roles are separated.

| Agent | Responsibility |
|---|---|
| **Architect** | designs the system structure and the scope of change |
| **Coder** | writes the implementation |
| **Reviewer** | inspects from a security and quality perspective |

## Why split at all

You could have one agent do everything. Three reasons not to.

### 1. Context stays clean

Each sees only what its own job needs. The architect sees the overall structure;
the coder sees the part it is building.
[The context filling up](/guide/ai-context-overflow) is mitigated.

### 2. Perspectives separate

When the same agent builds and reviews, it looks **in a direction that defends
its own decisions.** Making review a separate role means looking without taking
the build as a given.

### 3. Parallelism becomes possible

This is the biggest difference from a human team.

## Do not transplant the human hierarchy

A common misconception:

```
✗ Wrong model: junior builds → senior reviews → lead approves
   (sequential; each waits for the previous)

✓ Hyper-agile: the roles run concurrently
```

Review **does not wait** for coding to finish. Review goes in as parts emerge,
and problems found are reflected immediately.

```mermaid
graph TD
  S["Specification"] --> A["Architect: design the structure"]
  A --> C["Coder: implement"]
  A --> R["Reviewer: review the design"]
  C --> R2["Reviewer: review the implementation"]
  R -.->|"problem found"| A
  R2 -.->|"problem found"| C
  C --> T["To the validation phase"]
```

The dotted lines are **return paths.** This is not a sequential pipeline but a
back-and-forth structure.

## A shared workspace

The agents look at **the same workspace.** Handover documents existed in human
teams because each person worked somewhere else; in this structure that cost is
gone.

| | Human team | Agents |
|---|---|---|
| Passing information | moved via documents and meetings | they see the same space |
| Loss in transfer | yes | none |
| Async collaboration | difficult | the default |

## Where the human is

There are two points of human intervention in this phase.

1. **When the design direction diverges from the specification** — if the
   architect's decision differs from the intent, you catch it
2. **Irreversible decisions** — schema changes, external contract changes

Otherwise you watch and look at the result.

## What to watch in practice

### Do not split into too many agents

The more roles you add, **the more coordination cost comes back.** You would be
reviving in your agent setup exactly the problem you removed from the human
team. Three or four roles is usually enough.

### Tell the reviewer agent what to look at

"Review this" alone produces generic remarks. Narrow it to be useful:

```
Review perspective:
  □ are all four rules from the specification implemented
  □ is input validation missing anywhere
  □ did it touch the existing payment logic (it must not)
  □ does it follow our code conventions (attached)
```

---

## Check yourself

**1. What are the three reasons to split roles?**

<details>
<summary>Answer</summary>

**Context stays clean, perspectives separate, and parallelism becomes possible.**
The second especially — when the same agent builds and reviews, it looks in a
direction that defends its own decisions.
</details>

**2. Why should you not transplant a human team's hierarchy?**

<details>
<summary>Answer</summary>

**Because it becomes sequential and creates waiting.** Review should not wait for
coding to finish; it should go in concurrently as parts emerge.
</details>

**3. What goes wrong if you keep adding agent roles?**

<details>
<summary>Answer</summary>

**Coordination cost comes back.** You would be reviving the very problem you
removed from the human team, so three or four roles is usually enough.
</details>

---

The phase that judges whether what was built is right →
[Process 3 — automatic validation](/guide/ha-phase3-validation)