From Assisted to Autonomous: A Maturity Model for Agentic Development

How we are thinking about it on our enterprise platform

Across the industry, engineering teams running AI pilots are asking the same question: How much autonomy can we safely give an agent, and what infrastructure must be in place before we expand its scope?

Today, the bottleneck is rarely the underlying AI model; it is the platform the agent operates on. An agent cannot deliver high value if it cannot reach your codebase, runs on a developer's personal credentials, lacks a secure sandbox, or delivers into a manual review process designed for humans. Your return on Agentic AI investment is dictated entirely by your platform's maturity in orchestrating agentic workflows.

Four Maturity Levels Across Three Axes

We evaluate agentic maturity across three operational axes within the delivery pipeline:

Initiation: Who triggers the work? (A person, a platform rule, or the platform evaluating an objective).
Execution: Who writes the code? (A person or an agent).
Approval: Who authorizes the release? (A person, a platform policy engine, or the platform's encoded guardrails).

The journey through these levels is a progressive handover of trust and control, driven by continuous feedback. In reality, teams often advance these axes in different combinations—for example, delegating execution to an agent while keeping initiation entirely manual. However, these four defined levels represent the combinations that form stable, cohesive operating models.

Organizational Readiness Precedes Engineering Maturity

Before a platform engineering organization can put agents to work, the wider business must establish the necessary groundwork across AI strategy, security, data governance, and culture.

This article focuses strictly on platform engineering maturity—how effectively the pipeline integrates agents, and how it goes further responsibly. However, engineering maturity cannot exist in a vacuum; it is strictly bounded by organizational readiness. A single engineering squad can quickly build capabilities that outpace the rest of the company, but each technical leap requires a corresponding organizational mandate to authorize its use in production and unlock its actual business value:

To support Assisted engineering, the organization must formally approve sharing code and data with a model provider.
To support Delegated engineering, the organization must accept the security posture of agents acting in internal systems under their own agent identities.
To support Policy-driven engineering, the organization must align on which changes can auto-merge based on policy, and formally shift human approval up the chain to the overarching policy rules or batched release manifests.
To support Autonomous engineering, the organization must define the exact operational boundaries (the scope) where the platform can safely auto-deploy, and establish strict exception paths (such as mandatory human oversight for physical equipment) where it cannot.

When platform capabilities advance ahead of organizational readiness, the result is inevitably a security incident, a compliance violation, or an unexplainable change impacting a customer.

The Anatomy of the Four Levels

The following sections explore each maturity stage in detail. To provide a consistent framework, every level is broken down by its core mechanics: what it entails, who holds accountability, what the platform must provide, what the business must accept, and how to measure success.

However, regardless of the maturity level, one absolute rule applies: humans must remain in control.

Core Controls Required at Every Level

To enforce human control, three systemic guardrails must be established to begin with. Unless these prerequisites are met you are not ready for the next level, regardless of how sophisticated your AI tooling is. Additionally, each control must be robust as autonomy increases:

Halt and Revoke: Administrators must be able to terminate an agent, revoking its identity and model access within minutes. At the Assisted stage, this simply means cutting off tool access. By the Autonomous stage, it requires a global "kill switch" that stops all running agents while ensuring in-flight changes are safely rolled back.
Traceability: Every machine-authored change must be strictly attributable. The platform must record exactly which agent, model version, and task generated the code, alongside all pipeline validation evidence. This requires signed commits and attestations attached to the pull request so the change can be audited.
Rehearsed Rollbacks: Every deployed change must be cleanly reversible, and those reversal procedures must be routinely tested. From the Policy-driven stage onward, where changes can reach production without human review, rollback must be automatic and triggered by telemetry regressions.

Level 1 — Assisted (Developer-Driven, Agent-Assisted)

At this foundational stage, every task begins and ends with a human. The developer describes what they want, and the agent returns a strictly read-only output—either code snippets or explanations.

The agent operates entirely as an advisory tool. It creates no branches, modifies no files, and commits no code. Its output is merely a proposal that becomes real only if the developer manually incorporates it into their local repository.

In Practice: Level 1 is a way of working, not a dedicated role. It applies to product owners refining user stories, architects sketching options before a design review, and developers writing code. Common use cases include:

Prompt-Driven Generation: AI-assisted coding natively within the IDE.
Architectural Mapping: Granting the agent read access to the source code to auto-generate architecture diagrams.
Legacy Code Discovery: Prompting the agent to trace call paths, surface hidden dependencies, and reconstruct undocumented intent within a monolith.
Incident Triage: Using the agent to rapidly correlate traces, logs, and metrics during a service outage.

Who Decides and Who Is Accountable The developer decides what work happens, executes the work, and approves what ships. While the agent accelerates understanding and drafting, accountability for the final shipped code rests entirely with the human developer.

What the Platform Must Provide The platform team here acts as a facilitator in ensuring the teams have access to the right tools and models. They provide engineers and operations teams with access to approved models, enforce token budgets, track usage, and manage data-loss prevention (DLP) rules governing what can be pasted into a prompt. At this level, there is no agent identity, no isolated sandbox, and no structural change to how code is merged or deployed.

What the Organization Must Accept The investment at Level 1 is primarily organizational rather than technical. The business (Security, Legal, and Data Governance) must formally approve data-sharing contracts with model providers. Engineering cannot fund tokens or deploy IDE plugins until these external approvals are secured.

How to Measure This Level Success is measured by the adoption rate (share of engineers utilizing approved models) and cycle time reduction (specifically, the elapsed time spent on the context-gathering phase before and after AI adoption).

The critical limitation: While the gains at Level 1 are real, they are quite limited. Because a single developer must manually carry every change through the review process, throughput is limited by human bandwidth. The agent makes the developer faster, but it does not add net-new engineering capacity. Measuring these initial speed gains is essential, as they form the business case for advancing to Level 2.

Level 1 in Action: A Real-World Scenario

To illustrate how these controls function, we will track a standard software defect through to production. (Note: We will use this same scenario across all four levels to highlight how the operating model evolves).

The Scenario: An edge gateway collects readings from field devices and forwards them to the cloud. After a facility upgrade adds new devices, the increased telemetry load bottlenecks the gateway's synchronous I/O loop, causing dropped readings that require a fix.

Ticket Generation (Human): A customer reports missing data. A human creates a ticket and triggers the work.
Context Retrieval (Human + Agent): The developer asks the agent to analyze the gateway's codebase. The agent traverses the domain, logical services, dependencies, and flow, returning a text summary and a diagram. In large, long-lived codebases, this AI-assisted discovery phase often saves more time than writing the actual fix.
Implementation (Human + Agent): The developer writes the fix in their IDE. The agent suggests code completions; the developer accepts some, rewrites others, and continues prompting. The final proposed change exists only on the developer's local machine.
Validation (Automated CI): The developer manually pushes the code and opens a pull request. CI runs standard tests and security scans. If it fails, the developer fixes it and pushes again.
Promotion (Human): A human peer reviewer reads the diff. Existing merge policies dictate who has the authority to approve it.
Deploy & Observe (Human): The developer manually triggers the release, rolling it out to staging and then production. An engineer monitors the logging and metrics to confirm system stability.
Remediation (Human): If the new code breaks something, an alert fires and a human must manually respond to debug, roll back, or patch the gateway.

Level 2 — Delegated (Developer-Delegated, Agent-Executed)

At Level 1, the agent could only propose. At Level 2, it can act.

However, execution still begins with a human. A developer creates a ticket describing the problem, defines the acceptance criteria, makes the necessary scoping decisions, and references relevant Architecture Decision Records (ADRs). Once the task is defined and assigned, the agent takes over.

The agent autonomously creates its own branch, commits code, and opens a pull request. This triggers the CI/CD pipeline. If tests, security scans, or policy rules fail, the pipeline feeds the failure directly back to the agent, which iterates and pushes corrected code. Multiple agents can run in parallel on different tasks, each generating its own isolated branch and pull request.

Who Decides and Who Is Accountable The developer dictates the work and approves the release. At Level 2, developers evaluate the outcome against their original acceptance criteria using two inputs: pipeline validation evidence (tests, scans, automated reviews) and the agent’s own summary of the changes. The developer only inspects the raw code diff if the evidence reveals an anomaly. Until approved by the developer, the change remains isolated; nothing builds on it, and nothing ships.

Accountability rests entirely with the human developer. In regulated environments, the approving developer is the official approver of record. The commit retains both the agent's identity and the validation logs to ensure a complete audit trail.

The critical aspects here are clearly articulating the problem so the agent can derive the right context and act on it, alongside the quality of the test suites to ensure the developer requires minimal intervention. You can no longer rely on human intuition to catch bad logic. Your test suite has to evolve from simply checking if the build breaks to definitively proving the code fulfills the acceptance criteria. Whatever the tests miss, ships.

What the Platform Must Provide To safely delegate execution to an agent, the platform architecture must enforce strict boundaries:

Agent Identity: Agents must possess their own credentials, strictly scoped to the repositories, environments, and data required for the task.
Isolated Workspaces: Each agent must execute in its isolated environment to prevent concurrent agents from interfering with each other’s work.
Curated Context: The platform must automatically assemble the necessary context—relevant repository slices, Architecture Decision Records (ADRs), service definitions, and enterprise conventions. Without this, agents will continuously rediscover the same context and arrive at inconsistent conclusions.
Execution Limits: Hard caps on compute, runtime, and API costs must be enforced to prevent a stuck agent from spinning endlessly.
Strict Merge Gates: Agents must be forbidden from holding deployment credentials or pushing to protected branches. Their code is allowed to reach an environment only by passing through the repository's human-controlled merge gate.

What the Organization Must Accept At Level 2, agents act within your enterprise systems under their own identities. Because legacy access-management and change-control processes were designed for human employees, the organization (specifically IAM and Security) must extend governance to non-human identities. This requires establishing policies for issuing agent credentials, designating a named human owner accountable for each agent's actions, and defining exactly how agent-effected change is represented in compliance audits.

How to Measure This Level Success is tracked by evaluating the agent's reliability and its impact on human review time:

Agent-Authored Share: The percentage of total merged changes written by an agent.
Change-Failure Rate: The frequency of defects in agent-authored code compared to the human baseline.
Gate Rework Rate: How often a reviewer rejects the agent's pull request and sends it back for revision.

Level 2 in Action: A Real-World Scenario

The Scenario: A gateway is dropping device readings under load.

Assign Work (Human): The developer triages the ticket, defines the scope of the required fix, and assigns it to an agent. The platform issues the agent its scoped credentials and execution limits.
Retrieve Context (Agent): The agent reads the repository, ADRs, and service definitions. Unlike Level 1 (where it built context for a human to read), the agent now builds this context for its own internal execution.
Implementation (Agent): Operating entirely in the background, the agent drafts the code fix and opens a pull request.
Validation Loop (Agent): CI runs tests, security scans, and policy checks. If a run fails, the pipeline returns the error to the agent, which adjusts the code and pushes again until it passes.
Promote Change (Human): The pipeline runs green. This is the first time in the workflow a human looks at the code. The developer evaluates the pipeline evidence, judges if the fix is correct, and approves the merge.
Deploy, Observe & Remediate (Human): The developer triggers the release. Telemetry confirms the gateway is stable. If a regression occurs, an alert fires and an engineer handles it. (At Level 2, agents can now read telemetry, allowing them to validate their own changes—laying the foundation for Level 3).

Extending Level 2 to Platform Operations

Level 2 delegation is not limited to software engineering. The exact same model applies to operational workflows and infrastructure management.

Instead of opening a pull request on a codebase, an agent can prepare a complex firewall-rule request (complete with service routing, traffic flow, and justification), draft a private DNS record against the correct enterprise zone, or automate a certificate lifecycle request within your existing PKI workflow. In each scenario, the agent compiles and files the highly technical request, while the designated human approver simply reviews the evidence and clicks approve. The agent removes the exhaustive manual effort of assembling correct infrastructure requests, without bypassing existing security approvals.

Level 3 — Policy-Driven (Platform-Initiated, Policy-Approved)

In Level 2, the workflow relies on a human at the front of the pipeline. This person is accountable for contextualization (describing the problem, scoping, defining acceptance criteria), assignment to an agent, and final validation (ensuring the code fulfills the requested criteria).

In Level 3, these manual responsibilities shift to the platform.

The platform wires the agentic framework directly into your existing DevOps event streams, making the system event itself the trigger. The platform then handles contextualization (just as the human did earlier through Jira tickets) by spinning up a triage agent, before routing the compiled context to the appropriate execution agents.

Importantly, standard validation also shifts from the human to the platform. A policy engine evaluates the automated evidence against a set of strict conditions, dictating what merges automatically and what requires human intervention.

Because initiation and approval are decoupled mechanisms, engineering teams have the flexibility to adopt them independently.

Autonomous Initiation & Triage Level 3 eliminates the latency of human triage. When a trigger condition occurs (e.g., a failing dependency check, an operational anomaly), the platform immediately dispatches an agent to assess the impact and build the task context. This automates the most cumbersome bottleneck of the repair cycle. The platform then routes this context to an execution agent, which iterates on the code until it passes validation.

The Approval Matrix: Risk vs. Confidence Approval automation is governed by evaluating the agent's work across two dimensions:

Risk: The inherent impact profile of the task (Low, Medium, High).
Confidence: A dynamic trust score based on the agent’s historical success rate with similar tasks and the depth of the associated test coverage.

This matrix allows teams to progressively scale autonomy:

Initial Rollout: Low-risk changes auto-merge if confidence is high. Low-confidence or higher-risk changes route to an engineer.
Matured State: As trust in the agent builds, medium-risk changes with high confidence unlock auto-merge capabilities. High-risk tasks remain permanently gated behind human review.

Observability & Policy Governance Observability is the engine behind the confidence score. It provides the concrete evidence of past agent performance needed to justify autonomous merges. The policy owner uses this data to answer one calibrating question: which risk profiles and confidence thresholds qualify for auto-merge?

What the Platform Must Provide To establish Level 3, the platform must provide a rigorous set of automated controls:

A Deterministic Policy Engine: A dedicated service that evaluates the risk and confidence of every change. While a human defines the rules, the engine itself executes them. The engine must run under its own verifiable identity so that when it automatically approves a pull request, the audit trail explicitly shows the system that made the merge. For example, the Git history would read: "Approved by svc-policy-engine based on Rule v2.4."
Robust Validation Evidence: In Level 2, tests just provided information to help a human decide the 'merge'. In Level 3, the test results literally become the physical gate. The policy engine reads the cryptographically signed test output and decides if the code ships.
Progressive Delivery: Autonomously merged changes must never deploy to the entire fleet at once. They must roll out sequentially—starting with a canary slice and widening gradually—gated by the same telemetry used to evaluate the fix.
Automated Rollbacks: You cannot rely on users to report a bad release or humans to read an alert. The deployment controller must actively query your monitoring tools (e.g., Datadog, Prometheus) as it routes traffic to the canary slice. If the new code causes a metric regression—such as HTTP 500 errors spiking or ingestion latency exceeding the defined Service Level Objective (SLO)—the platform must instantly abort and revert the change without waiting for human intervention.
Agent Observability & Cost Controls: The platform must enforce limits on the compute costs of continuously running agents. Furthermore, it must provide granular data on how agents perform across different risk profiles—this is the exact telemetry policy owners use to safely graduate workflows from human-reviewed to fully autonomous.

What the Organization Must Accept At Level 3, code merges and progresses based on automated policies. This does not mean human oversight disappears entirely. In highly regulated industries, instead, human approval shifts up the chain: an accountable human approves the strict policy rules, the risk thresholds, or a batched release manifest.

As this shift heavily impacts regulatory posture, compliance audits, and customer commitments, delegating the approval authority to the platform is not solely an engineering choice but a collective decision involving platform leadership, security, and the broader business.

How to Measure This Level Success at Level 3 is tracked through the following core metrics:

Autonomous Merge Rate: The percentage of total changes merged without human intervention.
Mean Time to Remediation (MTTR): The lead time from anomaly detection to a deployed fix.
Comparative Escaped-Defect Rate: The volume of defects slipping through on auto-merged changes versus those passing through traditional human review.
Agent Unit Cost: The compute and API costs incurred per autonomous change.

The escaped-defect rate is the critical calibrating metric. It provides the empirical evidence the policy owner requires to either graduate a workflow to full autonomy or revert it back to mandatory human review.

Level 3 in Action: A Real-World Scenario

In this scenario, a service degradation is resolved before a customer ever notices—and without a single ticket being manually created.

Detect & Triage (Agent 1): A gateway begins dropping readings under heavy load, matching a predefined telemetry trigger. The platform instantly detects the anomaly and assigns it to a triage agent. This agent analyzes the logs to assess the impact and assembles the initial task context, automating the cumbersome investigation phase previously done by humans.
Dispatch & Context Retrieval (Agent 2): The platform uses that task context to determine which specialized execution agent should handle the fix. Once dispatched, this second agent ingests the repository, Architecture Decision Records (ADRs), and service definitions to build its localized working context.
Implementation: Operating entirely in the background, the execution agent drafts the code fix and opens a pull request.
Validation Loop: The CI/CD pipeline executes tests, security scans, and automated code reviews. If a check fails, the pipeline feeds the error directly back to the agent, which iterates and pushes a corrected commit.
Policy-Driven Promotion: The policy engine evaluates the pull request. In the case of a low-risk scenario, the policy would have auto-merged it. But because this scenario of altering gateway logic is classified as a high-riskoperation, the engine halts the merge and flags an engineer for manual approval.
Deploy, Observe & Remediate: The release rolls out to a canary slice. Telemetry confirms the gateway is stable, allowing the deployment to widen. Had the fix caused a regression, the platform would have triggered an automated rollback instantly, without waiting for an engineer to be paged.

Level 4 — Autonomous (Objective-Driven, Scope-Bounded)

At Level 3, the platform determined and assigned work based on pre-configured scenarios defined by a human. At Level 4, the platform takes on a much larger responsibility: managing objectives.

A human-defined objective is not just a list of known scenarios; it is a broad operational mandate—such as maintaining a service-level target, enforcing a security posture, or managing a cost envelope within a bounded context. At this scale, a single agent does not do it all. Multiple specialized agents collaborate and execute in an orchestrated manner to achieve the defined objective.

Agents continuously monitor for anomalies—across telemetry, customer behavior, security findings, and costs—strictly in the context of these human-set objectives. They make independent judgments about which anomalies threaten a goal, decide how to orchestrate specific tasks to ensure the objectives are met, autonomously open tickets, and prioritize them against everything else in flight to execute the remediation.

Importantly, because agents are not constrained by the human-capacity bottleneck, high- and low-priority optimizations run in parallel rather than competing for triage.

Who Decides and Who Is Accountable The platform decides what work is necessary to meet an objective, while humans decide where it is allowed to operate.

At this scale, autonomy does not mean individual agents making isolated decisions. The platform acts as the central orchestrator. When an objective is threatened, the platform analyzes the context and generates an execution plan. The policy engine evaluates this proposed orchestration against the human-defined boundaries. Only when the plan is validated does the platform dispatch the appropriate agents to carry out the work.

The most critical governance decision at Level 4 is defining these boundaries. This perimeter will never cover the entire enterprise. Once leadership defines this boundary, the platform governance team encodes it as strict technical guardrails.

Redefining Autonomy: 100% is Not the Goal Achieving anywhere close to full autonomy across an entire enterprise system is not a realistic target, and success at this level should never be measured by that parameter. Instead, autonomy must be measured strictly against a defined scope.

If an accountable executive targets 60% autonomous remediation within a specific domain, and the platform safely delivers that, Level 4 is achieved. The remaining 40% is not a shortfall—it represents deliberate, essential human control. This distinction is especially critical for enterprises whose software interfaces with physical equipment. In those environments, the designated share of human oversight will naturally remain large, and rightly so.

What the Platform Must Provide In addition to everything from Level 3 running continuously, the platform must provide:

Scope Enforcement: The boundary between autonomous operations and manual oversight must be enforced technically, not by convention. Agent identities must hold write access only within the permitted scope; outside of it, they may only suggest changes or open tickets for humans.
Guardrails as Code: Objectives, budgets, and operational limits cannot be mere guidelines. They must be encoded as immutable policies that the platform evaluates before every agent action.
Fleet-Level Halt: The "halt and revoke" control must evolve to stop every running agent instantaneously, ensuring all in-flight changes are either cleanly completed or rolled back.
Autonomous Learning Loops: When telemetry confirms an agent's fix was successful, the platform must automatically convert that failure pattern into a persistent validation rule, ensuring future changes to the same path are protected against regression.

What the Organization Must Accept The organization must accept a fundamental shift in how work originates: the platform will autonomously identify problems, write code, and orchestrate complex remediation plans without a human ever opening a ticket.

However, as established, this does not mean the platform blindly pushes changes to production. In highly regulated enterprises, the organization must formalize its exception paths. They must legally and operationally define the exact boundaries where the platform is allowed to safely auto-deploy, and where it must pause to present its fully orchestrated solution to a human for final release approval. For mission-critical systems—such as software managing physical infrastructure—defining these hard deployment boundaries is a profound governance question long before it is a technical one.

How to Measure This Level

Preemptive Remediation Rate: The percentage of anomalies the platform detects and resolves before they escalate into an SLO breach or trigger a human alert.
In-Scope Autonomy Rate: The share of orchestrated tasks completed autonomously within the defined boundary, measured against the executive target.
Scope-Bounded Rollbacks: The volume of unplanned rollbacks occurring within the autonomous perimeter.
Emergency Interventions: The frequency and root causes of the fleet-level halt control being triggered.

Level 4 in Action: A Real-World Scenario

The Scenario: No ticket has been raised, and no alert has fired. Nothing has actually broken yet. However, the platform is continuously monitoring the fleet against a human-defined ingestion latency objective. It notices gateway readings degrading slightly under a specific load pattern. Based on predictive analysis, this trend threatens the objective.

Detect & Orchestrate (Platform): Without relying on a predefined rule, the platform identifies the root causes threatening the objective and generates a multi-step execution plan. It prioritizes this plan against all other automated work currently in flight.
Scope Enforcement (Platform): The execution plan targets two areas for optimization: the cloud ingestion service and the gateway firmware. The policy engine evaluates this plan against the encoded guardrails. It determines the cloud service is inside the autonomous scope, but the firmware—which controls physical equipment—sits strictly outside the perimeter.
Execute Inside the Scope (Platform & Agents): For the cloud ingestion service, the platform dispatches multiple specialized agents in an orchestrated manner. They concurrently retrieve context, write the necessary code optimizations, and iterate through the validation loop until the objective is secured. The platform ships this change progressively without human approval.
Delegate Outside the Scope (Platform): Because the guardrails block autonomous changes to the gateway firmware, the platform halts that portion of the execution plan. It automatically generates a detailed ticket containing the root-cause analysis and routes it to an engineer to handle manually.
Learn & Adapt (Platform): Telemetry confirms the cloud-side optimizations stabilized the latency. The platform automatically converts the load-degradation signature into a new validation rule, ensuring future changes to this path are tested against it.

Summary

Across the four levels, the operating model shifts along three axes: who initiates the work, who executes it, and who approves the result before it ships.

Level 1 (Assisted): The developer initiates, executes, and approves; the agent merely accelerates understanding and drafting.
Level 2 (Delegated): The developer initiates and approves; the agent executes.
Level 3 (Policy-Driven): The platform initiates based on predefined rules; the policy engine approves most merges.
Level 4 (Autonomous): The platform continuously evaluates human-defined objectives, orchestrating multiple specialized agents to execute and promote changes strictly within a human-defined scope. While Level 3 is reactive (waiting for a threshold to break), Level 4 is predictive (resolving anomalies before they threaten the target state).

Progressing through these levels requires advancing two tracks simultaneously. You must build platform capability(agent identities, isolated environments, immutable validation, progressive delivery, and deterministic policies) while securing organizational readiness (security approvals, defined risk ownership, and business alignment on autonomous actions). Without organizational readiness, the business will not authorize the technical capability. Without platform capability, organizational readiness has nothing to govern.

Furthermore, three core controls remain absolute: the ability to halt and revoke instantly, absolute traceability for every change, and rehearsed rollbacks. If your platform cannot guarantee these guardrails at your current level, you are not ready for the next one.

Crucially, this maturity model is not a mandatory ladder for every system to climb. Different architectural domains justify different levels of autonomy. For mission-critical systems—such as software controlling physical equipment—much of the work will, and should, remain tightly coupled to human judgment.

Success is measured by how effectively agents operate within the scope you chose, not by the blind pursuit of total autonomy. Start where the risk is lowest and the gain is clearest, and let empirical evidence dictate how far you scale.

How This Relates to Other Maturity Models

The foundational four-level structure of this framework is adapted from the Agentic AI Model authored by Kaspar von Grünberg and Luca Galante, which ranks maturity by how far initiation and approval have moved away from human operators.

This article builds on their work in three specific ways: by formalizing the three-axis definition of a level (Initiation, Execution, Approval), by introducing the strict prerequisite of organizational readiness, and by defining Level 4 through a scope-bounded lens for enterprises whose software controls physical equipment.

It is important to clarify that this framework is not intended to assess an organization's overall maturity in adopting agentic AI. Models like Microsoft's Agentic AI Adoption Maturity Model serve that exact purpose, evaluating readiness across AI strategy, business value, governance, security, and culture.

This model focuses strictly on platform engineering readiness. It asks a single question: How much of the software delivery pipeline have you safely handed over to agents?

Organizational readiness and engineering maturity are measured independently, but readiness sets the ceiling for execution. An enterprise can possess formal governance, executive sponsorship, and measured business value while its platform maturity remains at Level 1. Conversely, a single engineering team can rapidly outpace the broader organization's policies. That latter scenario is the riskier direction; deploying autonomous capabilities without the corresponding organizational foundations inevitably triggers the security and compliance failure modes discussed earlier.

In short: use organizational adoption models to determine if the business is ready, and use this platform model to determine what the pipeline can actually execute.