AI agent maturity model: six levels from prompt pilots to governed execution

Forty-seven pilots. No production architecture.

A diversified enterprise celebrates its forty-seventh AI pilot: contract assistants, service copilots, document extractors, risk classifiers, employee search, and several agents that call enterprise APIs. Twelve have tool access. Seven use retrieval. Four can create or change business records. Each has a sponsor, a prompt, a model and a dashboard of successful requests.

The executive committee asks two questions: which of these are ready for production, and which shared capabilities should we fund?

The inventory can't answer. One pilot checks the user at login, then acts through a broad service credential. Another stores approval as a yes/no flag. A third has no durable state. A fourth can't say which model, prompt, index, policy and mapping produced a past result. Several track tokens; none can tie cost to a business outcome.

The enterprise had accumulated demonstrations, not a production architecture. It's common. Deloitte's 2026 research finds just 21% of organizations have a mature governance model for agentic AI, and Gartner reported in April 2026 that only 13% believe they have the right agent governance.

What is an AI agent maturity model?

It's a way to measure how much consequential responsibility an AI application can safely accept, scored per application and per domain, with evidence required to move up.

Maturity is often read off visible activity: number of models, agents, tools, pilots or users. That shows adoption. It doesn't show an application can produce an authorized, explainable, accountable outcome.

A system can use a very capable model and still be operationally immature. It can run several agents and still lose the requester's authority. It can have an elaborate workflow and still be unable to prove which proposal a person approved. It can have extensive logs and still be unable to explain the final effect.

You don't have one enterprise maturity level. A low-risk drafting assistant can rightly sit low while a payments agent needs much stronger controls. The point isn't a badge. It's making the current and target state explicit, and stopping a strength in one domain from hiding a dangerous weakness in another.

What are the levels of AI agent maturity?

Six: prompt experiments, tool-enabled prototypes, orchestrated applications, governed execution, an authoritative application definition, and a shared enterprise platform. Each widens what the application can prove.

Levels 1 and 2: useful, not production

Prompt experiments test feasibility, failure modes, data needs and user reaction. Context is pasted in, state is session-local, and evidence is a screenshot or small test set. Exit when you have a declared task, representative evaluation cases, known data classes and prohibited inputs, a named owner and known limits.

Tool-enabled prototypes connect to retrieval, APIs and files. They expose the first big gap: the model can reach more than the user is allowed to do. Identity shrinks to a session user while downstream calls use broad credentials. Tool schemas validate fields, not resource ownership or purpose. Exit with typed tool contracts, read-only defaults, declared tenant and data scope, classified side effects, budgets and a plan for durable state and evidence.

Level 3: an application, still fragmented

Orchestrated applications coordinate models, rules, policies, approvals, queues and APIs in a repeatable route. Some state is durable; retries and timers exist. But the workflow owns control flow while identity, policy, approvals, versions and evidence live elsewhere. Engineers reconstruct the full meaning in their heads. This is where most pilots stall. (See coordination debt.)

Exit with one application identity, typed step contracts, durable waits, authority carried through, policy checks at actions, approvals bound to proposals, stable operation IDs and evidence that reaches the external outcome.

Level 4: governed execution

Identity, tenant, purpose, policy, approval, versions and evidence survive the whole case, not just the front door. Context assembly is permission-aware. Model routes are filtered for eligibility before they're optimized. Approval binds to the exact proposal reviewed. Writes get stable operation IDs, reconciliation and confirmation from the system of record. The application can show an action wasn't just successful but authorized under the conditions that held at the time.

This is the minimum for agents that move money, change contracts, touch identity or create regulated effects.

Levels 5 and 6: authoritative and shared

At level 5, one published workflow version is the authority. What people review, what the runtime executes and what the evidence records stay traceably linked. Past cases can be inspected and replayed without live side effects, and each role sees its own view of the same application.

At level 6, those semantics extend across the portfolio. Identity, publishing, contracts, durable state, policy, approvals, side-effect control, evidence and cost attribution are standardized once. Domain teams keep their logic, data, models and apps, joining through declared interfaces. Level 6 isn't an end state; it brings its own risks of over-standardization and central bottlenecks. (See build vs buy an AI agent platform.)

How do you measure AI agent maturity?

Score each application in eight domains, using artifacts as evidence, not slideware. Business outcome, identity and policy, context, contracts, state and side effects, evidence, operations and cost, and platform reuse.

The CISA Zero Trust Maturity Model uses the same idea: progress across several pillars, not one checklist score.

Many failures happen after the model gave a useful answer, at the point where a proposal becomes state, approval, a tool call or an external effect. A mature application can use an imperfect model safely, because it preserves uncertainty, escalates and blocks unsupported actions. An immature one can use a powerful model unsafely, because it lets model output become authority.

What maturity level does an AI application need?

It depends on consequence. Read-only and reversible work can stay low; anything financial, contractual, identity-related or regulated needs governed execution at minimum.

Advance with evidence, not enthusiasm, funding or demo count. Before an application gains more autonomy or new side effects, assemble an evidence pack (definitions, evaluations, control evidence, operating records, cost data, incident tests, outcomes) and review it at a stage gate. Autonomy should be earned in steps. (See progressive automation.)

Maturity drifts after go-live

Passing a review once doesn't make an application mature forever. Models, prompts, indexes, features, policies, identities, providers and processes change. A fallback route gets added without residency rules. An approval event is simplified to a flag. A model alias advances without evaluation. An index keeps stale permission metadata. Cost tracking loses its link to the outcome.

Monitor control coverage, evidence completeness, route eligibility, permission freshness, replay fidelity and cost attribution, not just technical health.

No single team owns maturity. Application owners define the outcome and consequence. Domain teams own data, rules and evaluations. Security and identity define authority. Platform teams provide reusable execution and evidence. Operations owns incidents and recovery. Risk and audit set evidence expectations. Finance ties cost to outcomes. The platform standardizes mechanics; the enterprise stays accountable for decisions and risk.

Common anti-patterns

Ten rules for an AI agent maturity model

1. Measure governed outcomes, not model size, autonomy or pilot count.
2. Score per application and per domain.
3. Set target levels by consequence, reversibility and regulation.
4. Gate every increase in autonomy on evidence.
5. Treat identity, policy, state, side effects and evidence as equal to model quality.
6. Let the weakest consequential domain cap autonomy.
7. Name what's authoritative at each level.
8. Standardize shared controls; extend for domain differences.
9. Monitor for drift after go-live.
10. Reassess using real outcomes, incidents, corrections and cost.

The result: responsibility you can govern

Prompt experiments ask whether something is useful. Prototypes ask whether it can reach the enterprise. Orchestration asks whether parts can cooperate. Governed execution asks whether identity, policy, state, approvals and side effects stay enforceable. An authoritative definition asks whether the whole application is inspectable and replayable. A shared platform asks whether all of that is reusable.

The progression isn't about adding intelligence. An enterprise is mature when it can say what the application is, why it was allowed to act, what it actually did, what it cost, and how the same controls and evidence carry to the next agent.