KubeCon 2026 Wrapped: 7 Things We Learned

A few years ago, KubeCon was about Kubernetes maturing into the foundation for cloud native applications. It was Kubernetes’ Linux moment: the layer everything else gets built on. Then generative AI arrived, and the conversation turned to using Kubernetes to schedule GPUs for training and inference.

This year in Salt Lake City, we saw the next step. Kubernetes is moving beyond infrastructure orchestration to become the control plane for AI agents. The questions on the floor weren’t about whether agents work. They were about how to run them as real workloads, inside real organizations, with real consequences. Here’s what we took home from four days in the sessions and at our booth.

1. Agents are a workload now, not a demo

CNCF made it official. This year’s program added a new AI Inference + Agentic track covering agentic workflows, GPU scheduling, model serving and observability for production AI, and Monday had an entire co-located day for MCP and agents.

The conversations matched the program. Everyone was asking how to deploy, scale, and observe agents alongside everything else they already run. It makes total sense: Kubernetes is already core infrastructure for many of the world’s largest enterprises, and running agents there is the sensible choice for architecture, cost and governance.

2. Agents are approaching their Kubernetes moment

Containers went through this a decade ago. First everyone learned to build them. Then the hard problem became running thousands of them reliably, and that is what Kubernetes solved. Agents are at that same turning point. The focus is shifting from building agents to operating and managing them at scale in an enterprise environment.

KubeCon is the audience that has lived through this before, and it showed. When we described Mecatl as an agent runtime that runs as a Kubernetes workload, with permissions and audit built into the engine, people got it immediately.

66% of organizations running generative AI workloads already rely on Kubernetes.

Those teams shouldn’t have to hand their agents to someone else’s cloud to run them.

3. Governance is the real blocker, and identity is where it starts

One keynote title summed up the week: “The Identity Crisis: Who is the AI Agent in Your Cluster?” It named the problem we heard about most. Governance is the biggest thing holding enterprises back from deploying agents, and governance starts with identity.

Human identity systems weren’t built for this. They answer who a person is and what that person can access. An agent needs a different answer: what this specific run was chartered to do. That’s why we believe identity has to be anchored in the agent’s individual session, not in its definition and not inherited from the user who started it. The identity carries the agent’s charter.

Once identity works that way, the rest of the governance model follows:

• On the model side, no inference runs unless it’s tied to a chartered agent identity.
• On the tool side, no system is reachable unless it falls within that charter.
• Every action is identity-stamped and written to a tamper-resistant ledger, so teams can review a run afterward, find errant behavior and tune their guardrails.

That progression shapes how we’re building our own cloud-native harness.

4. MCP governance is growing up

MCP had its own day at KubeCon, and the tone has shifted. Talks like “The Agent Did What? Reconstructing MCP Tool-Call Attacks” treated prompt injection through tool calls as a real incident class, complete with forensics.

We saw the same shift at our booth. People came asking about ToolHive by name, either because they had a specific MCP security or governance problem to solve or because they already run it in their organizations. Teams are seeing what shadow AI looks like when tool access goes ungoverned, and they want a plan before it becomes an incident.

5. A gateway is a feature, not a strategy

Gateways are everywhere this year, which tells you routing and policy enforcement at the edge are quickly becoming table stakes.

The more interesting conversation is about the whole path an agent takes. Where does it run? Whose identity does it carry? What can it touch, and who can see what it did? A gateway in front of the models and another in front of the tools create a useful separation of concerns, but a gateway can only enforce an identity that something else issued.

The runtime, the identity model and the gateways have to be designed together.

6. Lifting agents into VM sandboxes repeats old mistakes

One approach we saw a lot of is taking existing agent instances and dropping them into VM sandboxes. It’s a fast way to get isolation, but it brings back the problems the industry worked through in the early 2010s: scaling, portability and governance that differ by environment. We learned those lessons once already.

A view we heard again and again, including from infrastructure providers, is that the next generation of agent harnesses needs to be model-agnostic and provider-agnostic, built on open standards, and independent of any single governance framework. That’s what Kubernetes did for container orchestration. Agents need the same thing.

That means rethinking the agent harness from the ground up with cloud native principles, not retrofitting existing infrastructure for agents. It validated our thesis around our own cloud-native harness: Kubernetes-native agent runtime you can run in your own clusters and own outright. Owning your harness, and renting the model is resonating. 

7. Platform teams will own the agent guardrails

Daniel Bryant’s session argued that infrastructure requests now come from copilots and agents operating at machine speed, so platforms need capabilities that encode organizational policy, security and operational knowledge for humans and AI alike. We agree.

Agents are becoming tenants of the internal platform. The teams that built golden paths for services will build them for agents too, and they’ll want open, composable building blocks rather than another black box. There has rarely been a more interesting time to be a platform engineer, and organizations already running Kubernetes at scale have a real head start.

What comes next

KubeCon 2026 confirmed what we’ve believed since we started building ToolHive: agent infrastructure is cloud native infrastructure. It deserves the same openness, security and operational rigor the community spent a decade building for containers.

If you’re working through any of this, from MCP governance to running agents in your own clusters, we’d love to compare notes. Start with ToolHive or explore Mecatl.