What you will learn How role-separated agents collaborate, and why transplanting a human team structure is a mistake.
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 |
You could have one agent do everything. Three reasons not to.
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.
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.
This is the biggest difference from a human team.
A common misconception:
Review does not wait for coding to finish. Review goes in as parts emerge, and problems found are reflected immediately.
HyperTeamsgraph 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.
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 |
There are two points of human intervention in this phase.
Otherwise you watch and look at the result.
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.
"Review this" alone produces generic remarks. Narrow it to be useful:
1. What are the three reasons to split roles?
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?
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?
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
✗ Wrong model: junior builds → senior reviews → lead approves (sequential; each waits for the previous)✓ Hyper-agile: the roles run concurrentlyReview 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)