Why AI Agents Need Platform Engineering: The Next Evolution of Software Delivery
Enterprise software delivery is entering a new era in which AI and platform engineering must work hand in hand. Recent research underscores this point: in a platform engineering survey of 900+ organizations, 55% reported having adopted internal developer platforms, and an overwhelming majority view AI and platforms as co-dependent.
“86% of respondents believe that platform engineering is essential to realizing the full business value of AI,” while 94% say AI is “critical” or “important” to the future of platform engineering. In short, modern teams see platform engineering and AI agents as partners, not rivals. The challenge is to give AI agents the same high-quality infrastructure and governance that developers already depend on.
Google’s research shows platform engineering adoption surging: 24% of firms “employ platform engineering extensively,” and 31% use it for some projects, for a combined 55% adoption rate. Crucially, leading adopters reap big rewards: 71% of mature platform users report significantly faster time-to-market versus just 28% of less mature teams, and 85% of adopters say developers rely on the platform for success.
This trend has only intensified with AI’s rise. Google Cloud’s report notes a “synergistic relationship” between AI and platforms: organizations see AI as a catalyst for advanced platforms, and platforms as key to AI success.
Platform engineering is, in essence, about giving developers self-service tools and “golden paths” so they can build and deploy without wrestling with infrastructure. According to IBM, an internal developer platform is “a centrally coordinated set of internal tools, services, and processes that make it easier for developers to build, deploy, and run software without having to be responsible for all the underlying infrastructure.”
This essentially implies giving developers pre-made templates to execute various operations, such as microservice deployment or on-demand staging environment setup, according to the standards of the company. Using an IDP allows reducing unnecessary context switching on the part of platform teams and provides scalability for growing organizations.
The Rise of Agentic Software Delivery
That foundation is now being stress‑tested and extended by AI agents. The first wave of AI coding assistants (Copilot, ChatGPT, etc.) improved developer productivity, but still required humans to glue the results into production. Today’s agentic systems go much further: they plan, execute, and adapt entire development tasks autonomously.
As one platform-engineering expert notes, “the next generation of autonomous AI agents are now beginning to provision infrastructure, deploy applications and perform operational tasks with minimal human intervention”. In other words, agents aren’t just writing code; they are running pipelines and pushing to production.
However, this power comes with pitfalls. Atlassian reports that, in practice, AI tools on their own create a new “productivity gap.” In a longitudinal study, AI usage jumped by 65%, yet overall developer velocity crept up only about 10–15%. Why? Because software delivery has never been just coding; it’s about understanding business context, architecture constraints, compliance rules, and so on.
If an AI agent writes code without this context, it often introduces errors or security issues downstream. As Red Hat’s Balaji Sivasubramanian puts it, an agent acting alone “can improvise infrastructure, skipping compliance checks or deploying to the wrong environment”. He warns that “agents without context are just confident hallucination machines.” Instead, an agent must have access to the same enterprise context (service catalogs, security policies, approved templates, etc.) that human teams rely on.
Treating AI Agents as First-Class Platform Users
Platform engineering provides exactly that context and structure. Platform teams are now learning to treat AI agents as first-class users of the system effectively, second-class developers who talk in APIs instead of GUIs. As CloudBolt’s COO Yasmin Rajabi advises: “Treat agents as first-class users, not traditional automation.
They need the same golden paths, role-based access control (RBAC), and audit trail as developers, just exposed through machine interfaces”. In practice this means extending every platform practice to machines: every agent must authenticate under the platform’s identity system, inherit only allowed permissions, log every action, and be subject to usage quotas. “Once an agent can provision or deploy,” she says, “three controls stop being optional: [platform auth with] RBAC, audit, and spend limits”. Without such guardrails, agents risk “policy drift” or conflicting objectives as each agent pursues its own goals.
In short, platform engineering becomes the governance layer for AI-driven workflows. Agents should still produce standard artifacts (for example, Pull Requests) that go through normal CI/CD pipelines and human review. As GTT’s Gary Sidhu emphasizes, agents do not and cannot understand intent or context on their own; they must operate within “human-defined boundaries, serving as the execution layer rather than the source of business judgment”. Platform teams encode those boundaries, permission schemes, security policies, and audit logs so that as agents automate more tasks, accountability remains clear.
Building the AI-Native Developer Platform
SoftServe notes that as agent‐based systems grow, teams will need tools to “manage the agents themselves,” registering agent identities, assigning them to tasks, monitoring their status and spending, and integrating them with existing CI/CD and ticketing systems. Without this shared orchestration layer, efforts to scale from a handful of AI experiments to production-grade delivery will stall. As SoftServe bluntly states: “You can’t scale AI without a platform layer. Building one agent is easy; running hundreds is not”.
Crucially, the same IDP that serves developers must serve agents too. Red Hat’s analysis is clear: a modern developer portal contains the “catalog of every service, API, model, and component in your organization, golden-path templates encoding architecture decisions and policies, and real-time data from CI/CD and monitoring”.
For human users, this is a (sometimes clunky) UI, but for agents it must be a programmatic API. Red Hat envisions the portal evolving into a dual-audience platform: developers may still browse it in a browser, while agents query it via protocols like the Model Context Protocol (MCP). In other words, the IDP becomes infrastructure for agents. When an agent needs to deploy a service, it would query the portal for the approved deployment template, compliance checks, and AMIs all invisible to the user, and then execute under those guardrails.
This integration of humans and AI is already underway. Atlassian, for instance, recently announced “agentic” features in Jira: teams can now “plan work with AI, turn intent into agent-ready specs, [and] assign work to coding agents” alongside humans. (Similarly, technology news site PR2DAY reported on these features as an example of agents entering the SDLC.) The idea is that intent and context stay in one place (Jira/Confluence/Slack), and agents operate against that common data graph. Without it, AI-generated changes often become bottlenecks: Harness’s research finds that only teams with mature, automated platforms see actual throughput gains from AI. Organizations with strong CI/CD pipelines were twice as likely to release faster using AI, whereas those with ad-hoc tools see stability drop.
Conclusion
AI agents can deliver immense productivity, but only if backed by robust platforms. A governed, scalable IDP acts as the bridge between human intent and autonomous execution. As one Red Hat author concludes, “in a world where AI agents are making decisions at machine speed, the need for a governed, curated, enterprise-scale development context becomes the most critical layer in your platform engineering stack”. In other words, the portal isn’t dying; it’s becoming infrastructure.