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 is the evolved form of the Internal Developer Platform (IDP), designed to make platform paths executable by agents at scale. It provides the paths, interfaces, and guardrails that allow both humans and agents to work reliably at the autonomy levels set by the organization.
Figure 1: Agentic Development Platform end-to-end reference architecture with three layers: Tooling, path specifications, and agent infrastructure.
It’s been six years since we proposed the reference architectures for Internal Developer Platforms (IDPs). Since then, they’ve been downloaded over 250,000 times and have acted as the reference for many platforms (see latest versions of AWS, Azure and GCP). The revised guidance on ADP has been developed with this responsibility in mind, but is subject to change and constant iteration. We continue to build and assess platforms using these approaches and will revise as new insights emerge. Especially at the speed at which AI technologies are developing, this feels imperative. Note that our architectures are intended for enterprises with meaningful estate sizes, typically 50+ developers. If your instinct is “this feels like overkill,” you’re probably right, and you should ignore this architecture. Overautomation can hurt your productivity, too.
Final note on the naming. We call this “Agentic DevelopMENT Platforms” because we are increasingly observing business users vibe-code applications using advanced ADPs. We believe these user groups will account for a significant part of the user base going forward.
Three layers of an ADP
An ADP consists of three layers, and the interesting property is which of them change.
Tooling is the top layer: the internal developer and domain platform, the tools work actually runs on. Path specifications sit in the middle. They tell agents what to do and how to find their way around. Agent Infrastructure is the bottom layer: how agents do enterprise work, how that work is governed, and the models it consumes.
Work hands down and back up. Tooling hands work to Path specifications, and Path specifications hand work to Agent Infrastructure.
Here is the part that matters. Tooling and Path specifications swap per vertical. Agent Infrastructure never changes. A sales organization and an engineering organization need completely different tools and completely different paths, but they need identical machinery to run agents safely. That invariance is the core thesis: one base platform, many verticals.
One point worth clarifying upfront: deterministic paths run on Tooling alone. They predate the Agent Infrastructure and continue to operate independently of it. Agent Infrastructure exists to make probabilistic and hybrid paths possible. This makes the ADP a true evolution of the IDP rather than a replacement for it. If you don't yet have a good IDP, forget building an ADP. You need those clean foundations first.
The tooling layer
The top layer is the muscles of the ADP. For the development vertical it consists of the five planes we proposed for structuring the reference architecture for IDPs, rendered as the historical IDP flow. The Observability plane sits above as a top strip, the Security plane below as a bottom strip, and work flows across the middle from the Developer control plane through Integration & delivery to Resources.
Figure 2: Zoom in on the Tooling layer, showing the five planes: developer control, integration & delivery, resource, security, and observability.
These are largely the tools platform teams have been building and curating for years. What changes is the demand placed on them. Agents call tools repeatedly, in parallel, at volumes no human workflow anticipates. Tools designed for deliberate sequential human interaction need to evolve with reliable APIs, predictable rate limits, structured outputs, and clear failure modes. Platform engineers must make that case to vendors and internal teams alike.
Building on the guidance we've always given on IDP design, configuration as code remains non-negotiable at enterprise scale. The tooling layer is backed by Infrastructure as Code (IaC): declarative configuration for every tool, defined in files like `backstage.yaml`, `pipelines.yaml`, `terraform/`, and `policies/`. It's the same discipline platform engineers have been practicing for years.
The path definitions layer
Platform engineering has always been about paths. The term was first coined by Charity Majors, and we've built on it ever since, because it's a brilliant way of thinking about what platforms actually do. A path is a valuable way for a user to achieve an outcome and progress along a value stream. While shipping a feature is a value stream, examples for paths could be creating an ephemeral environment, raising a PR, running a security scan, and deploying to production.
Figure 3: Zoom in on the Path Definitions layer, showing the three path types: probabilistic, deterministic, and hybrid.
In an ADP, paths become more important, not less. Because if you think about it, an agent is simply another type of user. Agents join the fun circle of building platforms with many of the same operational needs as human users. They too need good documentation, well-designed interfaces, and clear capability boundaries to operate safely.
Path definitions describe how the different parts of the ADP execute a path when it is invoked. The definition is not the runtime; execution is handled by the orchestrator in the Agent Infrastructure layer. Paths themselves come in three types:
Probabilistic paths are agent-driven. The LLM does the work and outcomes are verified by evals and humans. An agent reviewing a pull request, drafting a first-pass spec from a ticket, or generating release notes from merged changes are all probabilistic paths. The definition specifies the LLM-driven steps, the eval criteria, and the human verification points.
Deterministic paths are pipeline-driven. Platform engineers have been building them forever. Repeatable, gated, codified. CI builds, security scans, deployments, policy gates, promotions. These are exactly the paths your IDP already runs. The definition describes the repeatable steps, gates, and promotion rules the CI pipeline will execute.
Hybrid paths combine the two in a loop pattern. A probabilistic step produces a candidate, a deterministic gate evaluates it. The loop continues until the gate passes. An agent proposes a change, the pipeline validates it, failures route back to the agent, the agent retries. This loop pattern is where the real productivity gains and accuracy come from. The mistake is to assume it's problematic if an agent fails on the first run, rather than structuring the platform so that repeated runs against error-updated context converge on the correct result. This is similar to finding the global maximum of a function in basic algebra.
Figure 4: Outcome quality across agent attempts over time, showing how failure routes back as feedback until the gate passes.
The Agent Infrastructure layer
Agent Infrastructure is the constant substrate of the ADP. It is the scripts and infrastructure that run agents, tune agent behavior, supply context and memory, define guardrails, and govern how humans and agents communicate. As with Tooling, we need to differentiate the actual infrastructure from its representation as code. We call this practice Agent Infrastructure as Code (AIaC). Platform engineers who already practice IaC will recognize the pattern. Same discipline, expanded scope, and absolutely vital for recoverability, auditability, and all the usual benefits of "as code" approaches.
Figure 5: Zoom in on the Agent Infrastructure layer
The layer answers three questions. How do agents do the work? Who is allowed to do what, and what gets observed? And what intelligence is being consumed? Those are the harness, governance, and models.
The harness: how agents do the work
Above the harness planes sits the agents themselves: Cursor, Codex, Antigravity, Claude Code, Open Code. Beneath them, four planes.
Execution covers orchestration, gateways and routers, and the runtime or sandbox the agent works inside. Sandboxing matters more than it sounds, because parallel agent runs that share a workspace collide. This is where autonomy becomes real, and where the risks of runaway agents are either contained or left unchecked.
Context covers the service graph and ontology, search and retrieval, and memory and state. These foundations are vital because agents without sufficient information do not fail loudly. They proceed on incomplete assumptions.
Capability covers protocols, tool gateways, contracts and registries, and interop. At this point much of the existing IDP capability estate carries over. If your organization has already built mature infrastructure paths, they are exposed here for the agents to use.
Evaluation covers agent-output evals, goldens, rubrics and replay, and change-safety gates. Eval frameworks are the new test frameworks. This is what separates a platform an organization can trust from one it can only hope works.
Governance: who is allowed, what is observed
Governance is the fleet half, and the part you never build per agent. Building it per agent is how you end up with an estate you cannot audit.
Identity covers workload identity alongside human identity and secrets. Agents can be understood as another type of user, and every user requires clear authentication and authorization to act within defined permission boundaries. Agents must be credentialed, their scope bounded, their budgets constrained, and their egress controlled.
Agent security covers output guardrails, compliance and posture, and DLP and allowlists. Note the qualifier. This is not the Security plane in Tooling, which scans code. This governs what an agent is permitted to emit.
Agent observability covers traces and telemetry, agent-specific signals, and audit and cost attribution. Again, distinct from the Observability plane above, which watches production applications. This watches agents.
Models: the intelligence being consumed
Models sit as a full-width strip beneath both buckets, because both consume them. Three categories. Providers are the frontier and open model vendors. Inference endpoints are managed APIs, billed per token. Model hosting is deploying and running models yourself, whether on managed platforms or on raw accelerator capacity.
Treating this as a plane rather than a procurement decision is the shift. Left unowned, every application team solves model access, routing, and cost attribution independently for its own workload, and governance fragments accordingly. Routing sits in Execution, budgets in Identity, cost attribution in Agent observability. The models strip is what all three point at.
How a path actually runs
To make this concrete, we walk through what happens when an agent runs a probabilistic path like `/pr-review`.
A developer opens a PR in GitHub. Because we're good citizens, the change is linked back to the Backstage catalog and a Linear ticket. That's what triggers the path. GitHub fires a `pull_request` webhook, and the agent platform routes the event to the named `/pr-review` specification.
Something must execute it. That something is the orchestrator, in the Execution plane. In our reference stack, that's LangGraph, a workflow engine that sequences steps, manages state between them, handles retries, and persists progress. It's important to be precise here. The orchestrator does not think; it walks a graph. The reasoning happens inside the LLM nodes the graph contains, and the model's output can drive which edge gets taken next. That's what makes the path probabilistic rather than deterministic. The orchestrator is structurally similar to Temporal or Argo Workflows, except some of its nodes are allowed to be LLM calls, and those calls are allowed to influence control flow.
The run needs an identity. The agent assumes a workload identity scoped to that repository, with short-lived tokens issued by Vault or equivalent. Identity must bind first, because nothing further can be authorized without a principal.
With identity bound, the run resolves capability. The tool gateway looks up which tools this identity is entitled to call (`gh`, `jira`, `lint`, project tests) and surfaces them over MCP. Capability has to come before any tool use, including retrieval, because retrieval itself often goes through the gateway.
Now the harness assembles context. The service graph and memory layers recall the repo's conventions and Architecture Decision Records (ADRs). The agent fetches the diff, prior reviews, and CI artefacts. With the working set loaded, the agent invokes its tools, runs lint, runs tests via Semgrep, Snyk, and the project's own suite, and synthesizes inline plus summary review comments grounded on the diff and that context.
Then evaluation. An eval node scores the draft against goldens and a rubric (grounding, completeness, tone) using LangSmith or Braintrust. Change-safety gates decide whether it may proceed. Governance scrubs on the way out: output guardrails strip secrets and policy violations on the egress path. Only then does the review get posted back to the PR.
Afterwards, agent observability captures the trace. The OTel span, cost, tokens, latency, and pass or fail outcome are all recorded and attributed. Application performance monitoring picks up any reviewer-merge regressions later, and the result lands with the human reviewer, who signs off on the evidence rather than re-reading the diff.
That single path exercises the whole layer. The harness does the work: context, capability, execution, evaluation. Governance holds the boundaries: identity at the start, agent security on the egress path, agent observability throughout. Models supply the inference all of it depends on. You can do all of this with Claude Code on a laptop without any of this infrastructure, and you should, because that's how you learn the shape of it. But not at enterprise scale. At scale every one of these planes must exist, be defined as code, and be owned by the platform engineering team. Otherwise it won't be possible to meet the security, audit, and quality requirements of modern enterprises.
The ADP grows with the level of autonomy you grant
The maturity your ADP requires depends on where your organization sits on the maturity curve. In our research on the four levels of agentic software development, we define each level by the changing role of the human across the feature development value stream, from human-in-the-loop at Level 1 to full autonomy at Level 4.
Figure 7: The four levels of agentic software development
At **Level 1, human in the loop**, agents suggest and humans approve line by line. The developer remains the execution engine, so gains are linear. Agent Infrastructure can be minimal. Most paths are still deterministic, with a handful of experimental probabilistic paths appearing at the edges.
At **Level 2, human on the loop**, agents generate pull requests in parallel. Humans trigger work and verify behavior rather than inspect every diff. This is the first real parallelization, and it is where validation stops being a one-pass gate and becomes a loop. Identity, sandboxing, evaluation, and agent security all become non-negotiable. A new path type appears here too: Dispatch Work to Agents, which converts a human-directed assignment into a governed agent work item with bound identity, assembled context, and explicit scope. That is a specification with inputs and outputs, not an informal handoff to a bot.
At **Level 3, human as orchestrator**, the full substrate must be operational. Agents execute long-running paths in the background, the platform manages state and picks up where sessions left off, and human review becomes exception-based. Critically, this is where the platform starts generating work from signals rather than waiting for a human to trigger every path. Hybrid paths become far more common. This is also where token economics stops being an afterthought, because every loop iteration consumes budget and cost per accepted output becomes a metric you manage deliberately. This is where most forward-thinking organizations will be a year from now. The platform I work with every day is at Level 3 90% of the time.
**Level 4, human outside the loop**, is where agents initiate and execute paths autonomously within guardrails, and humans define constraints and escalation boundaries rather than approving work. Signal-driven execution becomes the dominant trigger: a vulnerability is detected and remediated, a customer call transcript mentioning a frontend bug results in a fix. Signal management becomes its own discipline. We should be clear that Level 4 is a projection of where this is heading rather than settled practice, and the failure mode is predictable. Organizations that attempt Level 3 with a Level 1 substrate will find their agents running faster than their guardrails can keep up. Autonomy without governance is not ambition, it's recklessness.
You don't need to build everything today, but you need to know what the next level demands before you attempt the transition. The most common failure mode we see isn't models that cannot perform. It's a platform unable to deal with the complexity of at-scale agentic operation.
Which points at the thing worth ending on. The gain here is not one agent going faster. It is many agents running parallel paths at once, and that is throughput rather than speed. Throughput is a property of the platform, not the model. A faster model does not give you parallel governed execution; identity, sandboxes, gates, and observability do. So the competitive dynamic is a throughput race rather than a model race, and the gap compounds every quarter on platform quality. Our upcoming research will double down on the Agent Infrastructure layer to dissect the nuts and bolts, and cover in detail how to transform your current setup into a scalable ADP step by step. The organizations that move on this early will not just ship faster. They will operate on a different curve entirely.
Disclaimer: In this article, we mention representative vendors for certain categories. Weave Intelligence doesn’t endorse any vendors, and the mentions are purely illustrative.