AI-augmented platform engineering: the IDP in 2026

Platform engineering in 2026: the IDP becomes the default operating model

For a decade, DevOps tore down the wall between development and operations. In 2026, platform engineering structures the field: rather than requiring every product team to master cloud, observability, security and compliance, the organisation gives them an Internal Developer Platform (IDP), a self-service internal platform that encapsulates these disciplines behind paved paths, the golden paths.

The shift is clear. Gartner anticipated it as early as 2022: 80% of large software engineering organisations run a platform team in 2026, up from 45% four years earlier. The prediction has been confirmed in the field, and a second movement layers on top of it: agentic AI. Agents no longer merely suggest code in the editor; they execute complete engineering tasks, service scaffolding, framework upgrades, incident remediation, under human supervision and within the frame the platform imposes on them.

For an IT department, the question is therefore no longer "do we need an IDP?" but "how do we design it so it absorbs AI agents without sacrificing governance or sovereignty?". This article takes stock of what agentic AI concretely changes in platform engineering, of the guardrails that become non-negotiable under DORA, NIS2 and the AI Act, and of how to measure the real value of an augmented platform, beyond the promises of velocity.

Internal Developer Platform: golden paths and governed self-service

An IDP is not yet another infrastructure tool. It is an internal product whose users are the developers, with a backlog, SLOs and a roadmap driven by actual usage. It exposes golden paths: create a service, provision a database, deploy to production, wire up monitoring and observability, all of it without writing a single line of infrastructure by hand, and while staying within the organisation standards. The developer portal, whether built on Backstage or a commercial alternative, is only the visible part: the substance lies in the orchestration that executes the requests and in the templates that carry the standards.

Making the compliant path simpler than the workaround

The goal is not to take freedom away from teams, but to make the compliant path more attractive than tinkering. When creating a complete microservice, CI/CD pipeline, security scans, FinOps tags, observability dashboards, takes ten minutes through a validated template, nobody builds their own parallel deployment any more. Compliance becomes a default value rather than a layer added at the end of a project under the pressure of an audit.

Reducing cognitive load, not autonomy

A good platform is measured by what it makes disappear: waiting tickets between teams, infrastructure decisions repeated in every squad, the fear of touching production. Internal DevEx surveys, onboarding time for a new developer, share of time lost to tooling friction, declared satisfaction, have become as structuring as DORA metrics for steering the platform roadmap, because they reveal irritants before they turn into workarounds.

Related readPlatform engineering: scaling DevOps across the hybrid cloudA dedicated platform team, hybrid cloud architecture, developer portal, IaC and AI agents: how platform engineering scales DevOps across hybrid environments.Read the article

AI agents and the IDP: from code suggestion to supervised execution

Agentic AI moves the IDP from a catalogue of templates to a workshop that acts. An agent connected to the platform can generate the skeleton of a compliant service, open the pull request for a framework upgrade, correlate an incident with a recent deployment, or propose an infrastructure-as-code fix along with its execution plan. Golden paths become the action grammar of the agents: every task goes through the same templates, the same controls and the same pipelines exactly as if a human engineer had initiated it.

The real gain: less toil, more consistency

The trap would be to believe raw velocity is the main stake. In the field, the lasting benefit lies elsewhere: less repetitive toil for platform and on-call teams, a smoother developer experience, and above all reinforced consistency, every agentic action takes the same guardrails as human actions. AI amplifies what the platform encodes: if the standards are solid, it multiplies them; if they are absent, it industrialises the disorder at unprecedented speed.

This is why platform maturity conditions AI maturity. Organisations that try to deploy agents without an IDP end up with orphaned automations, untraced and non-reproducible, scattered across scripts and editor extensions. Those that already have governed golden paths observe the opposite: the agent becomes one more user of the platform, subject to the same rules, and its adoption accelerates without creating a new uncontrolled risk surface.

Control plane and governance: the auditability required by DORA, NIS2 and the AI Act

As soon as an agent acts on real systems, classic engineering becomes central again: immutable audit log, fine-grained permission governance, explainability of decisions, isolated execution environments for every agent run. A control plane consolidates these signals, who requested what, which agent acted, with which model and which prompt version, on which resources, and makes every action reconstructible after the fact, which is what separates a platform defensible before an auditor from a collection of opaque automations.

What the regulator expects from an agentic system

The regulatory calendar leaves no room for improvisation: DORA has applied to financial entities since January 2025, NIS2 extends software supply chain traceability obligations to thousands of organisations, and the AI Act obligations for general-purpose models have been applicable since August 2025, with the requirements on high-risk systems ramping up over 2026-2027. In every case, the logic is identical: demonstrate who controls what, with which evidence. An IDP equipped with a control plane natively produces these audit artefacts; agents deployed at the margins of the information system cannot.

Security follows the same slope. An agent with broad permissions is a first-order attack surface, exposed in particular to indirect injection through the content it consults and to malicious MCP servers. Least privilege, human approval on irreversible actions and systematic review of connected tools are part of the platform foundation, not options to enable later.

Related readAI agents shouldn't be a security nightmarePrompt injection, data exfiltration, rogue agents: a six-layer framework to deploy AI agents safely in production, from least privilege to the kill switch.Read the article

Digital sovereignty: keeping the choice of cloud and models

Sovereignty plays out at the platform level, because the platform is what freezes, or preserves, the structuring choices: sovereign, hybrid or hyperscaler cloud in a compliant landing zone; data location and remanence; dependence or not on a single model provider. A well-designed IDP treats these choices as reversible parameters rather than as irrevocable commitments taken implicitly as integrations pile up over the years.

Open-weight models and self-hosted inference

The maturity of open-weight models makes self-hosting credible for a growing share of platform use cases: incident classification, first-level code review, test generation, alert triage. The most regulated organisations combine self-hosted inference on sovereign cloud for sensitive data and frontier models via API for complex reasoning tasks, with explicit routing decided by the platform, never by the agent itself. The internal corpora that feed the agents' RAG follow the same residency rule as the data they contain.

This decoupling also protects economically: when model routing is a platform parameter, changing provider is a configuration migration measured in days, not a six-month project. In a model market that shifts every quarter, this reversibility is a low-cost insurance against the obsolescence of initial choices.

Related readCloud adoption strategiesSeven strategies for adopting the cloud with method: aligning technology with business objectives rather than absorbing the vendors' pace.Read the article

Measuring the value of an augmented IDP: DORA, DevEx and toil

A platform is an investment, and like any investment it must be steered by data. Three families of metrics are enough to objectify the value. DORA metrics first, deployment frequency, lead time, change failure rate, time to restore, measured before and after golden path adoption. DevEx metrics next: onboarding time, proportion of time spent on tooling friction, developer satisfaction. Operations metrics finally: share of toil automated, golden path adoption rate, percentage of agentic actions traced and approved.

The anti-metric: adoption by mandate

One signal must alert immediately: a platform imposed by decree rather than adopted by preference. If teams bypass the golden paths, the problem is almost always a product problem, the compliant path is slower or poorer than the workaround, and rarely a communication problem. The platform is won the way a product wins its market: by being better than the alternative, measurably and durably.

The arrival of agents adds a new metric: the rate of agentic actions validated without human rework. Too low, it signals poorly calibrated templates or prompts; artificially high without review, it signals a loosening of supervision. Tracking it over time gives an honest reading of the trust the organisation can place in its automation, quarter after quarter.

The Adservio approach: La Forge, the platform as a discipline

At Adservio, the augmented IDP takes shape in La Forge: an engineering platform that equips the four pillars of an augmented IT department, automate, augment, accelerate, arbitrate. Each expert runs their workshop of agents contextualised on the house corpora, and the control plane keeps control of production: permissions, audit logs, human approvals on sensitive actions.

Our conviction has not changed with the agentic wave, it has been reinforced by it: a well-run platform is first a discipline of alignment, between product teams, security, compliance and leadership, not a product you install. And a successful mission ends with a transfer of skills: your teams operate the platform and its agents day to day, and we keep supporting them on the projects that follow.