Kubernetes co-founders want to move agents off the laptop and into the cloud

“A monolith in a container is still a monolith.” Craig McLuckie, a co-founder of Kubernetes, wrote that line on the CNCF blog on 28 September. He was not talking about microservices this time. He was talking about the agent harness, the loop that is probably running on your laptop right now.

On 7 October McLuckie appeared on the Latent.Space podcast with Joe Beda, his fellow Kubernetes co-founder and now his partner in building Stacklok, to explain the plan: shift where agents deliver value from the desktop to the cloud. Anyone who lived through the container wave will find the script familiar.

For FDEs this has practical consequences. You take an agent that works well on your own machine to a customer, and the first question is not “which model?” but “who is allowed to run it, where, and with what permissions?” The two Kubernetes co-founders argue that most harnesses today have no answer.

Today’s harnesses are single-user software

Beda’s diagnosis is specific. Existing harnesses were designed to run on the desktop, and in them the agent loop, the execution layer and the session state are tightly coupled. McLuckie made the same point on the CNCF blog: most harnesses assume one person, one machine, a local filesystem and an interactive process.

That assumption holds when you use an agent to edit your own code. Now picture a company that wants hundreds of people sharing one agent, running jobs overnight, with logs that auditors can inspect. Every one of those assumptions breaks at once.

This is where McLuckie warns of a familiar trap. Packaging a desktop-style harness into a container does not solve the architectural problem. In his view, a harness for the next phase has to be designed as a distributed application from the start.

Where Stacklok is placing its bet

Stacklok’s answer is Mecatl, an open-source harness written in Go. Its package documentation says it keeps the agent loop independent of the client and the execution environment, so the same loop runs in a terminal, as a service or on Kubernetes without being swapped out. Because of that separation, Mecatl scales horizontally across Kubernetes replicas while the loop stays the same.

The second piece is ToolHive, Stacklok’s open-source MCP platform. ToolHive runs each MCP server in its own container, either locally through Docker or Podman or on a cluster through a Kubernetes operator. Each server gets a least-privilege permissions file and no local credentials. In other words, the agent’s tools have already made the move from laptop to cluster, ahead of the loop.

What Stacklok sells is an enterprise control plane that ties the open-source projects together and handles identity, authorization, policy and audit.

Don’t wait for Mecatl to mature

You do not need to wait and see whether Stacklok wins to use its way of looking at the problem: split the loop, execution and session state into three things that can live in three different places. Take an agent you have already built, draw those three boxes, and ask which box knows too much about the other two.

When you read FDE job descriptions, look for four words: identity, authorization, policy, audit. That is exactly the list Stacklok has built an entire commercial control plane to address. If you have ever added one of those layers to an agent yourself, even just an audit log of tool calls, say so explicitly on your CV rather than folding it into “built AI agents”.

McLuckie is reminding the industry of a lesson from Kubernetes: a monolith in a container is still a monolith. The next time someone suggests “just dockerise the agent and ship it to the customer”, you will have your answer ready.