HyperTeamsProcess 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 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:
Review does not wait for coding to finish. Review goes in as parts emerge, and problems found are reflected immediately.
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.
- When the design direction diverges from the specification — if the architect's decision differs from the intent, you catch it
- 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:
Check yourself
1. What are the three reasons to split roles?
Answer
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.
2. Why should you not transplant a human team's hierarchy?
Answer
Because it becomes sequential and creates waiting. Review should not wait for coding to finish; it should go in concurrently as parts emerge.
3. What goes wrong if you keep adding agent roles?
Answer
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.
The phase that judges whether what was built is right → Process 3 — automatic validation