The agentic AI maturity model

The agentic AI maturity model scores a workflow on how much of it an AI agent actually runs, and, on a separate axis, on how well that agent's actions are controlled while it runs. There are three levels. At level 0 a person still does the work and AI is a reviewed trial at most. At level 1 a person prompts the AI whenever the work comes up. At level 2 an agent runs the workflow end to end, triggered by an event rather than a person. The controls are scored separately, so a team that has automated everything and can answer no questions about evidence, policy or audit reads as a gap, not as a top score.

That is the model behind Alyria's five free assessments. Each one is 20 questions: 18 about how a specific workflow runs today, spread across six phases of that function's work, and 2 about the controls around it. A result needs an answer to all 20 and appears on the page. There is no single maturity number, which is the point. A program is normally mature in a couple of places and immature in most others, and the useful question is which workflow to work on next rather than which grade the company deserves.

The two dimensions

Workflow automation is the first dimension: who performs the work. Every workflow question offers the same three answers, whether the subject is bug triage, invoice capture, supplier evaluation, case resolution or alert investigation.

Level	Name used in the assessments	What earns the point
0	Reviewed trial	A person does the work, or the workflow does not exist yet
1	Bounded workflow	Someone prompts the AI manually each time, then checks the output
2	Verified automation	An agent runs the workflow itself, every time it is triggered

Controls are the second dimension: two questions per track that score 0, 1 or 2, kept out of the workflow score. The first asks what externally verified evidence has to exist before a high-impact step can move forward. The second asks whether runtime policy can stop an action because of what the session already did and what it already read. Both are about enforcement outside the model, because prompting the model to be careful is not a control.

Eighteen workflow questions are worth 36 points in total and the two controls are worth 4. The combined figure exists, and it stays secondary. The report names a gap for any control that scores below 2, and that gap is more informative than the total, because busy and ungoverned is a real combination and it is the one that ends up in an incident review.

The six phases

The workflow questions are spread across six phases of the function's own process, so the result shows where automation is concentrated rather than only how much of it there is. Each track names its phases in the language of that team's work.

Track	The six phases
Software development	Plan, design, implement, test, deploy, observe
Security operations	Prepare, detect, investigate, respond, recover, improve
Procurement	Define demand, source suppliers, evaluate and contract, order and receive, resolve and monitor, renew and improve
Customer service	Receive, assess, resolve, coordinate, close, improve
Financial operations	Capture and validate, account and resolve, authorize and settle, collect and manage cash, reconcile and close, report and improve

Three questions sit in each phase. A program that scores 2 through detect and investigate and 0 through respond and recover is not unusual, and it describes a real risk: the team can see the incident faster than it can act on it. The phase breakdown is where that pattern becomes legible.

Level 0: reviewed trial

At level 0 the workflow is done by a person, or it does not exist yet, and AI enters only as something a reviewer controls. The common shape is a pilot: someone pastes a document into a chat window, gets a suggestion, decides whether to use it, and nothing is written until they have decided. Nothing is triggered, nothing repeats, and the model has no standing access to the systems of record. Most organizations are at level 0 for most workflows, including ones where a few engineers are already further along on their own.

What it looks like in practice. A bug report is read by a person who assigns severity. An invoice is keyed in by a person. A supplier questionnaire is summarised by a person, possibly with a chat window open beside it. The pilot is scoped to a sample, the sample is reviewed, and the question being answered is whether the output is good enough to rely on at all.

Controls expected at this level. Few, but not none, because the trial is where the first inventory entry and the first policy line come from.

• Inventory. A list, even a spreadsheet, of which agents and chat tools are being tried, by whom, and whether any of them hold credentials. The managed version of this list is what Alyria Beacon produces across a fleet, and a trial is the cheapest place to start collecting it.
• Policy. One written rule that says what may not be pasted into a model: customer records, credentials, unreleased financial results. No enforcement layer is implied yet.
• Monitor then enforce. Nothing to enforce. If an agent CLI is installed for the trial, run it observing only, which is how Alyria Beacon deploys: read-only, with nothing intercepted.
• Audit chain. Keep the trial artifacts: the sample, the prompts, the outputs and the reviewer decisions. They are the evidence that the trial was reviewed rather than announced.
• Approvals. Person to person, usually informal. Decide in writing which first automated step would be allowed.

Level 1: bounded workflow

At level 1 the workflow exists and a person drives it with AI assistance. The agent is triggered by a human, works on what the human gave it, and returns something a human checks before it affects a system of record. This is where most teams that say they use AI actually are, and it explains a common mismatch: leadership believes the rollout is automated, and every step still starts with someone typing.

What it looks like in practice. An engineer pastes a stack trace and asks for a fix suggestion, then applies it by hand. A buyer asks for a requisition draft and then corrects the requirements, dates and quantities. An analyst asks for a summary of an alert and then writes the ticket. The work is faster and it is still human-paced, and the queue in front of a person remains the constraint.

Controls expected at this level.

• Inventory. The specific tools in the workflow, their versions and the MCP servers each one is wired to. This is the level where which server a client trusts becomes answerable and starts to matter, because MCP servers proliferate through client config files.
• Policy. Written rules naming which tools, which data classes and which destinations are allowed for this workflow, and one rule about sequences. Alyria writes policy as code in Lyra, which is capability-brokered: an agent is granted the capability to call a named tool against a named resource, and nothing more.
• Monitor then enforce. Every rule that would block something runs in monitor mode first, and the team reads the decisions before turning anything on. That ordering is what keeps a rollout from stalling on its first false positive.
• Audit chain. A record of what the assistant was asked and what was returned, at least for actions that touch a system of record. Local logs are enough at this level, as long as they can be exported when someone asks.
• Approvals. A named person accepts each write: the merge, the purchase order, the payment release, the customer response. The approval is per action and it is easy to justify, which is also why it does not scale much further.

Level 2: verified automation

At level 2 an agent runs the workflow end to end, every time it is triggered, without a person in the loop for the ordinary case. This is the level that produces the results people expect from agentic work, and it is also the level that fails badly when it is attempted without the controls. The remaining human work is exception handling, approval of the actions that were designed to need approval, and reading the evidence.

What it looks like in practice. An issue is filed and an agent labels, de-duplicates and routes it within seconds. A supplier submission triggers requirement assembly with source links. An alert triggers investigation with a reconstructed timeline. The workflow keeps running while everyone is asleep, which is the point and the risk in one sentence.

Controls expected at this level. These are the controls the assessments score, and they are what separates automation from automation anyone can defend.

• Inventory. Continuous, not periodic. Agents, CLIs, versions, MCP servers and models, per endpoint, with the drift visible. A quarterly survey cannot answer which machine started running a new agent last Tuesday. Alyria Beacon inventories the AI layer on each machine and flags hygiene and exposure, including down-level tools, unpinned MCP servers and secrets in config.
• Policy. Policy as code, evaluated at the point where the action originates, deterministically and without a cloud round trip. Lyra is information-flow-aware, so the rule can follow data across tools instead of judging one call in isolation, which is exactly what the second control question asks about.
• Monitor then enforce. Enforcement is promoted rule by rule, category by category, on evidence. Alyria Beacon deploys read-only and starts in monitor mode, and every tenant also receives a managed baseline of rules reconciled into monitor mode. Promoting a rule to enforce is an admin decision in the console, and that reconciliation never overrides a rule an admin set to enforce or off.
• Audit chain. A signed, hash-chained record of the decision, the rule that made it, the revision it applied to and the action that followed, exportable and verifiable off the platform. One chain over every agent decision is the difference between evidence and a collection of logs from five vendors.
• Approvals. Designed rather than default. Approve the release, the payment, the destructive command or the merge to a protected branch, and let everything else run. An approval on every tool call is the fastest route to approval fatigue, and that is the most common way a level 2 program quietly loses its controls.

The table, in one place

Level	A person's role	Automation	Inventory	Policy	Enforcement	Audit	Approvals
0. Reviewed trial	Does the work	None, or a reviewed sample	List of tools being tried	One written prohibition	None, observation only	Trial artifacts	Informal, person to person
1. Bounded workflow	Prompts, then checks	Triggered by a person	Tools, versions and MCP servers for that workflow	Tool, data and destination rules, plus one sequence rule	Monitor mode, read before enabling	Exportable local record	Named person per write
2. Verified automation	Handles exceptions, approves designed actions	Triggered by an event, runs end to end	Continuous, per endpoint, with drift	Policy as code, information-flow-aware, evaluated at the endpoint	Monitor first, then promoted per rule on evidence	Signed, hash-chained, exportable, verifiable	Only where designed, on specific actions

How to move up a level

Moving from 0 to 1 is a scoping exercise. Moving from 1 to 2 is a controls exercise, and it fails when it is treated as a model choice.

1. Pick one workflow, not a program. Choose the workflow whose exception cost is lowest and whose volume is highest. Invoice capture and issue triage are common first choices. Anything that touches payments or credentials is not.
2. Write down who does it now, phase by phase. Use the six phases of that function's track. The phase with the most manual handling is not always the best first candidate, because the cheapest phase to automate is the one with the smallest exception surface.
3. Inventory before you automate. Install the agent inventory first, including on the machines that will not run the agent, so the baseline exists before the change. Alyria Beacon deploys read-only in about 30 minutes and one command removes it, which makes this step cheap to reverse if the program stops.
4. Write the policy you can defend, then run it in monitor mode. Two rules are worth having before any automation: a secret read followed by network egress, and a high-impact action without a recorded approval. Run both in monitor mode for a week and read the decisions rather than the counts.
5. Design the approval around the action, not the call. Approvals belong on releases, payments, deletions and merges to protected branches. Everything else should be a policy decision, recorded, with a path to an exception.
6. Promote enforcement one category at a time, on evidence. Keep the decision log from monitor mode as the justification. A rule promoted after a week of clean monitor decisions survives its first false positive. A rule promoted on a demo does not.
7. Make the audit chain exportable before anyone asks. The first external request for evidence is usually an audit or a customer security review, and both arrive with a deadline.

Two things hold a program at level 1 indefinitely. The first is enforcement without a monitor period, because the rollout stalls on its first blocked request and nobody can reconstruct why the rule exists. The second is inventory without policy, which produces a good-looking report and changes nothing about what agents are allowed to do.

Where the model comes from

The levels and phases are the ones the five assessments already use, so a score and this page cannot disagree. The two control questions are the ones that separate a workflow people trust from a workflow people have automated and stopped watching.

Beyond the free tracks, Compass runs the same question packs as a coordinated assessment across an organization: contacts get their own dated instances, packs are assigned by scope and owner, and completion summaries report per division. Use the free tracks for your own read of one team, and Compass when the answer has to be the company's.

Frequently asked questions

Is agentic AI maturity one number?

No, and treating it as one hides the finding that matters. Workflow automation and control maturity are scored separately because they move independently. A team can be at level 2 in four workflows with controls at 0, and the useful output of an assessment is that sentence rather than an average.

What is the difference between level 1 and level 2?

Who triggers the work. At level 1 a person prompts the AI each time and checks the result. At level 2 an event triggers the agent, the agent completes the workflow end to end, and a person is involved only for exceptions and the actions designed to need approval.

Does automating more always mean maturing?

No. Level 2 without the controls in the right-hand columns of the summary table is a liability rather than a maturity step, which is why the assessments score the two control questions separately and name a gap for each one below the top score.

What controls should exist before moving to level 2?

Five: inventory of agents and MCP servers, written policy that can be enforced outside the model, a monitor mode you have actually run, an audit record that can be exported and verified, and approvals placed on specific high-impact actions rather than on every call.

Where does the model put monitor mode?

Between writing a rule and enforcing it. Monitor mode is how a team proves a rule decides what they intended on their own traffic, and it is the step most often skipped when a program tries to move up two levels at once.

How long does an assessment take?

The 20 questions are answered on the page, and the result appears when the last one is answered. Emailing the full report is optional.

Do the free assessments score the whole organization?

No. Each free track is a one-person read of one function: answer, see the result, keep it. Organization-wide scoring runs the same packs in Compass, with dated instances per contact and division-level summaries.

Get a full Alyria maturity assessment

Alyria assesses your agents and controls across functions using Compass, and delivers a scored maturity report and a roadmap. Talk to us about a full assessment and we will start with the functions that matter to you.

Start with the free track for your function: software development, security operations, procurement, customer service, financial operations. Each track opens on the same page, and the per-function pages carry the questions: software development, security operations, procurement, customer service, financial operations.