Building an AI Dev Team: Hierarchical Multi-Agent Orchestration
Problem
A single coding agent hits a ceiling on larger work: it either burns its context on file exploration and mechanical edits, or it loses the high-level goal while deep in implementation. I also had no consistent way to verify an agent's own claim that a task was finished, so 'done' often meant 'probably done.'
Trial
I built a role-based agent company running across two CLIs simultaneously. A team-lead agent on Claude owns goals, decomposes work into task files, and performs final review; a manager agent on Codex dispatches implementation tasks and verifies the results; specialized workers run on different model tiers, with max-reasoning models reserved for hard problems and faster models handling boilerplate and QA. A natural-language trigger phrase activates the whole protocol, and dispatch, status, and review scripts move task files and worker reports up the chain.
Result
Work that used to serialize through one context now runs in parallel lanes, and each layer only carries the information it needs: the lead sees conclusions and diffs, not file dumps. Because workers must report to the manager and the manager must verify before the lead accepts, completion claims are now backed by at least one independent confirmation pass. The trigger-phrase protocol made the setup repeatable rather than a one-off arrangement I had to rebuild per session.
Lessons
The leverage comes from the reporting structure, not from adding more agents: an unverified worker report is worth little, while a manager-confirmed one is actionable. Matching model tier to task difficulty also matters as much as the org chart, since routing boilerplate to a frontier model wastes money and routing hard debugging to a fast model wastes time.
Next Action
I want to persist per-role performance history so the dispatcher can learn which task types each worker tier actually handles well, instead of relying on my static routing rules.