Six agents, each with a name, a job and a model
I started with 14 agents and cut the team to six roles. Only one reviews requests to change code.
On July 14, I rolled out a group of 14 agents from my assistant, JARVIS. In Claude Code (a tool for working with code), they were mirrored as 13 subagents (helpers that take specific tasks). Eight days later, on July 22, I started cutting that group down to six.
The part of Claude Code that carries out tasks ended up with six roles. Each has a name, one responsibility, and a fixed AI model. Only one reviews PRs (requests to review and include code changes).
The six that stayed
The Claude Code execution layer has these roles. VULCAN leads work on the server. LUMEN leads the client side and the interface. SENTINEL handles quality, reviews, and tests. MNEMOSYNE handles documentation and knowledge. NEXUS handles supporting systems, security, and reliability. APOLLO is the advisory technical lead.
APOLLO stays outside PR review on purpose. I call it when I suspect the model made something up or when work starts to drift. I also call it when two pieces of evidence contradict each other or an architecture decision comes up. It advises, but approves nothing.
PROMETHEUS, who led AI engineering, left execution. Its work moved to the main loop, the session I am talking in.
The names changed a month before the cut. On June 22, when I redesigned the roles, AEGIS became NEXUS and THEMIS became SENTINEL. Registry v3 came out the next day. The cut to six agents happened only on July 22, with registry v3.1. Those were two separate steps. In my view, a name that still describes the old role makes you call the wrong agent without noticing.
Each role has a model
The AI model (a program that carries out a task) is part of the agent's definition. It is not something I choose when I delegate. The planning and heavier review roles, APOLLO, MNEMOSYNE, and SENTINEL, use Opus. The implementation roles, VULCAN, LUMEN, and NEXUS, use Sonnet. The search and reading helpers use Haiku. That is three agents in each of the two larger tiers.
The main session distributes tasks. It reads the request, chooses the needed tier, and delegates. It handles simple reading itself. Starting a subagent to read a file usually costs more than reading the file.
I rarely ask which model to use. Now I ask which role fits. I can tell by looking at the task.
One name, one responsibility
I think a name tied to one responsibility makes it clear who should fix a problem. If the system returns the wrong field, the question already has a destination: VULCAN. If the screen breaks on a phone, it is LUMEN. When several agents have similar roles, it is less clear where to take the problem.
A job that fits in one line is also easier to write and maintain. If an agent's description needs two lines, it is probably two roles. A role costs more to place at its boundary with its neighbors than to define by itself.
One reviewer
SENTINEL is the only PR reviewer. That avoids one possible failure: two reviewers each assuming the other checked the hard part. With one reviewer, someone owns the check.
The cost is concentrating everything in one place. If SENTINEL has a blind spot, every PR goes through it. I prefer that risk to the other one. A single blind spot can be fixed in one place. Split responsibility is harder to locate.
If the number grows again, I will ask one question before adding an agent. Which responsibility will it take from someone?