TL;DR
- Enterprises are adopting agents faster than they are redesigning the work those agents will perform.
- The unit of autonomy is the delegation envelope: one actor, one goal, one allowed action set, one evidence contract, and one recovery boundary.
- Capability, delegated authority, and operating maturity are separate scorecards. A system that can perform an action has not automatically earned permission to take it.
- The goal is the minimum authority needed to improve a defined outcome, expanded only when the workflow can prove and recover from its work.
IBM found that 64% of 2,000 surveyed CEOs said fear of falling behind drives technology investment before value is clear. Another 61% were adopting AI agents and preparing to scale them, while only 25% of AI initiatives had delivered the expected return. Enterprises are chasing autonomy faster than outcomes.
That is why How autonomous should our AI be? is the wrong opening question. An enterprise does not have one autonomy level. A software-maintenance workflow can complete bounded work while a payment workflow requires approval for every consequential action. Customer service can resolve a routine request while legal review remains advisory.
The useful question is:
What outcome are we trying to achieve, how does the work produce it today, and what authority has each part of that workflow earned?
Start With the Outcome, Not the Agent
“Deploy an agent” is not a business outcome.
Reduce account-opening time. Resolve routine service requests without repeat contact. Cut invoice exceptions. Detect fraud before money moves. These are measurable outcomes. An agent is one possible actor alongside deterministic software, analytical models, policies, systems of record, and human judgment.
Task productivity is not workflow performance. An agent may draft an answer in seconds while the case waits two days for approval, or generate more code while review becomes the bottleneck.
McKinsey’s 2025 global survey found that 62% of respondents’ organizations were experimenting with agents, but only 23% were scaling an agentic system somewhere in the enterprise. In any individual function, no more than 10% reported scaling agents. Adoption, workflow penetration, and business value are different scorecards.
The outcome defines what “done” means, which decisions matter, what the agent may change, which errors are tolerable, when a person intervenes, and how success is measured. Without that sequence, autonomy becomes a technology objective detached from the work.
The Delegation Envelope Is the Real Unit
Authority lives in a delegation envelope: one actor, one goal, one allowed action set, one evidence contract, and one recovery boundary. Change any part and you have a different envelope. This is the unit that can be designed, audited, graduated, and revoked.
A workflow contains multiple envelopes at different levels. The same agent may hold advisory authority for a legal conclusion, bounded authority for assembling its evidence, and no authority to send the result externally. Calling the whole system “L3” hides the consequential boundaries.
Three scorecards must stay separate:
- Capability: What can the system accomplish, and with what reliability?
- Delegated authority: What effects may it cause without further approval?
- Operating maturity: Can the organization observe, constrain, audit, interrupt, and recover that delegation?
“The model can do it” answers only the first question. The levels below describe envelope scope, not corporate progress. There is no universal L1–L5 standard for enterprise agents; this is my design model.
| Level | What the envelope permits | Human responsibility |
|---|---|---|
| L1 — Advise | Analyze, draft, predict, or recommend. No material external action. | Performs the work and makes the decision |
| L2 — Per-action approval | One discrete action whose exact occurrence and consequential parameters receive explicit approval | Directs the action and reviews consequential parameters |
| L3 — Pre-authorized bounded workflow | A multi-step workflow whose class, boundaries, and evidence contract were approved in advance; individual runs are not separately approved | Approves the workflow class and its exceptions—not each step |
| L4 — Coordinating envelope | Sequences and selects among several already-bounded L2/L3 envelopes toward a defined outcome. Composed authority, not new authority. | Sets constraints, owns material deviations and cross-boundary exceptions |
| L5 — Continuing objective | Creates and revises its own plans toward a standing objective under policy, budget, and time limits | Sets strategy, prohibited actions, and revocation authority |
The L2/L3 distinction is when approval happens: each occurrence at L2, the workflow class at L3. L4 composes bounded envelopes; if the coordinator gains authority none of them had, the boundary has leaked. L5 is a horizon, not a target. The public sources reviewed for this article did not document a standing-objective envelope with self-revised plans under material consequence.
Enterprise Workflows Are Landing at Different Levels
The ranges below are my assessment of public evidence available as of September 2026—not a market standard or benchmark. I use ranges because the evidence does not support point estimates, and I label vendor claims, regulatory boundaries, and thin evidence.
| Enterprise workflow | Typical range | Basis, and its limits |
|---|---|---|
| Software engineering | L2–L3 | Vendor product claim: GitHub documents that its coding agent implements bounded changes and opens pull requests; humans retain merge authority. Documented capability, not measured adoption depth. |
| IT and employee service | L2–L3 | Vendor product claim: ServiceNow's platform announcement describes routine service workflows completing inside existing approvals. Marketing material; no independent outcome data. |
| Customer service | L2–L3 | Routine resolution is the most commonly reported bounded-completion case in the surveys cited above; exceptions stay human-owned. Vendor deflection figures are not comparable across firms; I do not rely on them. |
| Sales | L1–L2 | Weak evidence. No function-specific study cited. Inference from the ≤10% per-function scaling ceiling in McKinsey's survey plus the structural point that pricing and commitments are contractually binding. Hypothesis. |
| Marketing | L1–L2 | Observed adoption: BCG reports agent-led workflows remain a minority; campaigns operate inside approved briefs and budgets. |
| HR | L1–L2 | Observed adoption: employee service and onboarding advance. Regulatory boundary: employment decisions face EU AI Act high-risk obligations—a legal ceiling, not a measurement of practice. |
| Finance and accounting | L1–L2 | Observed adoption: reconciliation and close preparation advance; assurance readiness and material approvals remain limiting (KPMG). |
| Procurement | L1–L2 | Observed adoption: supplier analysis and low-value transactions advance; trust in autonomous decisions is the leading reported barrier (BCG). |
| Supply chain and logistics | L1–L2 | Observed adoption: agents generate and execute narrow plans; cross-network trade-offs typically remain planner-approved (BCG). |
| Risk, legal, and compliance | L1 | Observed adoption: research, review, monitoring, drafting, and evidence collection dominate (Thomson Reuters). Also subject to professional-responsibility limits. |
| Physical operations | L2–L3 in engineered environments only | Weak evidence. No study cited here covers robotics. Inference from the engineered-environment argument below: bounded robots operate where state and recovery are physically constrained. General-purpose physical agents are earlier. Treat as hypothesis. |
Three patterns matter. Engineering leads where evidence and rollback are executable. Regulated functions move more slowly because their actions carry legal or financial consequence. Maturity varies within every function because workflows expose different boundaries.
Why Software Engineering Moved First
Software engineering already had the control system for bounded delegation: machine-readable state, tests, sandboxes, granular permissions, reviewable diffs, independent approval, and rollback.
GitHub's coding-agent documentation—a vendor product description—maps cleanly onto the envelope. The agent evaluates an issue, changes code, runs tests, and opens a pull request. The pull request is the evidence contract; merge authority is the boundary. The agent completes a pre-authorized workflow without inheriting authority over the software outcome.
Other functions need equivalent controls: simulation instead of a branch, deterministic business rules instead of tests, action diffs instead of code diffs, task-scoped credentials instead of deployment access, and compensating transactions instead of rollback.
The ICLR 2026 Measuring Agents in Production study found that across 306 practitioners and 20 case studies, 68% of production agents executed at most ten steps before human intervention, 74% relied primarily on human evaluation, and reliability remained the leading challenge. Production maturity currently comes from bounded authority, not unrestricted action.
A Worked Example: Invoice Exceptions
The outcome is not “process invoices with an agent.” It is “resolve valid exceptions within one business day without an unauthorized posting or payment.”
An L1 envelope classifies the exception and assembles evidence. L2 requests missing documentation under a pre-approved rule. L3 resolves named exception classes below a financial threshold, while payment release remains separately gated. Each step records the source data, rule, and proposed change. Recovery means reopening the exception, reversing a provisional posting, and revoking authority when error thresholds are exceeded.
The envelope earns wider scope only when its goal, action set, evidence contract, authority history, and recovery boundary strengthen together. Widening authority without strengthening those controls is weak governance wearing a level number.
What Executives Are Actually Deciding
Deloitte’s 2026 State of AI research found that 74% of surveyed leaders expected moderate or extensive agent use within two years. Yet only 21% reported mature governance for autonomous agents, 30% were redesigning key processes around AI, and 84% had not redesigned jobs around it.
The gap is concrete: organizations want class-level autonomy before they have evidence contracts that make class-level approval safe. L4 compounds the problem across decision rights, data definitions, permissions, budgets, and accountability. The composition itself needs an owner.
McKinsey found AI high performers were 2.8 times more likely to report fundamental workflow redesign than other respondents—55% versus 20%. That is an association, not proof of causation, but it is a stronger maturity signal than agent count.
The operating sequence is simple: observe the workflow, let the system advise, approve individual actions, pre-authorize proven workflow classes, then coordinate bounded workflows. At each step, collect outcome and exception evidence, monitor drift, and demote or revoke authority when the evidence deteriorates.
The NIST AI Risk Management Framework asks organizations to map an AI system’s intended purpose, context, affected actors, objectives, and legal requirements. NIST’s February 2026 draft on agent identity asks how standards can support identification, authorization, auditing, and non-repudiation. My architectural implication is that agents should receive scoped, auditable delegation rather than silently inherit a person’s full access.
What’s Missing
The market has plenty of agent frameworks. It has fewer mechanisms for operating authority.
Business workflows still lack standard equivalents for tests, action diffs, merge protection, and rollback. Evaluations score answers while production risk lives in tool use, permissions, side effects, and exceptions. Weak human review becomes an approval button without enough context or power to refuse.
The missing layer is not another autonomy label. It is an authority lifecycle that defines the envelope, gathers evidence in simulation and production, graduates scope within explicit thresholds, monitors drift, and revokes authority when performance deteriorates.
So What
Ask which envelope you are designing: whose goal, which actions, what evidence, what recovery, and whether approval happens per action or per workflow class. Some envelopes should remain advisory permanently. Maturity is knowing which can move—and having a mechanism for moving them back.
Here is a bet that can be checked. By September 2028, enterprises publicly reporting durable financial outcomes from agents will be distinguished by workflow-level evidence infrastructure—action diffs, scoped credentials, compensating transactions, and named envelope owners—rather than by the breadth or autonomy level of their deployments. I also expect no credible public case of a sustained L5 envelope operating over material consequence by that date.
I am wrong if enterprises scale agent authority broadly and profitably without those controls, or if a standing-objective agent runs a consequential business objective with self-revised plans and holds up under audit.
The question I have not resolved is how much evidence a workflow should accumulate before it moves up one rung—and who should set that threshold when the benefits and the cost of failure fall on different functions.
