Agent Reference

Technical reference for AI-DLC's 14-agent roster: 11 domain experts, 2 review-only agents, and the adaptive-workflows composer.

For design philosophy and rationale, see the Agents chapter in the User Guide.

The 14 Agents (11 domain experts + 2 reviewers + composer)

Shared Configuration

All 14 agents share a common configuration baseline defined in their frontmatter. None declares a tools: allowlist, so every agent inherits the full session toolset — all of Claude Code's built-in tools plus any MCP tools provisioned to the session. The one shipped restriction is disallowedTools: Task.

The session toolset (inherited by every agent)

Every agent inherits the built-in Claude Code tools, including:

Common Disallowed Claude Code Tools

Tools each persona is expected to exercise

Every agent can reach Bash and WebSearch by inheritance; the table records which personas the methodology expects to use them, not a per-agent grant. To genuinely restrict a persona, add an optional tools: allowlist (which drops inherited MCP unless mcp__<server>__<tool> ids are also listed) — this implementation ships no such restrictions.

Agent Tiers

Every shipped agent declares a tier: in its authored frontmatter; the packager projects it into each harness's native model/effort keys (on Claude Code: judgment -> model: inherit with no effort pin, balanced -> model: sonnet with no effort pin, templated -> model: sonnet + effort: medium). A judgment agent is therefore never downgraded below the session's own model and effort. An agent is templated only when its output is dominantly pattern-following — delivery plans, CI/CD YAML, observability and runbook scaffolding — and the methodology is already encoded in the agent's knowledge files.

The nine judgment agents share one property: their work requires multi-constraint reasoning whose decisions cascade downstream. Architectural boundaries, interpretation of ambiguous intent, UX trade-offs, code synthesis under dense context, risk-based test strategy, threat prioritisation, regulatory edge-cases, and cloud architecture trade-offs all fall in this category. The two balanced reviewers evaluate novel input against explicit criteria — the checklist encodes the method, so a mid-size model at session effort suffices (on Claude Code, Codex, and opencode; on Kiro all tiers inherit the session model and effort). See the projection table and the tier_cap override in Agent System.

Agent Summary Table

Agent Comparison Matrix

Yes in the next two columns means the methodology expects the persona to use that inherited tool; it does not grant or withhold access.

Observations: - The aidlc-architect-agent has the broadest stage involvement (9 stages across 3 phases), reflecting its role as the central design authority. - Across the full 14-agent roster, nine agents carry the judgment tier and five step down on Claude Code, Codex, and opencode (the two balanced reviewers plus the three templated planners; on Kiro all tiers inherit the session model and effort, so no agent steps down there); the stepped-down agents produce reviews against explicit checklists or dominantly templated planning, CI/CD, and runbook work. The matrix above covers the 11 domain-expert agents. - The aidlc-compliance-agent operates purely in an advisory capacity (4 support stages across Ideation, Construction, and Operation; no lead stages). - Six of 11 agents are expected to use Bash for CLI interaction (infrastructure, security, development, testing, deployment, operations). - Three agents are expected to use WebSearch for research tasks (product, design, compliance).

Phase Participation

This table shows which agents are active in which phases, and whether they serve as lead (L) or support (S) in that phase.

Agent Collaboration Map

graph TD
    subgraph "Ideation & Inception"
        PA[aidlc-product-agent]
        DA[aidlc-design-agent]
        DL[aidlc-delivery-agent]
        AA[aidlc-architect-agent]
        CA[aidlc-compliance-agent]
    end

    subgraph "Construction"
        DEV[aidlc-developer-agent]
        QA[aidlc-quality-agent]
        SEC[aidlc-devsecops-agent]
        AWS[aidlc-aws-platform-agent]
    end

    subgraph "Operation"
        PD[aidlc-pipeline-deploy-agent]
        OPS[aidlc-operations-agent]
    end

    PA -- "requirements, stories, intent" --> AA
    PA -- "personas, intent" --> DA
    PA -- "priorities, scope" --> DL
    DA -- "interaction specs" --> DEV
    DA -- "UX acceptance criteria" --> QA
    AA -- "unit specs, API contracts" --> DEV
    AA -- "NFR targets, test boundaries" --> QA
    AA -- "infrastructure requirements" --> AWS
    AA -- "design for review" --> SEC
    CA -. "regulatory constraints" .-> AA
    CA -. "compliance controls" .-> SEC
    SEC -. "security gates" .-> PD
    SEC -. "secure coding requirements" .-> DEV
    SEC -. "security test cases" .-> QA
    DL -- "delivery plan, mob assignments" --> DEV
    DEV -- "code scan results" --> AA
    DEV -- "implemented code" --> QA
    DEV -- "build scripts, source" --> PD
    QA -- "test suites, quality gates" --> PD
    QA -- "performance baselines" --> OPS
    AWS -- "environment endpoints" --> PD
    AWS -- "provisioned infra" --> OPS
    PD -- "deployed services" --> OPS
    OPS -- "operational feedback" --> PA
    OPS -. "architecture improvements" .-> AA
    AWS -. "cost optimization" .-> OPS

Text Fallback

aidlc-product-agent
  |-- requirements, stories --> aidlc-architect-agent
  |-- personas, intent -------> aidlc-design-agent
  |-- priorities, scope ------> aidlc-delivery-agent

aidlc-design-agent
  |-- interaction specs ------> aidlc-developer-agent
  |-- UX acceptance criteria -> aidlc-quality-agent

aidlc-architect-agent
  |-- unit specs, API contracts --> aidlc-developer-agent
  |-- NFR targets, test boundaries --> aidlc-quality-agent
  |-- infrastructure requirements --> aidlc-aws-platform-agent
  |-- design for review -----------> aidlc-devsecops-agent

aidlc-compliance-agent
  |-- regulatory constraints ....> aidlc-architect-agent
  |-- compliance controls .......> aidlc-devsecops-agent

aidlc-devsecops-agent
  |-- security gates ............> aidlc-pipeline-deploy-agent
  |-- secure coding requirements > aidlc-developer-agent
  |-- security test cases .......> aidlc-quality-agent

aidlc-delivery-agent
  |-- delivery plan, mob assignments --> aidlc-developer-agent

aidlc-developer-agent
  |-- code scan results --> aidlc-architect-agent
  |-- implemented code ---> aidlc-quality-agent
  |-- build scripts ------> aidlc-pipeline-deploy-agent

aidlc-quality-agent
  |-- test suites, quality gates --> aidlc-pipeline-deploy-agent
  |-- performance baselines ------> aidlc-operations-agent

aidlc-aws-platform-agent
  |-- environment endpoints --> aidlc-pipeline-deploy-agent
  |-- provisioned infra -----> aidlc-operations-agent

aidlc-pipeline-deploy-agent
  |-- deployed services --> aidlc-operations-agent

aidlc-operations-agent
  |-- operational feedback -------> aidlc-product-agent  (CLOSES THE LOOP)
  |-- architecture improvements .> aidlc-architect-agent

Cross-References

• Architecture Overview
• Orchestrator
• Agent System
• Stage Documentation
• Agents chapter in the User Guide (philosophy and rationale)
• SKILL.md (Conductor) -- the forwarding loop that acts on engine directives; carries a human-readable stage-graph mirror