Labs

The sliding scale of autonomy

Written by Intevity | Nov 10, 2026, 8:59:40 PM

We recently wrote about the AI maturity curve, the five levels that describe how deeply AI is integrated into your architecture. If you read it, you might reasonably assume that autonomy is just the top of that same ladder. Get mature enough, and the AI eventually runs on its own. But it rarely works that way, and assuming it does is one of the more expensive mistakes we see organizations make.

Autonomy is a different ladder. The maturity curve measures how much of your stack is built for AI. Autonomy measures how much decision-making authority you’ve actually handed the AI once it’s built. Those are different questions with different answers, and an organization can sit high on one and low on the other entirely on purpose. Confusing the two leads to organizations either handing over control they shouldn’t, because they think maturity requires it, or holding back capability they’ve already paid for, because they think autonomy is automatic. Both are costly, and both are avoidable.

Five settings, from manual to full autonomy

Where the maturity curve runs from ad-hoc to integrated, the autonomy scale runs from manual to fully autonomous, and it describes something else: who is in charge of any given decision.

The scale describes what people do at each setting. Nothing on it says what the technology is capable of.

L0: Manual. Humans do everything. AI isn’t in the loop. Still the correct setting for plenty of high-stakes decisions, and worth saying out loud, because “some things should stay manual” is a legitimate position, not a failure to modernize.

L1: Assistive. AI suggests, drafts, and summarizes, and a human approves every action. Risk is near zero because nothing happens without a person signing off. This is the “faster horse” stage: useful, but the human is still doing all the deciding.

L2: Human in the loop. AI executes within narrow, explicit bounds, and a human reviews the exceptions and the high-risk cases. Guardrails are defined up front. This is where most enterprises operate today, and for good reason. It takes real work off people’s plates while keeping a person on every high-risk decision.

L3: Human on the loop. AI acts autonomously most of the time, and humans monitor dashboards and intervene when something looks wrong. The exception rate is low enough that watching is a viable job where approving each action would not be. The shift from “in the loop” to “on the loop” is the biggest jump on the scale, because it’s the point where humans stop approving individual actions and start supervising a system.

L4: Full autonomy. AI owns the workflow end to end. Humans focus on strategy and system design, and oversight is policy-based rather than case-by-case. Real, appropriate for bounded and well-understood domains, and further from most enterprise reality than the demos suggest.

Read across the scale, from assist to constrained execution to monitored autonomy to policy-driven autonomy, and each step changes what humans do, not what the technology can do. The maturity curve doesn’t capture that.

Why the level is a decision, not a destination

The maturity curve has a right direction. Higher is generally better, because a more integrated architecture is more capable, and the levels below are prerequisites for the levels above. You want to climb it.

The autonomy scale has no such arrow. Higher is not better. Higher is just more delegated. The right level of autonomy depends on what you’re willing to be wrong about, and how expensive being wrong is. For a system that recommends internal knowledge-base articles, L4 is fine, because the worst case is a bad suggestion. For a system that moves money, touches patient data, or makes decisions a regulator will later audit, L2 might be the mature choice, and staying there deliberately is a sign of good judgment, not timidity.

The dial is set per use case. The same platform can run one workflow at L4 and the next at L2, and both settings can be correct.

Vendors distort this. The commercial incentive is always to sell the most autonomous thing available, because autonomy demos well and sounds like the future. But autonomy you can’t govern isn’t an asset, it’s a liability with good marketing. The organizations that get this right treat the autonomy level as a dial they set per use case, based on risk, not as a destination they’re racing toward.

The two axes together

Put the two scales on separate axes and the whole picture resolves.

Architectural maturity runs one way: how much of your stack is built for AI. Autonomy runs the other: how much authority you’ve delegated once it is. Every AI system in your organization sits somewhere on that grid, and the interesting positions are the corners.

Three of the corners are legitimate for the right workload. Only one is a mistake for any workload.

Low maturity, high autonomy is the danger corner. You’ve delegated authority to a system your architecture can’t support or observe. This is the autonomous agent running on ungoverned data, making decisions nobody can trace. It feels advanced while it accumulates risk.

High maturity, low autonomy is where the most sophisticated organizations deliberately live for their high-stakes work. The architecture is fully capable of more, and they are choosing, consciously, to keep a human on every consequential decision. That is not underuse. That is governance.

High maturity, high autonomy is appropriate, and only appropriate, for bounded domains where the cost of an error is low and the system is mature enough to be fully observable. It’s a fine place to be for the right workload and a reckless place to be for the wrong one.

A mature AI organization doesn’t live in any single corner. It knows which corner each of its systems is in, and it put each one there on purpose. Maturity tells you what you’re capable of. Autonomy tells you what you’ve chosen. Doing both deliberately, per use case, is what separates an AI program that compounds value from one that just accumulates exposure.

Knowing where you stand

The maturity curve answers “what are we capable of.” The autonomy scale answers “what have we actually handed over.” Neither answer is useful without the other, and most organizations can state the first far more confidently than the second.

That second question is harder than it looks, because delegated authority tends to accumulate quietly. A system gets a little more latitude, then a little more, and no one revisits whether the guardrails still match the risk.

No single step here looks like a decision to raise the autonomy level. Together they are one.

Knowing, at any given moment, exactly how much autonomy each of your AI systems has, and whether that still matches the level you intended, turns out to be its own engineering problem.