Agentic Development Platforms

Most analyst categories are defined by what belongs in them. This one is mostly defined by what does not.

Forrester's framing of agentic development platforms spends a striking amount of its energy on exclusions. ADPs are not general-purpose platforms for building any kind of AI agent. They are not application generation platforms that let business users and developers produce software through natural language prompts, vibe coding, and low-code tooling. They are software development platforms that use agentic AI to help engineering teams build software of every kind, from interfaces and application logic through to infrastructure and backends.

Those two exclusions are doing real work, because both of the excluded things are currently being sold to the same buyer under overlapping vocabulary. If you are trying to work out why three vendors that appear to do the same thing keep getting compared to different competitors, the boundary is the answer.

What actually sits inside the category

Start with what these platforms grew out of. AI coding assistants were the first widely adopted enterprise application of generative AI, and for two or three years the value proposition was straightforward: a developer types, the assistant completes, the developer accepts or rejects.

ADPs are what happens when that assistant stops being a single suggestion engine and becomes a system. Forrester describes the shift as coding assistants evolving into platforms that coordinate agents, manage context, and automate work across the software development lifecycle.

Three verbs in that description, each pointing at a distinct engineering problem.

Coordinating agents means more than one agent working on related pieces of a task, with something deciding who does what, in which order, and what happens when two of them touch the same file. This is a distributed systems problem wearing a developer tools costume.

Managing context means solving the constraint that actually limits agentic coding in a real codebase. A model can write good code against a well-described problem. Enterprise repositories are not well-described problems. They are hundreds of thousands of lines with undocumented conventions, three generations of architectural decisions, and a deployment process somebody explained verbally in 2019. Whatever mechanism a platform uses to give an agent the relevant slice of that reality is where most of the differentiation now lives.

Automating across the SDLC means the scope extends past writing code into review, testing, documentation, migration, dependency updates, incident triage, and deployment. Forrester is explicit that the market goes well beyond code generation even while code generation remains central to how these products are sold.

Why the exclusions matter

The first exclusion separates ADPs from agent-building platforms. Those are tools for constructing agents that will do something in your business, customer service, research, procurement, anything. The output is an agent. With an ADP, agents are the input and the output is software. Forrester places these in different functional planes of its agentic AI framework, with ADPs in the build plane alongside AI platforms.

The second exclusion is the sharper one commercially. Application generation platforms, the vibe coding and prompt-to-app tools, are aimed at people who are not professional developers, or at professional developers building something disposable. They optimise for getting from nothing to something that runs.

ADPs are aimed at teams maintaining software that already exists and will keep existing. That is a fundamentally different problem. Generating a working prototype is a demo. Making a change inside a system with eleven years of history, an on-call rota, and a compliance obligation is the job.

Confusing the two produces a specific and expensive failure. Tooling that is genuinely impressive at greenfield generation can be actively unhelpful in a mature codebase, because it produces volume that looks like progress and creates review burden that looks like friction.

The Agentic Development Platforms Landscape, Q3 2026

Forrester published The Agentic Development Platforms Landscape, Q3 2026 as its first formal mapping of this market, describing a fast-expanding vendor field and positioning the report as a way to understand vendor focus, compare deployment models and market presence, identify the use cases that matter locally, and build a roadmap from controlled pilots toward adoption across the whole lifecycle.

A Forrester Wave evaluation is planned for Q4 2026, which means scored positions and tiers do not yet exist for this category. Any vendor currently claiming analyst validation here is pointing at a Landscape, and a Landscape maps a market without ranking anyone in it.

At the time of writing, no vendor has publicly announced its inclusion, so there is no reliable public list of who is in the report. That will change quickly as analyst relations teams work through their announcement cycles, and it is worth revisiting the vendor set once they do rather than assuming the obvious names are all present.

The line in Forrester's framing that deserves the most attention is about where the market goes next. The next phase, in its assessment, will favour vendors that turn agentic development from a set of clever assistants into trusted software delivery infrastructure.

Trusted and infrastructure are both load-bearing. Infrastructure means something the organisation depends on rather than something individual developers opt into. Trusted means the organisation can explain what it did.

The counterargument worth taking seriously

There is a credible sceptical reading of this entire category, and it comes from the platform engineering community rather than from vendors.

The argument, made clearly in a piece from Fairwinds engineer Stevie Caldwell titled An Agentic Development Platform Is Just Your IDP Growing Up, runs roughly as follows. Platform engineering had barely finished settling on internal developer platforms before a new acronym arrived. Strip away the novelty and what changes is not the platform fundamentals but who uses the platform. Agents become goal-driven actors operating within the same constraints as humans. The infrastructure is still Kubernetes. The questions are still governance, policy, cost, reliability, and ownership.

The practical conclusion is that most organisations should extend the platform they have rather than building a parallel one for AI, because a second platform produces duplicate tooling, immature guardrails, unclear ownership, and two teams competing for the same budget and expertise.

This is not a rebuttal of the category so much as a warning about how to buy into it. Forrester and the platform engineering view actually agree on the destination, which is agentic development as governed infrastructure rather than as a collection of assistants. They disagree about whether getting there requires a new platform layer or a maturation of the existing one.

For a buyer, that disagreement is the most useful thing in this article. Ask any ADP vendor how their platform relates to the internal developer platform you already run. If the answer involves replacing it, you are being asked to fund a second platform team. If the answer involves extending it, you are having a more honest conversation.

What genuinely changes when agents are users

The thing that is actually new is small in concept and substantial in consequence. Agents deploy services, change configuration, trigger jobs, and consume capacity, and they do it faster and more often than people can.

That forces three shifts.

Agents need identities and scoped permissions, governed the same way as any other actor on the platform. A change made by an agent under a shared service account is a change you cannot attribute, and unattributable changes are the thing that makes incident review impossible.

Quotas, limits, and capacity planning have to account for agent runs rather than only human teams and conventional services. The illustrative failure is an agent permitted to create a GPU namespace on a platform with weak quota enforcement, producing an expensive namespace and bursty jobs that push a cluster into contention within minutes. That is not an AI failure. It is a platform design failure that an agent exposed faster than a human would have.

Observability and incident response have to distinguish human from agent. When something breaks, the first question is who changed what, and if the answer cannot separate the two, everything downstream degrades.

The uncomfortable implication is that these platforms reveal weaknesses rather than creating them. A team that does not trust its platform today will find that adding agents makes existing reliability and governance problems surface more often and with higher impact. The useful diagnostic is whether your platform is something an agent could use without constant supervision. If the honest answer is no, that is a platform engineering problem to fix before it is a procurement decision to make.

The constraint moves to review

One consequence of this category that gets less attention than it deserves: when generation gets cheap, the bottleneck moves to verification.

A team that could previously produce a certain volume of change per sprint was constrained by how fast people could write code. Remove that constraint and the next one is how fast people can review, test, and take responsibility for code they did not write.

This is why the SDLC-wide framing matters more than the code generation framing. A platform that only accelerates writing makes the review queue worse. A platform that also strengthens testing, produces reviewable change summaries, and can explain why it did what it did addresses the constraint it created.

It also raises a governance question that is genuinely unresolved across the industry. When an agent writes a change, who is accountable for it? In practice the answer is the engineer who approved it, which works only if that approval is meaningful. Approval stops being meaningful somewhere around the point where a person is reviewing more change than they can hold in their head, and nobody has established where that line sits.

Ask vendors about this directly. The good answers involve smaller change units, better test evidence, and clear traceability. The weak answers involve throughput metrics.

What to do before the Wave publishes

Run agents against your worst repository, not your best one. Every ADP demonstrates well on a clean, well-documented, modern codebase. The question that decides value is what happens in the fifteen-year-old service that generates most of your revenue and that nobody wants to touch.

Measure review load, not acceptance rate. Acceptance rate tells you the tool produces plausible output. Review load tells you whether the team is actually faster end to end, and those two numbers can move in opposite directions.

Establish attribution before scale. Decide now how an agent-authored change is identified in your version control history, your deployment records, and your audit trail. Retrofitting attribution after two thousand merged changes is unpleasant.

Treat the Landscape as a longlist and wait for the Wave if you can. Scored positions arrive in Q4 2026, and in a market moving this fast a shortlist built from a map rather than an evaluation is a shortlist built on vendor self-description.

And keep the commitment short. This category did not exist as a named market a year ago, the Wave has not published, and the boundary between ADPs, agent platforms, and application generation tools is still being negotiated in public. Anything you sign for three years is a bet on definitions that Forrester itself is still drawing.

Forrester does not endorse any vendor named here, and inclusion in a Landscape report is not a rating or a recommendation to buy.