When Paved Roads Lead To Dead Ends
The Next Interface for Platform Engineering
Platform engineering is, at its core, an interface design problem. How do we provide sufficient abstraction to hide complexity while still giving users meaningful control? How do we make infrastructure consumable without making it feeling overly constrained?
We’ve spent a decade paving golden paths. We’ve built portals, written templates, catalogued services. The friction that once defined infrastructure provisioning has been dramatically reduced.
And yet, there’s always a developer who needs something slightly outside the paved path. Always an edge case that doesn’t fit. Always a troubleshooting session that should follow a known pattern but still demands an engineers’ time.
We’ve smoothed the journey, but we haven’t eliminated the need to travel.
From Golden Path to Preferred Route
MapQuest was one of the first mainstream “killer apps” of the Internet. Before any long journey, you’d use MapQuest to plot the most optimum route, print it off, and do your best to manage a pile of paper without crashing. Miss a turn? You were on your own! The system gave you a path, but no ability to adapt.
Early GPS was a game changer. We could now get turn-by-turn directions that meant you could keep your eyes on the road, but you were still following a predetermined route. The path was fixed at the moment you pressed “Go”.
Modern navigation is fundamentally different. Your phone reroutes dynamically based on traffic conditions, road closures, or your own mistakes. Take a wrong turn and the system simply recalculates. It doesn’t require you to pull over and re-enter your destination, it adapts in real time.
Recently, Apple Maps did something that surprised me. It suggested my “preferred route” to a destination I visit regularly, even though another route was technically a few minutes faster. The system had learned not just where I wanted to go, but how I prefer to get there. It understood my context, not just my destination.
Modern navigation combines real-time awareness of conditions, the ability to change course dynamically, memory of preferences and past journeys, and the intelligence to orchestrate it all.
This is where platform engineering is heading.
Golden paths are our MapQuest printouts - valuable, but static. They assume we know the journey before we start and that nothing will change along the way.
Internal developer platforms are early GPS: more responsive, but still path-centric. They help developers navigate known terrain faster.
But developer teams aren’t taking identical journeys. They’re building different products, serving different customers, operating under different constraints.
What if the platform could navigate terrain, not just provide directions?
Introducing Kagent
Kagent is a recent addition to the CNCF family that provides “an open source programming framework designed for DevOps and platform engineers to run AI agents in Kubernetes”.
Great…. but what does that actually mean?
A lot of AI tools can answer questions or explain concepts, but they can’t actually do anything. Kagent lets platform engineers build autonomous AI agents that have the ability to query cluster state, check recent deployments, correlate logs with metrics, and use advanced reasoning and iterative planning to autonomously solve complex problems.
That’s certainly useful, but what makes this interesting to me is how it achieves this and what that architecture might enable in the future.
Kagent is Kubernetes-native and declarative. Agents are custom resources that inherit existing RBAC, GitOps workflows, and governance patterns. You can use the machinery you’ve built to control infrastructure to control agents too.
Kagent separates reasoning from action. An agent consists of an LLM with a defined scope that is given access to tools that observe or change infrastructure environments. Kagent ships with an impressive set of tools covering Kubernetes, Istio, Helm, Argo, Prometheus, Grafana, Cilium, and others. Some observe; others effect change. All tools are Kubernetes custom resources (ToolServers) that can be shared across multiple agents. And, because kagent fully supports MCP, you can integrate capabilities from other platforms too.
Where this might lead
Right now, kagent’s users are platform engineers. The developer experience remains unchanged — golden paths, self-service portals, the interfaces we’ve built over the past decade.
But the building blocks kagent puts in place are exactly what we’d need to offer agents as the interface to the platform, not just tools behind it.
The platform’s next user might not be human. We’ve spent years optimising for human users; designing portals, writing documentation, crafting templates. But if agents can navigate infrastructure on behalf of platform engineers today, they could do it on behalf of developers tomorrow. The “user” of your platform might increasingly be an agent acting on someone’s behalf, not the someone themselves.
This changes what good platform design looks like. Clear interfaces matter less than well-described capabilities. Portal UX matters less than API discoverability. Documentation written for humans matters less than context an agent can consume.
From paved roads to terrain-aware guides. Golden paths work brilliantly for known journeys, but platforms serve diverse teams with diverse needs.
An agent doesn’t need a pre-paved path. It needs capabilities and judgment to navigate novel terrain. A golden path says “here’s the route”, but an agent says “I understand where you’re trying to go, and I can figure out how to get there, even if no one has taken this exact journey before”.
Golden paths don’t become obsolete. They become one input among many.
From automation to agency. Traditional automation executes predefined sequences: if X happens, do Y. Powerful, but brittle when reality deviates from expectations.
Agency means reasoning about what sequence is needed. The platform engineer says “this service should be healthy” rather than specifying every check. The agent figures out what healthy means, how to verify it, and what to do if it’s not.
The question for your next strategy session
Every platform team should be asking “which journeys in our current platform exist because a human needs to walk them, versus which exist because we assumed a human was the only option?”
Not every path will transfer to an agent, but it could be more than you expect.
The platform engineering discipline has spent a decade getting very good at paving roads. The next phase might be about training guides who can navigate terrain we haven’t paved yet, and perhaps never will.