Traditionally, platform engineering is the discipline of treating the production system of software as a product: something that requires constant refinement and optimization. The product platform engineers build and operate on is commonly known as an Internal Developer Platform (IDP), a term we coined in 2020.
The users served by the platform engineering team are, for now, software engineers. Much of this is about to change because of AI and, in particular, the rise of agents. Both represent the most significant changes the discipline has seen to date. Suddenly, we have a system that is faster and more capable of writing code than any human. This shift changes how we work, as well as the requirements for our platform.
Over the past year, Weave Intelligence tracked how enterprises adopt agentic development. The pattern is consistent. Organizations that treat AI coding tools as standalone add-ons see modest gains. Organizations that evolve their platform to support agents structurally are pulling away on a different curve. And that gap compounds every quarter.
The platform engineering community has spent nearly a decade refining the foundational platform architecture for software engineers. Today, we propose that this architecture must enter a new era. And we call it the Agentic Development Platform (ADP).
The starting point: The Internal Developer Platform
An Internal Developer Platform (IDP) is a product built by the platform engineering team to support recurring work in software development. It provides standard paths for the repetitive parts of specialist work, so developers can focus on judgment, craft, and decision-making.
The IDP does not own the creative work. It owns the coordination, compliance, and repeatability around it. For the past several years, it has served exclusively one primary user: the human software developer.
What changes with agents
Coding agents are not a new tool in the developer's editor; they are becoming actors across the entire software development lifecycle. When that happens, the lifecycle itself changes shape. The Software Development Life Cycle (SDLC) was designed around a human as the primary actor at every stage, including writing, reviewing, validating, and deploying. When agents participate in those same stages, the sequencing and triggers change, as well as the platform requirements. We call this the Agentic Software Development Lifecycle (ASDLC). It is what the SDLC becomes when agents are participants, not just tools. It is even fair to speak about them as users of the platform.
But here is the part most organizations miss. Rather than disappearing in the ASDLC, the SDLC becomes the harness. The deterministic infrastructure platform engineers have been building for years ( CI/CD pipelines, policy gates, identity management, security scans) is precisely what makes probabilistic agents safe to operate at enterprise scale. Without it, you get speed without control. Agents that generate output faster than any human, but with no reliable mechanism to catch what goes wrong. Organizations that build agentic development on top of a mature IDP get security, transparency, and governance for free, because the harness was already there. Organizations that reach for agents first and platform second will spend the next two years retrofitting the controls they skipped. In the mid to long term, a deterministic foundation is what makes agents trustworthy enough to do more.
At the most basic level, agents suggest code, and the developer approves it line by line. That looks like a better autocomplete, and it does not require any platform changes. But the moment agents start generating pull requests in parallel, the minute they start executing tasks in the background or initiating work based on observed patterns, everything about the platform must evolve.
The reason is structural. Agents behave surprisingly similarly to humans when interacting with a platform. They need identity and to consume paths. They need to operate within policy constraints, and they need environments, dependencies, credentials, and guardrails. They also produce outputs that must be validated before they become binding.
But agents also differ from humans in ways that matter enormously. They act fast. They act in parallel. They do not get tired, and they do not exercise judgment the way humans do. An agent that provisions 30 environments in parallel without cost controls will bankrupt your cloud budget by lunch. An agent that merges code without validation will introduce defects at a rate no human team could match.
So fundamentally, many of the assumptions we took when designing IDPs no longer hold.
What is an Agentic Development Platform (ADP)
An ADP is the evolved form of the IDP. It allows agents to operate securely and reliably to automate software development.
An Agentic Development Platform (ADP) is a platform built and operated by the platform engineering team that enables collaborative software development between engineers and AI agents. It provides the paths, interfaces, and guardrails that allow both humans and agents to work reliably at the autonomy levels set by the organization.
Where the IDP standardizes repeatable paths for humans, the ADP makes those paths consumable by agents. Where the IDP assumes a human triggers work and reviews output, the ADP supports a spectrum from human-triggered to fully autonomous execution.
The ADP consists of three layers, with tooling as the top layer. The same five planes platform engineers have been building for years, developer control, integration and delivery, resource, security, and observability, now face significantly greater demand. Agents can call tools repeatedly, in parallel, and at volumes no human workflow anticipates.
The middle layer contains the path definitions. Paths are what humans and agents invoke to get work done. Path definitions contain information about how the different parts of the ADP execute those paths when invoked. The definition is not the runtime. Execution is handled by the orchestrator in the agent infrastructure layer. Paths come in three types: probabilistic (agent-driven, LLM-led work verified by evals and humans), deterministic (pipeline-driven, repeatable and gated, the CI/CD lineage you already know), and hybrid (the loop pattern of probabilistic step, deterministic gate, loop until passes). The hybrid path is where the real productivity gains emerge. The mistake is to treat first-pass agent failure as a problem, rather than structuring the platform so that repeated runs against error-updated context converge on the correct result.
Paths are the operational backbone of the ASDLC, in the same way that pipeline stages are the backbone of the SDLC. Where a CI/CD pipeline defines what happens when code is pushed, path definitions define what happens when any actor, human or agent, initiates work anywhere in the lifecycle.
The bottom layer is agent infrastructure. This is the constant substrate that makes agents operable across the platform, covering seven components: identity, context, capability, execution, evaluation, security, and observability. Together, they answer the questions every enterprise must resolve before granting agents meaningful autonomy. These questions include who is acting, what they are allowed to do, what the agent knows, where it runs, whether the output is acceptable, whether the system is protected against misuse, and what happened afterward.
Deterministic paths run on the tooling layer alone. They predate the agent infrastructure and operate independently of it. This separation is intentional and does not diminish the agentic vision. Even in a fully autonomous manufacturing plant, humanoid robots would not replace conveyor belts or high-speed QA gates. The deterministic system is already proven and reliable. It is faster than any stochastic process could be for that class of work. You apply autonomy where judgment and adaptability create value. You keep determinism where determinism has a superior return. The same logic holds here. The agent infrastructure exists to make probabilistic and hybrid paths possible, making the ADP a true evolution of the IDP rather than a replacement for it. If you do not yet have a good IDP, forget building an ADP. Clean foundations must be in place first.
The four levels
The ADP does not need to be built all at once. How far it needs to evolve depends on the level of agentic maturity the organization is targeting. The four levels are, in effect, four versions of the ASDLC, each defined by a different role for the human across the lifecycle. At level 1, the ASDLC still looks much like the SDLC, with AI assistance layered on top. By level 3, it looks fundamentally different. is triggered by platform signals. Execution runs in the background and human involvement is exception-based rather than continuous. In our research published with Weave Intelligence, we differentiate four levels of agentic development by the degree of human involvement. Each level changes what the platform must provide.
Level 1: Human in the loop
Agents suggest, humans approve line by line. The developer remains the execution engine. Autocomplete, prompt-driven code generation, and agentic search for context retrieval.
What changes in the platform: The core platform continues to work as before, but there is meaningful work to do in making organizational knowledge machine-consumable. Codebase access, documentation, and architectural guidelines need to be structured so models can retrieve and use them reliably. Many enterprises are at this stage today.
Level 2: Human on the loop
Agents generate pull requests in parallel. Humans trigger the work and verify behavior rather than inspect every diff. This is the first real parallelization.
What changes in the platform: A new path appears. Dispatch work to agents becomes a first-class capability of the platform. The platform must now manage agent identity, allocate sandboxed environments per agent session, enforce resource limits, and provide validation loops.
Validation is the critical shift. At level 1, the human validates each line. At level 2, validation becomes a loop. The agent generates output. The platform runs automated checks, including tests, security scans, policy evaluation, and behavioral assessment. If the output fails, the agent retries within the same session. The human reviews aggregate results, not individual diffs.
This is the hardest jump for most organizations. It requires rethinking what "code review" means when the unit of work shifts from a single PR to a batch of agent-generated changes.
Level 3: Human as orchestrator
Agents execute long-running paths in the background. The platform itself can generate work from observed patterns. Human review becomes exception-based. Promotion becomes rule-based for low-risk changes.
What changes in the platform: The platform needs to support background execution with robust state management. Agents must be able to pick up where they left off. The platform must distinguish between changes that can auto-promote (low risk, high test coverage, matching established patterns) and changes that require human review.
Observe-to-act patterns emerge. The platform monitors signals, like a failing dependency check or a security advisory, and dispatches agents to address them. The human defines the rules, the platform executes.
At this level, the constraint shifts from developer review bandwidth to architectural maturity and cost management. Token economics has become a real concern. The platform must track and govern agent compute costs alongside traditional infrastructure costs.
Level 4: Fully autonomous (outlook)
Agents monitor environmental signals and initiate paths autonomously within predefined guardrails. Humans define constraints, strategic direction, and escalation boundaries. The production system becomes self-adjusting.
What changes in the platform: This is the horizon. We are observing early signals but not yet broad field evidence. The platform at this level would need to support fully autonomous planning and execution, along with self-correction within boundaries that the organization can reason about, audit, adjust, and govern. We frame this as a projection, not a prescription.
What to do now
If you are leading a platform engineering team, focus on three things.
First, assess where you are. Most enterprises are at level 1. Some are making the jump to level 2. Knowing where you are is the prerequisite for knowing what to build next. The self-assessment we are publishing alongside this piece can help.
Second, start building the ADP capabilities for level 2. The dispatch path, the validation loop, agent identity management, and sandboxed environments. This is the hardest jump, and it is where the throughput gains become real.
Third, follow the work. Over the coming weeks, Weave Intelligence will publish practical transition guides for moving between levels and deep dives on the expanding scope of platform engineering. Platform Engineering Consulting is busy building ADPs across industries and can help you, too.
The structural shift underway in software engineering is not incremental. The organizations that redesign their platforms now will operate on a different curve from those that layer tools onto existing architecture. That is the opportunity platform engineers are uniquely positioned to capture.
The Weave Intelligence whitepaper The four levels of agentic software development in the enterprise provides the full research foundation for the levels framework referenced in this piece. The self-assessment How ready is your platform to safely run agents? is available as a companion to this post.