How Is Platform Engineering Evolving with AI — and What Is an Agentic IDP?

Platform engineering was born from a scaling problem. DevOps asked every product team to own its own infrastructure — and at scale, that meant every team carrying the full cognitive load of Kubernetes, Terraform, pipelines, and compliance. The industry’s answer was to centralize: stand up a platform team, build an Internal Developer Platform (IDP), encode golden paths, and give developers self-service. Analysts told enterprises to fund it, and most did. But walk into a typical organization today and you will find that the platform team is largely the DevOps team renamed — because building a real IDP, with shared state, RBAC, audit trails, deterministic execution, and multi-engineer coordination, is a multi-year software project that platform teams were never staffed to deliver. The golden paths stayed on slides; the tickets kept flowing.

Now AI has entered the picture — though unevenly so far. The one segment where agents have made a real mark is troubleshooting, where AI SRE platforms are gaining traction. Across the rest of the platform engineering landscape — deployments, release management, access control, compliance controls — AI’s impact has been marginal. The most widely adopted AI solution in Platform Engineering today remains the coding assistant: a tool that improves an individual engineer’s productivity, as opposed to a platform that is centrally leveraged by all. There is still nothing about which one could say: with this in place, the traditional labor needs of platform engineering have reduced substantially. Yet AI has changed the economics of the original promise. The IDP that teams could never afford to build is, for the first time, becoming buildable — not as a portal of golden paths, but as an Agentic IDP: an Internal Developer Platform where every workflow is delivered as an agent. (We have also written about this thesis from the practitioner’s angle: What Is a DevOps Agent Platform?)

Before we discuss what an Agentic IDP is, let us first define the platform engineering problem itself — and what an agent even looks like to its end user.

What is the platform engineering problem — and what does an agent look like?

Platform engineering is a unique discipline: an endless stream of custom workflows. Team A’s release workflow, Team B’s environment provisioning, Team C’s incident runbook — every one of them bespoke, encoding conventions and judgment specific to the organization. But look inside these workflows and a pattern emerges: roughly 70% of what each one does is the same functions, over and over.

An agent that solves the above problem needs three core functionalities: (a) a Claude-like chat interface; (b) rich, use-case-specific UX and workflows that include forms, validations, dashboards, and views; and (c) the ability to intelligently combine AI and token-less workflows for each functionality. For example, use a skill to put together an ephemeral environment — but to restart a pod, the agent should just call an API, with no tokens spent. The following picture shows the anatomy of such an agent.

What is already solved by Claude Code

Part of the problem statement described above is already solved — by engineers, within the scope of their Claude Code session. An engineer can build a personalized agent that inherits Claude’s chat interface out of the box, and combine it with skills pointing at existing tools: Terraform, Jenkins, Kubernetes, the observability stack. What they don’t implement is any UX, APIs, or token-less workflows — and none of the multi-user, governance, or enterprise controls — because this is a personalized agent: one user, one laptop, one session. The implementation looks like the picture below.

The question most organizations then ask is: are we good with all engineers implementing their own bespoke agents for shared use cases — with access to sensitive systems and no enterprise controls — or shall we move to a centralized agentic platform model?

Enterprise Maturity Spectrum

How organizations adopt AI in platform engineering follows a maturity spectrum — three stages that move with the scale of the organization:

The vast majority of organizations today are still at stage one, a few have begun building centralized agents at stage two, and stage three is a phenomenon of larger enterprises who can afford to dedicate software development teams — as against just platform engineering — because this involves SaaS as well as distributed systems skill sets. Given how prevalent the problem is, there are ISVs building solutions that teams can leverage.

Building an Agentic IDP: The Gist of It

At a high level, the concept is to implement a system which is a combination of a Common Platform on which each use case is a custom app, plus a coding assistant that is specialized to build these apps by understanding what needs are fulfilled by the platform and what needs to be built. The coding assistant enforces standardized implementation across apps in such a way that each one is plug-n-play and is sandboxed from others. All apps inherit the capabilities of the platform. There are two personas this system caters to: first, the users who use the agent to accomplish their use cases; and second, the agent builder who automates their use case using the coding assistant. The coding assistant is nothing but a Claude plugin.

Detailed Implementation: DuploCloud Platform

We at DuploCloud have implemented one such Agentic IDP. We have written in detail about our implementation, along with some demos. We hope this is a useful read:

1. Multi-player Agent Runtime (ARMOR)
2. Extension Framework
3. Demo

Conclusion

Platform engineering has always been the land of laborious custom workflows, and the use cases are also inherently multi-user — i.e., many users in the organization need to interact with the system at the same time. AI today is fundamentally a personal assistant, so while Claude can automate the custom workflow, converting that capability into a multi-user agent is a monumental task — one has to implement 30+ capabilities. Also, platform engineering workflows are triggered repeatedly by users and hence need a simple UX, as against a user typing their needs every time into a chat interface. This means an agent that is chat-only does not make an IDP. Lastly, the majority of platform engineering functions need not go to AI but can call simple APIs — say, restart a pod. This means the agent needs a seamless capability to call AI and non-AI workflows.

An Agentic IDP needs to solve for all of these capabilities: (a) be multi-player, (b) the ability to add custom workflows with rich UX, and (c) support AI and non-AI workflows. This is the Internal Developer Platform the industry promised itself a decade ago — finally buildable, with golden paths encoded as plug-n-play apps rather than wiki pages and portals. Organizations that are scaling are already beginning to build many such agents; the need for an Agentic IDP will soon be table stakes. Regardless of whether you plan to build your own platform or leverage an out-of-box solution like DuploCloud, we hope this blog was a useful read.

Platform engineering, at last, gets its platform: the Agentic IDP.