AI-DLC ships 14 agent personas: 11 domain experts that execute stage work, 2 review-only agents, and the adaptive-workflows composer. This chapter explains the full roster, beginning with the domain agents and then covering the reviewers and composer.
Rather than dozens of narrow specialists (which recreates waterfall handoff chains), AI-DLC uses 11 broadly capable agents that each participate across multiple stages and phases.
In human software teams, a mob of 3-5 people covers an entire feature from requirements through deployment. Each person brings a broad skill set spanning several specialties. AI-DLC mirrors this model:
-
Each agent covers a whole domain across many tasks. The aidlc-architect-agent handles feasibility, domain design, units generation, contract design, functional design, NFR requirements, and NFR design — seven stages across three phases. A narrow specialist model would require seven separate agents with nearly identical knowledge bases.
-
Fewer agents means fewer handoffs. Every agent boundary is a potential information loss point. When the same aidlc-architect-agent leads both Domain Design and Functional Design, it retains context naturally instead of requiring an explicit handoff artifact.
-
Support roles enable collaboration without proliferation. Rather than creating a "security-reviewer-agent" and a "compliance-reviewer-agent" and a "cost-reviewer-agent," the aidlc-devsecops-agent and aidlc-compliance-agent participate as support agents in stages led by others. HOW they participate is the stage's
mode— its communication topology: on aninlinestage the conductor adopts each support agent as a persona in its own context; onsubagent(hub-and-spoke) andmob(mesh) stages each support agent is dispatched as a real, independent collaborator that writes its own contribution file for the lead to integrate (everyone writes, the lead owns the final artifacts; user-stories ships as the mob showcase), and onpipeline(chain) stages the links advance the artifacts directly in sequence and each return is recorded as ordered completion evidence (reverse-engineering is the shipped chain). On every topology the conductor performs every delegation — agents never invoke each other. -
Knowledge loading is per-agent. Each agent loads methodology knowledge from
.claude/knowledge/<agent-name>/and team knowledge from the space-levelaidlc/spaces/<space>/knowledge/<agent-name>/(if the team created it). Fewer agents means fewer knowledge directories to manage and fewer opportunities for contradictory guidance.
The following diagram shows how agents exchange information during a workflow. Solid arrows indicate primary artifact flows. Dashed arrows indicate advisory or review relationships. The operations-to-product feedback loop closes the full lifecycle.
flowchart TD
ORCH(["SKILL.md (Conductor)"])
PA["aidlc-product-agent\n(Product Manager)"]
DA["aidlc-design-agent\n(UX Designer)"]
DLA["aidlc-delivery-agent\n(Delivery Manager)"]
AA["aidlc-architect-agent\n(Solutions Architect)"]
AWSA["aidlc-aws-platform-agent\n(AWS Platform)"]
CA["aidlc-compliance-agent\n(Compliance)"]
DSA["aidlc-devsecops-agent\n(DevSecOps)"]
DEVA["aidlc-developer-agent\n(Developer)"]
QA["aidlc-quality-agent\n(QA Engineer)"]
PDA["aidlc-pipeline-deploy-agent\n(Pipeline & Deploy)"]
OA["aidlc-operations-agent\n(SRE)"]
ORCH -->|delegates| PA
ORCH -->|delegates| DA
ORCH -->|delegates| DLA
ORCH -->|delegates| AA
ORCH -->|delegates| AWSA
ORCH -->|delegates| CA
ORCH -->|delegates| DSA
ORCH -->|delegates| DEVA
ORCH -->|delegates| QA
ORCH -->|delegates| PDA
ORCH -->|delegates| OA
PA -->|"requirements,\nstories, scope"| AA
PA -->|"intent, scope"| DA
PA -->|"prioritized backlog"| DLA
AA -->|"architecture,\nunit specs"| DEVA
AA -->|"NFR targets"| QA
AA -->|"infra requirements"| AWSA
DA -->|"mockups, UX specs"| DEVA
DEVA -->|"code scan"| AA
DEVA -->|"code artifacts"| QA
QA -->|"test results,\nbug reports"| DEVA
AWSA -->|"provisioned infra"| PDA
DSA -->|"security review"| DEVA
DSA -->|"security tests"| QA
PDA -->|"deployed services"| OA
CA -->|"compliance constraints"| AA
DLA -->|"delivery plan"| DEVA
OA ==>|"feedback loop:\noperational insights"| PA
style ORCH fill:#e1bee7,stroke:#7b1fa2,color:#000
style PA fill:#c8e6c9,stroke:#388e3c,color:#000
style OA fill:#fce4ec,stroke:#c62828,color:#000
style DEVA fill:#fff3e0,stroke:#e65100,color:#000
style AA fill:#bbdefb,stroke:#1565c0,color:#000
Customizing what a shipped agent knows? Do not edit the 14 shipped agent files at
.claude/agents/*.md: they're framework files and get overwritten on upgrade. Add your company standards to the space-levelaidlc/spaces/<space>/knowledge/<agent-name>/instead. See Knowledge for the full workflow. Teams that want a new agent can drop a file at.claude/agents/<slug>.mdwith the required frontmatter; that file is user-owned. See Contributing: Adding an Agent. Your harness's own subagents can live in the same directory: a file with none of AI-DLC's persona keys (display_name,examples,tier,plugin) and noaidlc-prefix is left to the harness, andaidlc doctor --verboselists it as an advisory.
Each agent below has a deep-dive page — its full responsibilities, the stages it leads and supports, and the knowledge it loads. The agent deep-dive index lists all 11; the per-agent links are inline under each heading.
Domain: Requirements, user stories, scope, market research
The aidlc-product-agent acts as the product manager and business analyst. It captures intent, conducts market research, defines scope, elicits requirements, and produces user stories. It is the most active agent in the Ideation and Inception phases.
- Leads: intent-capture, market-research, scope-definition, requirements-analysis, user-stories
- Supports: rough-mockups, approval-handoff, refined-mockups
- Special tools: WebSearch (for market research)
Domain: UX/UI design, wireframes, interaction design, accessibility
The aidlc-design-agent creates wireframes, mockups, and interaction specifications. It works closely with the aidlc-product-agent on user-facing features and with the aidlc-developer-agent to ensure designs are implementable.
- Leads: rough-mockups, refined-mockups
- Supports: user-stories, domain-design
- Special tools: WebSearch (for design research)
Domain: Team formation, capacity planning, delivery sequencing
The aidlc-delivery-agent acts as the engineering manager. It assesses team capacity, forms the mob composition, plans delivery sequencing, and manages phase handoffs.
- Leads: team-formation, approval-handoff, delivery-planning
- Supports: scope-definition, units-generation
- Special tools: None beyond the shared set
Domain: Domain design, domain modelling, NFRs, component decomposition
The aidlc-architect-agent is the central design authority. It has the broadest stage involvement (10 stages across 3 phases) and carries the judgment tier, alongside seven other high-judgment agents (product, design, developer, quality, devsecops, compliance, aws-platform). With no recorded model policy, judgment agents inherit your session's model and effort. Delivery, pipeline-deploy, and operations carry the templated tier because their output is dominantly planning, CI/CD YAML, and runbook scaffolding; their shipped baseline also inherits. The reviewer tier uses Sonnet at medium effort on Claude Code; on Codex and opencode it inherits the session model and applies medium reasoning effort. The wizard-default balanced preset is an explicit effort override for all three groups, setting each to medium without changing models. On Kiro CLI it sets one effort for the whole interactive session; Kiro IDE, Cursor, and Copilot cannot express those group effort dials, so the wizard records no preset there. See Model Policy.
- Leads: feasibility, domain-design, units-generation, contract-design, functional-design, nfr-requirements, nfr-design
- Supports: intent-capture, reverse-engineering (synthesis), delivery-planning
Domain: AWS infrastructure, CDK/CloudFormation, cost optimization
The aidlc-aws-platform-agent designs infrastructure, provisions environments, and optimizes costs. It has Bash access for running AWS CLI and CDK commands.
- Leads: infrastructure-design, environment-provisioning
- Supports: feasibility, domain-design, contract-design, nfr-design, feedback-optimization
- Special tools: Bash (for
aws,cdkcommands)
Domain: Regulatory scanning, data classification, risk assessment
The aidlc-compliance-agent operates purely in an advisory capacity — it has no lead stages. It feeds regulatory constraints into stages led by other agents, particularly the aidlc-architect-agent and aidlc-devsecops-agent.
- Leads: None (support only)
- Supports: feasibility, nfr-requirements, infrastructure-design, environment-provisioning
- Special tools: WebSearch (for regulatory research)
Domain: Threat modelling, security scanning, DevSecOps pipelines
The aidlc-devsecops-agent reviews designs for security, defines security requirements, and integrates security into CI/CD pipelines. Like the aidlc-compliance-agent, it operates in a support role.
- Leads: None (support only)
- Supports: practices-discovery, nfr-requirements, infrastructure-design, build-and-test, environment-provisioning
- Special tools: Bash (for security scanning)
Domain: Code implementation, code analysis, data modelling
The aidlc-developer-agent spans three phases — from reverse engineering in Inception through deployment support in Operation. It runs code scans of existing codebases and generates implementation code.
- Leads: reverse-engineering (code scan), code-generation
- Supports: practices-discovery, user-stories, functional-design, deployment-execution
Workspace detection (workspace-detection) used to be a subagent of the aidlc-developer-agent; it now runs deterministically inside aidlc-utility intent-create using rule-based file and manifest detection.
- Special tools: Bash (for build and run commands)
Domain: Test strategy, test generation, performance validation
The aidlc-quality-agent defines test strategy, generates test suites, validates quality gates, and runs performance testing.
- Leads: build-and-test, performance-validation
- Supports: practices-discovery, user-stories, nfr-requirements
- Special tools: Bash (for test execution)
Domain: CI/CD pipelines, deployment strategy, release execution
The aidlc-pipeline-deploy-agent configures CI/CD pipelines, plans deployment strategy, and executes releases with rollback capabilities.
- Leads: practices-discovery, ci-pipeline, deployment-pipeline, deployment-execution
- Supports: None
- Special tools: Bash (for pipeline and deployment commands)
Domain: Observability, incident response, SLO tracking, feedback loops
The aidlc-operations-agent sets up monitoring, defines incident response procedures, and closes the lifecycle loop by feeding operational insights back to the aidlc-product-agent for the next iteration.
- Leads: observability-setup, incident-response, feedback-optimization
- Supports: none
- Special tools: Bash (for observability and monitoring commands)
This table shows which agents are active in which phases, and whether they serve as lead (L) or support (S).
| Agent | Phase 0 | Phase 1 | Phase 2 | Phase 3 | Phase 4 |
|---|---|---|---|---|---|
| aidlc-product-agent | — | L (intent-capture, market-research, scope-definition), S (rough-mockups, approval-handoff) | L (requirements-analysis, user-stories), S (refined-mockups) | — | — |
| aidlc-design-agent | — | L (rough-mockups) | L (refined-mockups), S (user-stories, domain-design) | — | — |
| aidlc-delivery-agent | — | L (team-formation, approval-handoff), S (scope-definition) | L (delivery-planning), S (units-generation) | — | — |
| aidlc-architect-agent | — | L (feasibility), S (intent-capture) | L (domain-design, units-generation, contract-design), S (reverse-engineering, delivery-planning) | L (functional-design, nfr-requirements, nfr-design) | — |
| aidlc-aws-platform-agent | — | S (feasibility) | S (domain-design, contract-design) | L (infrastructure-design), S (nfr-design) | L (environment-provisioning), S (feedback-optimization) |
| aidlc-compliance-agent | — | S (feasibility) | — | S (nfr-requirements, infrastructure-design) | S (environment-provisioning) |
| aidlc-devsecops-agent | — | — | S (practices-discovery) | S (nfr-requirements, infrastructure-design, build-and-test) | S (environment-provisioning) |
| aidlc-developer-agent | — | — | L (reverse-engineering), S (practices-discovery, user-stories) | L (code-generation), S (functional-design) | S (deployment-execution) |
| aidlc-quality-agent | — | — | S (practices-discovery, user-stories) | L (build-and-test), S (nfr-requirements) | L (performance-validation) |
| aidlc-pipeline-deploy-agent | — | — | L (practices-discovery) | L (ci-pipeline) | L (deployment-pipeline, deployment-execution) |
| aidlc-operations-agent | — | — | — | — | L (observability-setup, incident-response, feedback-optimization) |
- The aidlc-architect-agent has the broadest involvement (10 stages across 3 phases). It carries the
judgmenttier (inherits your session's model and effort), as do seven other high-judgment agents; only aidlc-delivery-agent, aidlc-pipeline-deploy-agent, and aidlc-operations-agent carry thetemplatedtier - The aidlc-developer-agent spans 3 phases: Inception, Construction, and Operation
- The aidlc-compliance-agent and aidlc-devsecops-agent operate purely in support roles, participating in stages led by others
- The aidlc-operations-agent closes the lifecycle loop by feeding insights back to the aidlc-product-agent
On Claude Code, every agent inherits the full session toolset plus provisioned MCP tools, with disallowedTools: Task blocking nested delegation. Other harnesses use native tool policy for the same boundary; Kiro delegate allowlists omit subagent, and its projected agent Markdown does not carry the unsupported Claude key. The table below records which tools each persona is expected to exercise in its work, not a per-agent grant.
| Tool | Expected to exercise it |
|---|---|
| Read, Edit, Write, Glob, Grep, AskUserQuestion | All 14 agents |
| Bash | aidlc-aws-platform-agent, aidlc-devsecops-agent, aidlc-developer-agent, aidlc-quality-agent, aidlc-pipeline-deploy-agent, aidlc-operations-agent |
| WebSearch | aidlc-product-agent, aidlc-design-agent, aidlc-compliance-agent |
| Task / native delegation tool | None (blocked by each harness's projected agent policy) |
To narrow a Claude persona, add an optional tools: allowlist to its frontmatter — but doing so drops inherited MCP access unless the fully-qualified mcp__<server>__<tool> ids are also listed. Other harnesses use their native agent configuration.
The table above shows the built-in tools each persona is expected to use; in practice every agent inherits all of them. MCP servers follow the same inherit-all model: this implementation declares them once in .mcp.json at the project root (beside .claude/), Claude Code provisions them to the session, and every agent inherits all of them — there is no per-agent grant. Each of the 14 agents can reach every declared server (context7 and the four AWS servers) with no further configuration, and a server you lack credentials for is simply unavailable rather than a blocker. To stop a specific agent from reaching a server, narrow that agent's tools: allowlist to the fully-qualified mcp__<server>__<tool> ids it should keep (for example mcp__context7__<tool>); this implementation ships no such restrictions today.
See Getting Started for the server registry and credentials, and Harness Primitives Mapping for how MCP maps onto Claude Code's native tool model.
Beyond the 11 domain-expert agents, AI-DLC ships 2 quality-gate reviewer agents. They do not produce artifacts — they review what a builder produced and challenge it, representing the customer (or the review board) at the gate.
| Reviewer | Reviews | Tier |
|---|---|---|
aidlc-product-lead-agent |
Requirements, user stories, and UX/mockup artifacts — completeness, business alignment, testability | balanced |
aidlc-architecture-reviewer-agent |
Technical design artifacts — soundness, implementability, broken cross-references, unachievable NFR targets | balanced |
One more agent sits outside both groups: aidlc-composer-agent, the adaptive-workflows composer. The conductor dispatches it on a compose request (/aidlc compose, a compose offer on a cold start, --report, or --new-scope). It estimates the task's implementation entropy (five components: intent ambiguity, structural uncertainty, verification entropy, risk, unresolved assumptions - grounded in CodeKB MCP analysis when configured, the workspace scan otherwise), proposes the minimum viable EXECUTE/SKIP grid with the score breakdown and a per-stage rationale, and - only after your approval at the gate - the plan is created for that piece of work (front/report; the composer writes no scope file, and the engine saves the plan as a scope only if you ask) or its pending-stage flips are applied by the deterministic recompose verb (in-flight). Its persona justifies both presence and absence against the entropy profile: every EXECUTE names the component it reduces, every SKIP names what already covers it, and cutting the spine (core, verification, the load-bearing discovery stage) is treated as the dangerous failure. See Scopes and Depth - The Adaptive Composer.
A reviewer fires only when a stage declares a reviewer: field. Today the product
lead reviews intent-capture, rough-mockups, refined-mockups,
requirements-analysis, and user-stories; the architecture reviewer reviews
domain-design, units-generation, contract-design, functional-design,
nfr-requirements, nfr-design, infrastructure-design, and code-generation.
The reviewer step. After the stage body produces its artifacts and before the
learnings ritual and approval gate, the conductor invokes the named reviewer as a
separate sub-agent. The reviewer reads the stage definition, the Q&A, and the
artifacts (never the builder's memory.md or plan — it forms independent
judgment), then writes its review (a verdict of READY or NOT-READY plus
a report of what changed: prior findings it re-checked and new findings) to the
review file the conductor names. The engine keeps the findings list: it assigns
the IDs, keeps your decisions exactly as you made them, and never lets a
reviewer write one. The reviewer never
edits the artifact it reviews; the engine records the review as a framework-owned
record under the intent's .aidlc-engine/reviews/ directory, writes a readable copy
with the full findings list as of that review for people at
<stage dir>/reviews/review-NN.md beside the reviewed
artifact, and refuses a verdict whose artifacts changed. How the verdict is handled depends on the stage's review class:
- Advisory (the human-gated ideation/inception prose stages): one normal-flow review pass, whatever the verdict. The engine's findings list is shown at the approval gate as decision support: you triage it, and a Request Changes at the gate is how a finding becomes a revision. If a later output write invalidates the terminal receipt, one bounded recovery request runs at the next ordinal.
- Adversarial (the Construction design/build stages): on NOT-READY the
builder re-runs to address the findings and the reviewer re-checks, looping
up to
reviewer_max_iterationstimes (default 2, engine-enforced). If findings remain after the cap, the workflow proceeds to the approval gate with the unresolved findings noted.
When a stage's review passes are used up and its reviewed work changed after the last review (the work took another approach, for example), the approval asks once: "Do you want me to have the new approach checked before you decide?" Say yes and the review runs again, past the passes, before you are asked to approve; say approve and it is approved as it is.
The reviewers also run under a hard turn budget - maxTurns: 60, authored in
the persona frontmatter, enforced natively on Claude Code and projected to
opencode's per-agent steps: 60; elsewhere it ships as persona prose. If a
review comes back without a usable verdict - no review file, or no single
canonical READY / NOT-READY line (a capped, crashed, or cut-off reviewer) - the
conductor re-dispatches that same review once, and a second incomplete attempt
is recorded as NOT-READY, and the gate shows the finding "The review did not
finish, so there is no review result to rely on." (followed by why, when the
reviewer's reply said), so a silent cutoff becomes a visible finding at the
gate instead of a missing verdict. That result is no reviewer's: you are told the review did
not finish, and your approval records it that way. If you stop a review
yourself and say what you want, the conductor does not retry it on its own: it
checks the next step first and does what you asked. Every request opens a
fresh review slot, so a stale pre-revision review can never be misread as
covering new work. Reviews recorded
by earlier releases as a ## Review section inside the artifact stay readable
at the gate until the next review replaces them.
The scope can cap the class (bugfix, poc, classic, and workshop cap
every stage to advisory; express caps reviews to none) and
/aidlc --review <class> caps it per run. Explicit autonomy keeps the single
pre-merge review, exempt from scope caps and per-run overrides. Either way the reviewer never blocks —
the human always has final say.
(IMPORTANT: use plain agent names in backticks as shown — do NOT make them markdown links; per-agent reviewer doc pages do not exist yet.)
- Phases and Stages — see agents in context of the full stage flow
- Knowledge — how agents load methodology and team knowledge
- Rules and the Learning Loop — behavioral rules that constrain agent behavior
- Glossary — terminology reference