asdlc-maturity-assessment

ASDLC Maturity Assessment

Purpose

Turn "how mature are we with AI coding agents?" into a defensible, leveled diagnosis and a specific next-level roadmap — not a vibe. Score the organization path-by-path against the 8-path × 5-level matrix below, back every score with evidence pulled from systems of record, and hand the resulting gaps to a platform roadmap. (For designing the platform that closes those gaps, hand off to the sibling idp-adp-architect skill — this skill diagnoses; that one architects.)

When the engagement starts without a trusted evidence baseline, run platform-maturity-discovery first. It gathers organizational signals across communication, meetings, work items, repositories, infrastructure, and sentiment; this skill consumes that evidence and scores agentic delivery paths only.

Core model to hold in your head

SDLC vs. ASDLC

The traditional SDLC assumes a human initiates and executes every stage: write, review, validate, deploy. That assumption breaks once agents retrieve context, implement changes, validate output, and respond to signals on their own. The Agentic Software Development Lifecycle (ASDLC) is the SDLC re-architected for that reality. The lifecycle stages don't disappear — what changes is who initiates and executes them, and what governs the handoffs. The differentiator is not model access (a commodity) but how well the organization's deterministic fabric — CI/CD, policy enforcement, ephemeral environments, identity — governs probabilistic intelligence at scale. Most failed AI initiatives fail here, not at the model: the platform lacked guardrails, checks, and balances during execution. Watch for the self-confirmation loop failure mode: an org layers AI on an unchanged platform, gets all downsides and little benefit, concludes "this isn't for us," and falls behind.

The human-role axis (per-team diagnostic)

As maturity rises, the human role shifts: Executor (L0–L1) → Validator (L2) → Orchestrator (L3) → Constraint-setter (L4). Use this as a per-team probe: ask each team who initiates work, who verifies it, and what humans actually spend review time on. Teams inside one org routinely sit at different points — frontend estates often run a full level ahead of backend, because behavioral validation (deploy previews) matures faster than deterministic backend guarantees. Record a role-axis reading per team; a mismatch between the claimed level and the observed human role (e.g., "we're Level 2" but engineers still read every diff line-by-line) is a scoring red flag. The sibling platform-org-design-advisor skill consumes these role-axis readings as its org-design driver.

Paths, not pipelines

Where the SDLC moves work through pipeline stages, the ASDLC moves work through paths — a path is how any actor (human or agent) advances a piece of work toward an outcome. There are eight paths total: seven exist at baseline; the eighth (dispatch work to agents) appears at Level 2. Every path is:

• Deterministic — pipeline-driven, gated, repeatable (unchanged from the SDLC: CI, security scans, deploys).
• Probabilistic — agent-driven, verified by evals and humans.
• Hybrid — the loop that defines the ASDLC: probabilistic step → deterministic gate → retry with enriched context until it passes. This loop has no SDLC equivalent and is the most underestimated shift for organizations making the transition.

A definition of done must be written explicitly for every path an agent touches (functional correctness, architectural alignment, policy compliance, operational characteristics). In the SDLC this lived tacitly in senior engineers' heads; in the ASDLC, agents need it written down or the hybrid loop has nothing to converge against.

Level 0 baseline: the seven paths

Score Level 0 ("human is the loop") when a functional delivery platform exists but no agentic capability runs in production. The baseline path inventory — take it into every engagement, because tools vary (CI: Jenkins, GitHub Actions, GitLab; deploy: Kubernetes, serverless, VMs) while the path structure is stable, which is what makes the rubric tool-agnostic:

Path	Typical input	Example capabilities	Output
Retrieve context	Ticket, issue, feature request	Repository search, documentation retrieval, dependency lookup	Context for the developer
Implement change	Intended code creation	Editing tools, compilers, dependency managers	Candidate code change or commit
Validate change	Code change or PR	CI pipelines, unit/integration tests, security scans	Verified artifact or failing validation
Promote change	Validated artifact	Review systems, promotion policies, environment checks	Approved artifact ready for deployment
Deploy system	Release artifact	Deployment orchestrators, infra provisioning, rollout automation	Running system in staging/production
Observe system	Runtime signals	Logging, metrics, tracing, alerting	Operational visibility and telemetry
Remediate issue	Alert or operational signal	Debugging tools, rollback mechanisms, patch deployment	Restored system state

A missing or broken path at L0 (e.g., no automated validation at all) is a prerequisite gap — flag it before any agent-adoption recommendation, because agents amplify whatever foundation exists. The paths built for human developers are the same paths agents will eventually execute.

The five levels (score each against path evidence, not aspiration)

Look for evidence running in production today, not plans.

Level 0 — Human is the loop. Manual development on a functional platform; all seven paths human-executed. Not a failure state — a solid L0 path inventory is the agentic groundwork.

Level 1 — Human in the loop.

• What changes: exactly two paths altered, nothing added. Implement change gains prompt-driven code generation in the IDE — the developer reviews, accepts, or rejects every proposal and remains the execution engine. Retrieve context gains agentic search — agents explain components, summarize files, propose modification strategies. The deterministic platform remains final authority; this is local augmentation, not structural transformation.
• Evidence to look for: IDE-integrated assistants; no agent-initiated PRs; all code review is per-line/per-diff.
• What the platform needs: organizational knowledge made machine-consumable (structured docs, codebase access, architectural guidelines an agent can retrieve reliably). Most enterprises are here today.
• Gain/constraint: linear gains; the binding constraint is human review bandwidth.

Level 2 — Human on the loop. The hardest jump — most orgs stall here. Six of eight paths are new or altered. L1 was "work enters when a developer types"; L2 is "humans send agents off to do chunks of work on their behalf" — the first real parallelization. The human still triggers everything and stays accountable.

• Dispatch work to agents (NEW path — the defining L2 addition). Human-directed assignments become governed parallel agent execution: point an agent at a ticket for a first-pass implementation, route an alert into an agent workspace, pre-work backlog items before a sprint. Defining pattern: a human sends one or more agents into an execution layer (e.g., a cloud coding agent's web interface) where multiple PRs generate in parallel; the human triages later. Audit the path's five capabilities explicitly: (1) work-assignment intake (UI/CLI/tracker integration); (2) context packaging — a "context stack" of repo, docs, known issues, environment hints; (3) non-human identity and scope enforcement (what the agent may touch); (4) workspace/sandbox provisioning so parallel work doesn't collide; (5) output routing (create a PR, or a ticket with PR attached).
• Retrieve context (altered). The agent is now the primary consumer: repo/dependency traversal that doesn't explode context windows, access to architectural intent (docs, ADRs, diagrams), environment awareness. Output must be structured context an agent can execute on, not prose. Documentation quality stops being nice-to-have.
• Implement change (altered). Agent-executed for many work items, in parallel and in the background. Multi-repo work exists but is awkward — often one agent proposes changes plus instructions for another repo; note it as a known L2 limitation, not a failure.
• Validate change (altered — becomes a loop; the most underestimated shift). With parallel PRs, a single human checkpoint stalls the system. Validation becomes a loop the agent retries inside — failure signals route back to the producing agent, which modifies and resubmits until deterministic checks pass. Aspiration: verification becomes boring — by the time a change reaches validation it should almost always pass; each failure class becomes feedback for improving the agent's operating model (immediate: reprompt; structural: update the context stack, rules, and testing expectations to push that failure class upstream). Audit three structural consequences — their absence means the loop isn't real:
  1. CI capacity pressure. Agents iterate far more aggressively than humans: more pipeline executions, more ephemeral environments, potentially dramatically higher compute. If CI spend and capacity planning haven't changed, the loop probably isn't running. CI/cloud cost can outgrow productivity gains if undesigned — check for cost governance.
  2. Widened validation scope. Unit tests can't replace human-reviewer judgment. Look for scenario execution, performance checks, dependency and license analysis, and environment-integrity checks added to the loop.
  3. Automated security and policy enforcement. Security scanning, secret-exposure checks, vulnerability detection, and compliance validation must run inside the loop; IaC policy checks (Terraform plans, Kubernetes manifests, Helm charts) run as deterministic in-pipeline gates — tools like OPA, Kyverno, or Checkov — not post-deployment audits. Non-negotiable at L2 volume. The quality of the policy layer directly determines how much autonomy can safely be granted — codified policies are the L2→L3 gate. Two more loop markers: AI-assisted code review runs early in the loop (review agents comment and the agent incorporates fixes before any human looks), and validation style diverges by estate — frontend leans on behavioral evidence (deploy previews in ephemeral environments; reviewers inspect the running feature; some teams run browser-driving "usability agents" that attach screenshots/videos), while backend must lean on deterministic checks (end-to-end scenarios, performance and startup-time regressions, data-integrity and security policies as evidence). Shared bar: validation must produce evidence strong enough to replace manual diff inspection.
• Promote change (altered). Humans stop reading every diff; they verify behavior, review evidence (tests, scenarios, policy outcomes), and triage with two gates: "Could we, in theory, ship this today?" and "If it doesn't work, is it easy to fix?" Yes → ship or loop back to improve the agent's rules; no → backlog with the PR attached.
• Observe system (altered). Observation becomes a source of work humans route to agents (alerts dispatched for diagnosis, anomalies investigated, recurring issues assigned). The human remains the trigger — observation feeding agents directly is the L3 shift; don't credit it early.
• Evidence to look for: a dispatch capability exists; agent identity tracked separately from human identity; validation runs as an automated retry loop before a human ever looks; review redefined from per-PR to per-batch.
• Gain/constraint: multiplied throughput; the constraint shifts from typing speed to validation quality.

Level 3 — Human as orchestrator. Humans orchestrate the system of agents rather than supervising individual changes; the platform runs continuously in the background and becomes less a tool developers use and more an industrial system developers supervise. Very few orgs run full L3 today — some reach it for their frontend estate only. L2→L3 is not "more automation"; it is a change in how work is triggered. Four paths expand:

• Dispatch (expanded). The platform itself generates work from observed patterns: recurring operational anomalies, dependency updates and security advisories, performance regressions, backlog preparation, incomplete work detected through analysis. New capabilities to verify: task scheduling, multi-agent coordination, conflict detection when changes overlap, prioritization of background streams.
• Implement change (expanded). Agents implement improvements without explicit human initiation — dependency upgrades, small refactors, configuration adjustments. Artifact type unchanged; what changes is cadence: a steady incremental stream vs. sporadic commits.
• Validate change (expanded). Validation is now the central control mechanism of the whole system, handling much larger concurrent volume: functional and scenario testing, architectural compliance, performance validation, dependency/security analysis, policy enforcement. Failures auto-route to the responsible agent. Human review becomes rare — only for ambiguous results or high-impact changes.
• Promote change (altered) — the risk-classification promotion engine (key L3 assessment checkpoint). Validated artifact → a classification engine assigns a risk tier → low-risk classes (dependency updates, minor performance fixes, well-understood operational issues) auto-promote to production with no human in the path; high-risk classes (new features, schema changes) require human review. Humans review the rules, not each change. To credit L3 here, demand three artifacts: the written classification rules, the audit trail of actual auto-promotions, and the rollback record. "Auto-promotion" that is actually a human clicking merge quickly is L2.
• Observe system (expanded). Observability becomes the platform's sensing system and primary signal source: pattern recognition across telemetry, anomaly-to-work-item conversion, a direct feed into dispatch — error spikes, latency changes, and cost anomalies initiate tasks without a human filing a ticket.
• Evidence to look for: background/async agent execution with state persistence (agents resume, not just run once); rule-based auto-promotion for a defined class of changes; observability feeds that trigger work rather than just reporting; agent compute/token cost tracked as its own governed line item.
• Gain/constraint: expanded execution capacity; the constraints are architectural maturity and token economics.

Level 4 — Fully autonomous (explicitly speculative — an outlook, never a score). Essentially no broad production examples exist; treat L4 as the trajectory's logical endpoint, not a scoreable level. Never assign Level 4. Instead, record forward indicators when observed (the org still scores L3 at most). The universal L4 pattern: observe a signal → determine it falls within a governed class of work → initiate paths → validate → promote per risk classification. Humans set constraints, policies, and risk thresholds — not tasks.

• Self-healing remediation decision tree (forward indicator): alert/anomaly → issue classification and pattern matching (known issue? playbook exists? severity/blast radius?) → if auto-remediable: execute playbook / apply learned fix / roll back; if not: escalate to a human (novel issue, high blast radius, failed playbook). Learnings feed back into the pattern library, so every remediation expands future autonomy. A working version of this tree for even one issue class is a strong forward indicator — note it, still score ≤ L3.
• Five unlock classes (forward indicators to note, never score): (1) competitive feature tracking — the system monitors competitor product surfaces and generates validated candidate implementations for human ship/no-ship decisions; (2) demand-responsive adaptation — usage shifts trigger infra scaling, config, even feature adjustments within policy boundaries; (3) continuous large-scale refactoring — tech debt, dependency risk, and architectural drift addressed as continuous background work instead of a quarterly initiative that never gets prioritized; (4) proactive CVE/compliance remediation — new CVEs detected, exposure assessed, patches generated and validated through the full loop, presented for promotion; compliance drift arrives as change proposals, not audit findings; (5) self-improving validation — structurally the most important: the system analyzes its own validation-failure patterns and updates agent context stacks, testing expectations, and policy rules, making the L2 feedback loop self-tuning.

The 8-path × 5-level status matrix (core scoring rubric)

Score every path, then derive the org level. Statuses: Unchanged / Altered (meaningfully changed) / Expanded (significantly scaled up) / New / Automated / — (not present).

Path	L1	L2	L3	L4 (outlook)
Retrieve context	Unchanged	Altered — agent-scale, structured, executable context	Unchanged (reliability now critical)	Unchanged (runs inside autonomous cycles)
Implement change	Altered — prompt-driven codegen, human accepts/rejects	Altered — agent-executed, parallel, background	Expanded — no human initiation, steady stream	Expanded — responds to environmental signals
Validate change	Unchanged (single human gate)	Altered — retry loop, widened scope, policy gates	Expanded — central control mechanism	Expanded — critical control layer replacing manual approval
Promote change	Unchanged	Altered — evidence-based behavior verification, ship-now vs. park	Altered — rule-based auto-promotion by risk class	Automated — policy-bounded auto-advance
Deploy system	Unchanged	Unchanged (still the governed deterministic path)	Unchanged (higher cadence)	Expanded — autonomously triggered
Observe system	Unchanged (passive monitoring)	Altered — source of work humans route to agents	Expanded — sensing system, anomaly→work-item	Expanded — primary entry point for all work
Remediate issue	Unchanged	Altered — humans dispatch agents to investigate; human applies	Expanded — recurring issues as continuous background work	Automated — self-healing within playbooks
Dispatch work to agents	—	New — the defining L2 addition	Expanded — coordination layer, platform-generated work	Expanded — central autonomous coordination

Scoring rule: for each path, mark the highest status for which production evidence exists. The org's level is the highest level whose full row-pattern is evidenced — report partial states explicitly ("L2 on 5 of 6 required paths; dispatch exists but validation is still a single human gate"). Deploy staying Unchanged through L3 is correct, not a gap: agents produce artifacts; deployment remains the governed deterministic path.

Cross-check with the constraint signature: if the org claims a level but its binding constraint doesn't match (claims L2, yet the bottleneck is still per-diff human review bandwidth), the claim fails — score where the constraint says they are.

Regulated-industry overlay

If the organization is in finance, government, healthcare, or another regulated context, layer these controls onto whatever level you're scoring toward — they don't change the level definitions, but they gate how fast an org can safely move up them:

• Workspace-level governance is the control surface — enforce network access, permissions, model usage, and audit logging at the infrastructure layer, not at the IDE or SaaS-tool layer (vendor/IDE-level controls alone are not sufficient for audit/compliance).
• Governed workspaces: cloud-hosted or air-gapped, policy-as-code, centrally controlled identity and execution.
• Privilege separation: agents run at least privilege; PR-only workflows (agents propose, never merge) reduce risk; human approval stays mandatory at defined checkpoints even at higher maturity levels.
• Core control patterns: provisioning, policy-as-code, audit trails, proxying, per-agent boundaries — these constrain probabilistic agent behavior inside deterministic guardrails.
• Implementation path: start with observability (see what agents are doing before granting more autonomy), then add structured context, then scale through ephemeral, policy-controlled workspaces. Don't skip straight to Level 2/3 capabilities without this sequence in regulated contexts. (For the full control architecture behind these patterns — governed workspaces, privilege separation, policy-as-code — use the sibling platform-security-playbook skill.)

Evidence sources & audit playbook

Don't rely on the interview alone — pull evidence directly from the org's systems of record. Audit these four source categories. Where tool access exists (first-party connectors — see the Workflow section — APIs, or the user pasting exports), inspect directly; otherwise walk the user through pulling each artifact.

1. Work tracking (GitHub Issues/Projects, Jira, Azure Boards)

What to look for, in ascending maturity order:

• Traceability plumbing exists: work items link to branches/PRs/commits (Jira dev panel, Azure Boards AB# links + "Integrated in build" links, GitHub issue↔PR linking). Without this, agentic integration can't be measured at all — flag as a Level-1 prerequisite gap.
• Agents as assignees / actors in the tracker: GitHub issues assigned to the GitHub Copilot coding agent; Jira work items assigned to Rovo/Rovo Dev agents or agents triggered on workflow transitions; Azure Boards "Create a pull request with GitHub Copilot" invoked from work items (status states: In Progress / Ready for Review / Error on the card). Presence of these = Level 2 signal (human-dispatched, agent-executed).
• Automation rules that trigger agents (Jira Automation invoking an agent on transition; Azure Boards → GitHub Copilot custom agents; tracker rules that dispatch work without a per-task human click) = early Level 3 signal — but verify the trigger is genuinely a signal/rule, not a human pressing a button per item.
• Volume & ratio: what % of completed work items in the last 90 days had an agent-generated PR linked? A handful of experiments ≠ integration.

2. Repos & repo settings (GitHub; Azure Repos)

• Agent config files in-repo — a cheap fingerprint of intentional integration: .github/copilot-instructions.md, AGENTS.md, CLAUDE.md, .cursorrules / .cursor/rules, custom agent definitions. Measure eligible-repository coverage, completeness, freshness, and whether build/test instructions work. Presence alone is not maturity; absence across all repos while the org claims heavy agent use is a visibility and governance contradiction to investigate.
• Branch protections / rulesets — the deterministic gate that makes agent PRs safe: required PR reviews (and whether bot/agent authors can self-approve — they must not), required status checks, blocked direct pushes to default branches, CODEOWNERS enforcement, signed-commit requirements. Weak or missing branch protection + active agents = a red flag to call out regardless of claimed level: agents merging without gates is speed without control.
• CODEOWNERS still routed for agent PRs: check that review routing doesn't break when the PR author is a bot (agent-authored PRs still need a human owner mapped).
• Workflows in-repo: .github/workflows/* (or azure-pipelines.yml) present and running validation on PRs — including PRs raised by agents. Note GitHub's default: Actions runs on agent-raised PRs require approval from a user with write access before running; confirm the org hasn't disabled that safeguard.
• Policy-as-code in the pipeline: OPA, Kyverno, or Checkov (or equivalents) gating IaC and manifests on PR — the L2 policy-layer evidence. Manual security sign-off as the only policy mechanism caps the score.

3. CI/CD (Azure DevOps Pipelines — YAML and Classic; GitHub Actions)

• YAML vs. Classic pipelines is itself a maturity signal. YAML pipelines live in the repo: version-controlled, PR-reviewed, branch-specific, template-able — exactly the auditable, deterministic substrate the ASDLC's hybrid loop needs. Classic (UI-defined) pipelines are not version-controlled and get harder to audit as complexity grows; a large Classic estate is a governance liability for agent integration. Inventory both; treat a Classic-heavy estate as a foundational gap to remediate before granting agents autonomy (Microsoft recommends YAML for all new pipelines).
• Gates and policies: Azure DevOps branch policies (required reviewers, build validation, linked-work-item requirement, comment resolution), environment approvals and checks, required YAML templates from a central security team, service connections with restricted scope. These are the deterministic gates agent output must pass through — enumerate which exist and which classes of change they cover.
• Do agent-generated changes flow through the same pipelines as human changes? Any side door (agents pushing artifacts or config outside the gated path) is an automatic finding.
• Validation-loop readiness: tests, security scans (CodeQL/secret scanning/dependency analysis or equivalents), and policy checks that run automatically on PR — the raw material of the Level-2 retry loop. Note whether failures are structured enough to feed back to an agent as context.
• Capacity trajectory: pull pipeline-execution counts and ephemeral-environment usage over the last two quarters. Flat CI volume alongside claimed heavy agent adoption contradicts the L2 loop (agents retrying until pass measurably increases executions).

4. Agent attribution — who actually wrote this?

You cannot score Level 2+ without knowing which changes were agent-authored. Audit the attribution story explicitly:

• Bot identities & commit signatures: dedicated agent accounts (e.g., copilot-swe-agent / github-copilot[bot], devin-bot, Claude's noreply@anthropic.com), Co-authored-by: trailers, "Generated with …" commit trailers, and signed/verified agent commits (the GitHub Copilot coding agent signs its commits and links each commit to session logs — a strong audit-trail pattern to look for).
• Known trap — squash-merge erases attribution: cloud agents whose work lands via squash-merged PRs can vanish from commit-level history (and conversely CLI agents like Claude Code appear in commits but rarely as PR authors). Check BOTH channels: PR authorship and commit authorship/trailers. An org that measures only one is undercounting, possibly massively.
• Attribution policy: is there a written convention (trailers required, agent emails standardized, commit hooks rejecting unattributed agent commits)? If the org can't answer "what % of production code last quarter was agent-authored," attribution is a gap to put on the roadmap before autonomy increases.

Measuring agentic integration (quantitative layer)

Once evidence sources are audited, quantify. Measure outcomes, not activity — acceptance rates and suggestion counts are vanity metrics on their own. (Design the full measurement and ROI program with the sibling platform-roi-scorecard skill.)

• Adoption & usage telemetry: GitHub Copilot usage metrics (dashboards + REST API / NDJSON export) provide org/enterprise-level daily+28-day data: active users by feature (completions vs. chat vs. agent mode vs. cloud coding agent), agent-adoption trend, code-generation breakdown by user- vs. agent-initiated activity, and PR lifecycle metrics (PRs created by GitHub Copilot vs. overall, median time to merge). Equivalent telemetry for other agents may need assembly from the attribution signals above. Watch retention, not just week-one uptake — early-adopter drop-off after a few weeks is common and distinguishes experimentation from integration.
• Delivery outcomes (DORA), segmented by agent involvement: lead time for changes, deployment frequency, change failure rate, MTTR — compared before/after adoption AND between agent-touched and human-only changes. Add: agent-PR merge rate, time-to-merge for agent-assisted PRs, rework/revert rate on agent-authored changes. Compare at team/org level, never individual-vs-individual.
• Watch for the local-optimization trap: field data repeatedly shows individual output jumping (tasks completed, PRs merged) while org-level delivery stays flat because the constraint moves to review, integration, and deployment. If agent adoption is up but lead time isn't moving, find where the queue formed (usually human review bandwidth) — that's the real next-level platform requirement, and it's exactly what the Level-2 validation loop exists to fix.
• Foundations check (DORA AI Capabilities Model, 2025): seven practices that determine whether AI amplifies strength or dysfunction — clear & communicated AI stance, healthy data ecosystem, AI-accessible internal data, strong version-control practices, working in small batches, user-centric focus, quality internal platform. Use as a secondary checklist: an org weak on these will see agents amplify chaos regardless of tooling. ("AI is an amplifier" is the core finding — it matches this skill's own guardrail that a shaky foundation gets worse, faster.)
• Balance with experience metrics: pair throughput numbers with SPACE-style satisfaction/well-being signals — a spike in agent-generated PR volume with rising reviewer frustration or burnout is accumulating strain, not progress.

Calibration benchmarks (industry survey data, 2025) — anchor scores against the market

Use these to keep scoring honest — both against inflation ("everyone uses AI daily, we must be Level 2") and deflation; the sibling platform-industry-brief skill carries the full benchmark databank these figures draw from:

• ~89% of practitioners report daily AI usage, but it is overwhelmingly tactical — code generation (~75%) and documentation (~70%) dominate. Daily individual usage is a Level-1 signal at best; never let ubiquity of assistants inflate a score.
• ~41.5% of organizations report no changes at all to their CI/CD pipelines for AI. The L2 validation loop is absent in a large share of the market — pipeline evolution is one of the most discriminating questions you can ask.
• Roughly 61% have never used agentic (dispatch-style) workflows. Genuine Level 2 remains a minority position; a claimed L2/L3 should stand out with strong artifact evidence, not blend in with the crowd.
• Platform teams own AI platform responsibilities in only ~36.7% of orgs; ~25% share ownership across teams and ~15% have no clear owner at all. Always establish who owns agent enablement — no clear owner effectively caps maturity regardless of tooling, and it's a roadmap item in its own right.
• Governance matures through four pragmatic stages: (1) enable experimentation (sandboxes, clear experiment/production boundaries) → (2) establish guidelines derived from actual usage patterns (principles over rules, outcomes over methods) → (3) automate enforcement (policy-as-code, observability of actual AI behavior, feedback loops) → (4) continuous evolution (governance managed as a product). Record the org's governance stage in the report; stage 3 is effectively a prerequisite for the L2→L3 transition — it is the "codified policies" gate in platform form.
• Productivity evidence is mixed — never assume gains. Controlled study data has shown experienced developers slowing down ~19% with AI assistance in some settings, while practitioner reports on long-horizon agentic workflows claim 18–38% speedups. Both can be true in different contexts. The assessment must demand the org's own before/after outcome data rather than importing an assumed uplift into the roadmap's business case.

Workflow

1. Interview. For [YOUR ORGANIZATION / CLIENT], walk through each level's "evidence to look for" with the user and mark: not present / partially present / present & running in production. Take a human-role-axis reading (Executor/Validator/Orchestrator/Constraint-setter) per team, and note frontend vs. backend divergence.
2. Audit the systems of record. Work through the four evidence-source categories above (work tracking, repos & settings, CI/CD, attribution). Prefer direct inspection over self-report; record concrete artifacts (API pulls, config files, policy definitions) per finding.
3. Collect evidence via first-party connectors (see subsection below). Wherever the org's vendors expose first-party MCP servers or APIs, pull the evidence programmatically instead of accepting screenshots or verbal claims.
4. Quantify. Pull the measurement layer above: adoption/usage telemetry, DORA outcomes segmented by agent involvement, the DORA AI-capabilities foundations check — and calibrate the raw numbers against the industry benchmarks. Establish a baseline even if it's the first measurement.
5. Score with the 8-path matrix. Mark each path's achieved status with its evidence; the org level is the highest level whose full row-pattern is evidenced and running (never the highest anyone aspires to). For every path, record applicable rubric checks, met checks, and partial/contradicted/unobserved checks with stable evidence citations. Report per-path and per-team, cross-check the constraint signature, note Level-3-in-name-only patterns (e.g., "background execution" still triggered per-task by a human — that's Level 2), and record any L4 forward indicators separately without scoring them.
6. Flag the regulated-industry overlay if applicable, and check the control patterns above explicitly — call out any missing ones as blockers to advancing, independent of level.
7. Roadmap. Identify the single hardest unmet requirement for the next level (moving 1→2 it's usually the dispatch path + validation loop + agent identity + sandboxing; moving 2→3 it's codified policy enforcement + the risk-classification promotion engine + observability-to-dispatch wiring) and sequence a 30/60/90 plan around it. Don't propose Level 3/4 capabilities to an org that hasn't solidified Level 2. Hand platform-design work to the idp-adp-architect sibling skill.
8. Output. A maturity report: current level with the scored path matrix; a per-path evaluation ledger (criteria met / applicable, partial/contradicted/unobserved checks, confidence, citations); per-team role-axis readings; target level; specific gaps mapped to platform requirements; attribution and branch-protection findings; governance stage; the regulated-industry control checklist if relevant; L4 forward indicators if any; and a phased roadmap. The criteria ratio justifies the evidence behind a path result but never substitutes for the full-row gate.

Evidence collection via first-party connectors

Map each discovery question to the vendor-owned connector that answers it. These are examples inside a tool-agnostic structure — substitute whatever first-party surface the org's stack exposes:

Discovery question	First-party connectors (examples)
Code, PR & pipeline evidence — agent config files, branch protections, PR/commit authorship, workflow runs, security posture	GitHub MCP server (repos, PRs, Actions, code security, commit search) · Azure DevOps MCP server (repos, PRs, builds, boards, wikis) · GitLab MCP server (MRs, issues, pipelines — beta, gated behind Premium/Ultimate + Duo)
Work-item flow — agent assignees, automation rules, work-item→PR linkage and ratios	Atlassian Remote MCP server (Jira, Confluence, Compass service catalog — useful for attribution audits) · boards/issues toolsets of the GitHub and Azure DevOps servers above
Org & collaboration signals — who reviews agent PRs, ownership, meeting/comms load, knowledge silos	Microsoft Work IQ MCP servers (people graph, mail/Teams/meeting semantics — requires eligible Microsoft 365 licensing; preview status) · Google Workspace MCP servers (Gmail, Drive, Calendar, Chat, People — developer preview)
Cloud resource & cost reality — agent compute as a governed line item, CI capacity pressure, ephemeral-environment spend	Managed AWS MCP Server (any AWS API under the caller's IAM, incl. Cost Explorer/Budgets) · Azure MCP Server (resource inventory, health, Log Analytics; cost coverage partial) · Google Cloud managed MCP servers (per-service; cost indirectly via BigQuery over billing export)

Rules and caveats:

• Prefer these APIs over screenshots and self-report for anything that feeds a score. A config file pulled through the vendor's own API is evidence; a verbal "we have branch protection" is not. Note evidence provenance per finding.
• Verify availability at engagement time. Several surfaces are preview/beta or license-gated (Work IQ requires eligible Microsoft 365 licensing; GitLab's server requires paid tiers plus its AI add-on; remote vs. local server availability shifts). Capabilities and gating change quarter to quarter — never promise a connector in the engagement plan without checking it still exists in that form.
• Telemetry only sees connected users. Developers running agents outside sanctioned tooling — or with telemetry off — are invisible to these surfaces. Cross-check connector data against the attribution audit (commit trailers, bot identities) to size the shadow-usage gap rather than assuming zero.
• Connectors are permission-trimmed to the authenticated user. Run collection under an account whose access matches the assessment scope, and log exactly what was pulled for the engagement's own audit trail.

Guardrails

• Don't let the user self-report a level without evidence — "we use AI agents" is not enough to distinguish Level 1 from Level 2.
• Never score Level 2+ if agent attribution is unmeasurable (no bot identities, no trailers, squash-merges erasing history) — unmeasurable autonomy is a finding, not a maturity level.
• Never assign Level 4 as a score — it is an outlook. Record self-healing remediation or any of the five unlock classes as forward indicators; the ceiling on any scored assessment is Level 3.
• Score per path and per team, not as one org-wide number — report the matrix, and call out frontend/backend divergence explicitly.
• Treat activity metrics (suggestions, acceptance rate, PR counts) as supporting data only; the score and roadmap hang on outcome metrics and platform evidence.
• Never assume productivity gains — the evidence base is mixed (measured slowdowns and claimed speedups coexist); the business case must rest on the org's own outcome data.
• Don't endorse an L2→L3 move while policy enforcement is manual or absent — codified, automated policy gates (the OPA/Kyverno/Checkov class of controls) are the transition's prerequisite, along with governance stage 3.
• Prefer first-party connector/API evidence over screenshots and self-report, and record provenance for every scored finding.
• In regulated contexts, never recommend skipping the observability-first implementation sequence to move faster.

Suggested effort

High — structured interview + systems-of-record audit + scored report.