Why IDPs Are the Wrong Abstraction for the Agentic Era
For five years the hottest answer to "our infrastructure is a mess" was an acronym: IDP. Build an Internal Developer Platform — Backstage, Port, Cortex — and unify the sprawl behind one portal. A software catalog. Clickable scaffolding. Maturity scorecards. Every tool you own, linked from one browser tab.
It was a reasonable answer to a real problem. It's also the wrong abstraction for the era we just entered. Run an IDP through the agent-native test and the whole category comes apart.
What an IDP actually is
Strip the marketing and an IDP is four things, all of them browser-shaped:
- A software catalog — hand-registered metadata about your services
(
catalog-info.yamlin Backstage), declaring owners, lifecycles, and links. - A scaffolder — a click-driven "create new service" wizard that generates a repo and pushes it once.
- Scorecards — maturity and compliance grades computed in a dashboard.
- Plugin dashboards — CI, logs, on-call, docs, each a view aggregated into the portal.
Notice what's missing from that list: anything that operates anything. An IDP doesn't reconcile your clusters, deploy your apps, rotate your certs, or enforce your policy. It catalogues and links. In the language of the primitive-matching post, it's a pile of read-models and one-shot generators — all surfaced as a portal.
Run it through the test
The agent-native test is simple: can an agent read it, edit it, and prove the edit worked, through text and composable commands? Hold each capability up to it:
| IDP capability | What it is | The agent-native verdict |
|---|---|---|
| Software catalog | Hand-registered metadata about services | A read-model — should project from real state, not be a second hand-kept truth |
| Scaffolder | Click-driven "create new service" wizard | A one-shot push. The agent-native form is a reconciled App / PreviewEnv CRD |
| Scorecards | Compliance grades in a dashboard | Policy is code (CEL, Kyverno) the agent satisfies at author-time — not a grade returned later |
| Plugin dashboards | Aggregated CI/logs/on-call views | A read-only lens the agent doesn't need; it queries the source directly |
Every row either fails read-edit-verify, is a one-shot push, or is a view the agent can generate itself from the real state. None is a primitive an agent operates. They are conveniences for a human at a browser.
The deeper problem: a second source of truth
Here's the part that actually breaks things. An IDP doesn't own your state — your GitOps repo, your Helm charts, your cluster do. The IDP catalogs a copy of the truth, maintained by hand, and immediately starts to drift from it.
That drift is the one failure mode that genuinely wrecks an agent loop. From the DX post: the thing an agent cannot tolerate is silent divergence — edit text, trust it, and be wrong. A catalog that says a service is owned by Team A while the repo says Team B is exactly that. So is a scorecard grading a service "compliant" against a rule that changed in Kyverno last week but nobody re-ran.
The dissolve
Now the part that ends the category. Everything an IDP does, an agent does better by reading the real, text-addressable state directly:
- "What services exist?" — read the GitOps repo, or
kilter catalog. No hand-registered catalog required. - "Scaffold a new service" — compose the CRDs and commit. Reconciled, not one-shot.
- "Are we compliant?" — read the policy (CEL/Kyverno) and check the resources against it. A live answer, not a stale grade.
- "Who owns this, is it healthy?" — query the actual state and its owners.
The IDP existed to help a human navigate a sprawl the human couldn't hold in their head. That was a real job — when infrastructure was a dozen incompatible tools with no canonical shape. Two things ended it. The substrate converged into a canonical stack. And the navigator is no longer a human who needs a portal — it's an agent that reads text. The IDP's entire reason-for-being dissolved, and what's left is a portal optimizing the one surface neither audience wants.
Same error, one layer up
This is the PaaS argument from the PaaSocalypse, repeated inside the org. A hosted PaaS hides Kubernetes behind a console; an IDP hides the whole substrate behind a portal. Both remove the surface area the agent needs to reach. Qovery gives you GitOps benefits without GitOps surface area; an IDP gives you a catalog without the substrate. Same category error, one layer up the stack.
What to build instead
Don't build a portal. Invest in the thing the portal was mirroring:
- A text-addressable substrate — CRDs and controllers for the abstractions that drift, Helm/Kustomize for transforms, CEL/Kyverno for policy.
- A CLI with structured output the agent can drive.
- Observability (SigNoz, OpenTelemetry) that makes verification commandable.
- Let the catalog be a projection an agent generates on demand from the real state — not a hand-maintained second truth.
The platform team's job in the agentic era isn't curating portal plugins. It's authoring the controllers and policies that expose every capability as declarative text. Do that and the catalog, the scorecard, the scaffolder — all the things the IDP sold you — fall out for free, current, and agent-addressable.
Where to go next
- Read what makes a platform agent-native — the test every IDP capability fails.
- See why agentic DX and human DX converge — why the portal is the wrong surface for both.
- Read the PaaSocalypse — the same error, outside the org.
- Start your free trial — the full platform, 7 days, no card.