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 authored agents share a common frontmatter baseline. On Claude Code, none declares a tools: allowlist, so every agent inherits the full session toolset plus provisioned MCP tools, with disallowedTools: Task as the nested-delegation denial. Other harnesses project that intent into native policy: Kiro agent Markdown omits the unsupported key, while Kiro CLI JSON and Kiro IDE tools: grants exclude subagent from delegates. The two review-only agents additionally carry maxTurns: 60 - a hard turn backstop enforced natively where the harness has a lever: on Claude Code the frontmatter key is binding (the sub-agent is stopped mid-task, no final message), and on opencode the packager projects it to the native per-agent steps: 60 (the runner grants one final text-only turn - a summary can return, but no tool call can write the review). Codex TOML personas carry the number as prose only (a TOML persona has no frontmatter, so the emit rewrites the citation), and Cursor, Copilot, and Kiro expose no per-agent cap key (the inert maxTurns: key still ships on the .md surfaces that tolerate unknown keys; the kiro agent JSONs never receive it). Section 12a's incomplete-attempt guard turns a review cut off at the cap into one retried dispatch and then a NOT-READY finding instead of a silently missing verdict - and the conductor deletes any pre-existing ## Review section before every dispatch, so a stale verdict can never stand in for a missing one.

The Claude Code session toolset

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

Common Disallowed Claude Code Tools

Tools each persona is expected to exercise

On Claude Code, 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 Claude persona, add an optional tools: allowlist (which drops inherited MCP unless mcp__<server>__<tool> ids are also listed).

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 + effort: medium, templated -> model: inherit with no effort pin). Judgment and templated agents therefore inherit 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 tier remains the Writing up group for aidlc config models, where a project can record the former downgrade as an explicit per-install choice.

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. The shipped balanced baseline pins medium effort on Claude Code, Codex, and opencode; on Kiro, Cursor, and Copilot 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 (10 stages across 3 phases), reflecting its role as the central design authority. - Across the full 14-agent roster, nine agents carry the judgment tier, three carry the inheriting templated tier, and only the two balanced reviewers step down on Claude Code, Codex, and opencode. On Kiro, Cursor, and Copilot all tiers inherit the session model and effort. 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 authored source) -- the forwarding loop that acts on engine directives; carries a human-readable stage-graph mirror