Learning AI-DLC building a game, part 15: the agents and roles
This is part 15 of a series on learning AI-DLC by building a game, World Rift Conflict, in Godot with an AWS backend. Part 1 set it up, and part 14 covered how AI-DLC remembers. This one is about who does the work: AI-DLC's agents.
Parts so far:
- Part 1: setup
- Part 2: a proof of concept
- Part 3: automated E2E tests
- Part 4: what the reviews caught
- Part 5: inside a stage
- Part 6: a bugfix intent
- Part 7: ideation
- Part 8: inception
- Part 9: an AppSync deploy error
- Part 10: walking skeleton
- Part 11: retrospective
- Part 12: guards and hooks
- Part 13: a UI pass and a release
- Part 14: the memory layers
- Part 15: the agents and roles (this post)
TL;DR
- AI-DLC ships 14 agents: 11 experts that do the work, 2 reviewers that only challenge it, and a composer that plans workflows.
- Most of the time they are roles, not separate agents. 29 of the 33 stages run "inline": the main session takes on the lead role and the support roles itself.
- Separate agents run in four stages, in reviews, and for the composer. In this project that was 193 hand-offs. 94 went to the architecture reviewer and 64 to the developer.
- The reviewers gave 80 READY and 25 NOT-READY verdicts. They run on a smaller model than the session, and still caught a production risk and a design gap the stage had missed.
- The multi-agent ensembles never ran here. Every scope I used has
collaborators: off, so each delegated stage ran its lead alone.
Fourteen agents
Each agent is one Markdown file in .claude/agents/, with a role description and its own folder of reference notes in .claude/knowledge/. The architect's folder has an ADR template and domain-driven design patterns, for example, and the quality agent's has test-strategy patterns.
| Group | Agents | What they do |
|---|---|---|
| Experts (11) | product, design, delivery, architect, aws-platform, compliance, devsecops, developer, quality, pipeline-deploy, operations | lead or support the stages |
| Reviewers (2) | product-lead, architecture-reviewer | "Does not produce — only reviews and challenges." |
| Composer (1) | composer | sizes a task and proposes the smallest workflow for it |
Every stage names one lead and up to three supports. A few examples from the stage graph:
| Stage | Lead | Supports |
|---|---|---|
| Intent Capture | product | architect |
| Feasibility | architect | aws-platform, compliance |
| Practices Discovery | pipeline-deploy | quality, developer, devsecops |
| User Stories | product | design, developer, quality |
| Code Generation | developer | none |
| Build and Test | quality | devsecops |
The architect leads the most: seven stages, from Feasibility to NFR Design. Compliance leads none. It is support-only.
No agent can start another one. All 14 files block the Task tool, and the framework puts it plainly: "Agents do NOT invoke each other — only the orchestrator delegates." The orchestrator is the main session that runs /aidlc.
Roles, not processes
The stage graph gives every stage a mode. 29 of the 33 stages are inline, where "the conductor adopts every voice, zero dispatches". The main session works the stage as the lead, then adds each support role's view, then brings them together. The stage file says it directly: "Take on lead_persona: you work the stage as that agent." And: "Do NOT dispatch a support agent on an inline stage."
So when the build log says "the product agent wrote the requirements", no separate agent ran. My session read the product agent's file and knowledge, and wrote as that role.
Four stages hand the work to separate agents, in one of three shapes:
| Stage | Mode | Shape |
|---|---|---|
| Reverse Engineering | pipeline | a chain: the developer scans the code, the architect writes the knowledge base, each link seeing all upstream work |
| Practices Discovery | subagent | hub and spoke: the lead drafts, each support reviews blind, the lead integrates |
| User Stories | mob | "one room, cross-talk, dissent recorded" |
| Code Generation | subagent | the developer builds the unit |
Reviews and the composer are separate agents too. A reviewer is "a separate sub-agent" that reads what the stage produced and writes one file with its verdict.
What actually ran here
Counted from the audit of all six pieces of work: 193 completed hand-offs to separate agents.
| Agent | Hand-offs |
|---|---|
| architecture-reviewer | 94 |
| developer | 64 |
| product-lead | 14 |
| pipeline-deploy | 6 |
| other or unrecorded | 15 |
The developer's 64 are mostly Code Generation, one per unit and more when a build ran out of room. The pipeline-deploy agent's 6 are Practices Discovery. No composer hand-off appears in the audit.
The bigger finding is what did not run. Every scope I used, poc, bugfix, mvp and classic, sets collaborators: off. Only enterprise turns it on. With it off, "the lead runs alone, on every topology". So:
- Reverse Engineering ran as a one-link chain. All five completed links are the developer agent's. The architect never added its part. "The developer agent both scanned and wrote the nine knowledge base files."
- Practices Discovery had the lead and no blind reviews by the quality, developer and security agents.
- User Stories had no mob round. One of the learnings options AI-DLC offered at that stage was literally "Mob round did not run with collaborators off".
I did not choose that. It came with the scopes, and I only found it while writing this post.
The reviewers
The reviewers are the part that did run, and often. They gave 105 verdicts here:
| Reviewer | READY | NOT-READY |
|---|---|---|
| architecture-reviewer | 69 | 22 |
| product-lead | 11 | 3 |
A reviewer is told to "Refute, don't confirm": READY is "the verdict it fails to reach after trying to break the artifact". A finding "backed only by opinion is a suggestion, not grounds for NOT-READY". Requirements and design stages get one advisory pass. The per-unit design stages in Construction get an adversarial loop of up to two passes. A reviewer of one unit may not read other units' files.
Some NOT-READY verdicts, from the review files:
- The end-to-end test kit's design: no step checked that a test build's user pool was the test pool before launch, "so a stale export pointing at production could run". The same review found three jobs that no component owned, which became a project rule.
- The game's user stories: "The walking-skeleton boundary does not hold together." A skeleton story depended on a story outside the skeleton.
- A UI unit's design: setting a slider's value in code fires its change signal again, "which would rebalance recursively".
Both reviewers are pinned to model: sonnet with effort: medium. The other 12 agents inherit my session's model, which the setup entry of my build log records as Claude Opus 5.5. So a smaller model checked a larger one's work, and in the game build the two reviewers sent back 22 of 43 first passes.
Friction
- A spend limit stopped an agent mid-draft. The fix became a project rule: "resume that same agent after the person says to continue, instead of starting a new one, so its work so far is kept."
- A 45-task build outgrew one agent. It stopped on a credit limit, then again at task 29 to stay within its context. A fresh agent, briefed with the first one's handover notes, finished the rest.
- Agents only know their own folders. They read
.claude/knowledge/, not the Godot skills I had installed. Those reached them through a section in the rootCLAUDE.mdand a project rule. - A reviewer can be wrong in its details. NOT-READY is not always right. I accepted some findings as open instead of fixing them, and later stages picked them up.
What I would tell myself
- Check
collaboratorsin your scope. If you want the ensembles, the blind support reviews and the mob round, pick a scope that turns them on, or change the setting. Expect more hand-offs and more cost. - Read "the architect did X" as "the session, as the architect". Only the four delegated stages and the reviews run as separate agents.
- Keep the reviewers. A second look from a different model, told to break the work, sent back half of the game's first review passes, with real problems in them.
- Know which model each agent uses.
aidlc config models --showprints it. Here, reviewers on Sonnet and everyone else on whatever the session runs.
What is next
More deep-dives from the same records until the next piece of work starts. The next one in the backlog is scopes and the composer: how AI-DLC picks which stages run.