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.
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.
Problem Statement: Laborious custom workflows, each sharing ~70% of its functionality.
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.
Desired anatomy of 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.
A personalized agent in Claude Code — crossed-out parts are not implemented.
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
The AI-in-platform-engineering maturity model: from individual copilots, to one-off agentic builds per use case, to the stage almost no one has reached — a centralized Agentic IDP.
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.
A coding assistant builds each use case as a custom app, on top of a Common Platform hosting the shared functionality.
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:
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:
1 Be multiplayer
Platform engineering use cases are inherently multi-user — many people in the organization need to interact with the system at the same time.
2 Add custom workflows with rich UX
Workflows are triggered repeatedly, so they need forms, validations, dashboards, and views, not a user retyping their needs into a chat interface every time.
3 Support AI and non-AI workflows
Most platform engineering functions don’t need AI at all — they can call a simple API, like restarting a pod, with no tokens spent.
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.
