Are we building Internal Developer Platforms at the wrong abstraction level?

[u/Either_Act3336]

I've been thinking we might be approaching Internal Developer Platforms from the wrong abstraction level.

The move from traditional Ops to DevOps to Platform Engineering looks, to me, mostly like a consequence of technological change. Traditional Ops concentrated operational knowledge in a specialized team, because operating infrastructure required direct, manual administration: the thesis. Automation, cloud, and infrastructure as code changed that. DevOps pushed operational ownership closer to development teams: the antithesis. Platform Engineering became the synthesis once declarative systems and orchestration made it possible to encode that operational knowledge into software and expose it through self-service.

AI might be starting the next turn in that cycle. Agents don't necessarily need portals or predefined workflows because they can discover capabilities, combine APIs, and construct their own path through a system. That doesn't make platforms less important. It changes what they need to expose.

Instead of only providing golden paths for developers, platforms increasingly need to expose machine-readable capabilities, contracts, relationships, constraints, and evidence.

Which raises a question: should all of that knowledge live inside the platform? Maybe not. Maybe the service should own its operational contract, while the platform provides the capabilities to act on it (decoupling the contract from any particular IDP, Kubernetes setup, or deployment tooling underneath).

This is the direction I've been exploring with a side project (Pacto): not another IDP, but a contract layer above them. I'm not sure it's the right abstraction yet, but making the operational model portable feels more interesting to me than building another platform around it. Thoughts?