Agents don't fit Kubernetes, and three more problems still open

Kubernetes was built for stateless, replicated apps. An agent is the opposite: one isolated, stateful instance that sits idle for hours, then wakes up and waits on a tool, a model or a person. That mismatch is the first of four problems Katelyn Lesse, head of platform at Anthropic, says software engineers have to solve before multiagent systems can be trusted with serious work. The other three: who an agent is and what it may do, how far a compromised agent's damage spreads, and how to stop a whole system at once.

Her article went up on X on October 26. It's short, and it opens on the engineers she sees going through an identity crisis as the job changes. Her answer isn't comfort. It's a list of work. I run 17 agents on a Mac mini and I'm moving one of them into a sandbox on an old Dell, so at the end I hold my own fleet against her four.

From a chat to thousands of agents

Her account of how we got here is quick. Agents started as chats with a human in the loop. Then models got better at running longer on harder problems, and agentic systems moved to the cloud. Then models got better at working together, and people built basic multiagent systems: an orchestrator that spawns subagents for a task, or agents given jobs other than executing, "like grading or advising or dreaming".

Now some teams are building systems for serious research, discovery and hardware design. Her picture is thousands of agents, persistently working towards an outcome. That's where the new problems show up, and she names four. Infrastructure for burstier workloads. Authentication and authorization, so agents can be identified, work together, take the actions they should and be kept from the ones they shouldn't. Security and isolation for untrusted code and content. And monitoring, with the ability to stop a system "when it's veering into the wrong territory".

Models will keep getting better, she says, and these systems will become really powerful. Whether the world trusts that power to cure diseases instead of causing harm is on the engineers who build the plumbing.

Agents don't fit Kubernetes

The software industry has been building on Kubernetes, which was designed for stateless, replicated apps, or for stable, numbered sets of stateful pods. Agents are "isolated, stateful, single-instance workloads". They go idle for arbitrary stretches between bits of work. They spend most of their life waiting: on tools, on model inference, on other agents, on a human.

Each of those shapes wants something different from the machine underneath. Some workloads need fast startup. Some need to stop burning compute while they wait. Some need a crazy scale. She points at AI infra companies building new filesystems and sandboxing offerings, and at the Google team building Agent Substrate as a new runtime, and says there's a ton left to figure out.

My fleet is a small version of the idle problem. Seventeen OpenClaw agents live on one Mac mini, each behind its own Telegram bot, and most of them do nothing until a message arrives. Forge, my open-source contribution agent, is the other shape: a worker starts for one issue, clones a repository, runs its tests and is gone. Neither looks like a replica set.

Who did that, you or your agent

Authentication, identifying the agent that took an action, is the easier half. The microservices world already built and hardened the pieces: workload identity, short-lived certificates instead of static keys. People are starting to apply them to agents.

Authorization is "much more wide open". Most agents today work on behalf of a human and use that human's identity and credentials to reach systems and take actions. The first problem hides inside that sentence: on the receiving system, nothing says whether the human or the agent did it. The deeper one is consent. If a multiagent system works for weeks, how does the human meaningfully approve what their agent can do? Auto-approval of tool calls helps, she says, but at scale the permissioning has to go deeper than that.

Then the part even less solved: agents with their own identity, and agents working together. How does an agent trust another agent that asked it for something?

I know the first problem from the receiving end. Every pull request my agents open is authored by me, as far as GitHub knows. In my own repositories, the one trace that a session did the work is a session id in an HTML comment in the PR body. And my first try at scoping what an agent may do taught me how thin that layer is: a deny rule in my gateway config matched nothing for a month, and an agent that was supposed to be locked out of my finance app was offered all 13 of its tools. I wrote that up in the note on AI coworkers in Slack, where MintMCP gives every agent an identity of its own.

One compromised agent is a blast radius

Over the past few months, she writes, and especially the past couple of weeks, vulnerabilities have surfaced faster than the industry can patch them, much of it in core software that many systems rely on. Put thousands of persistent agents on top of that software, writing untrusted code and reading untrusted content, and every unpatched vulnerability gets more dangerous. Her ask to engineers is to get creative about hardening the kernels, browsers, runtimes and common libraries those agents run on.

Multiagent systems add a twist. A compromised agent can pass injected instructions to the agents it works with, and those instructions can end up in memory, where future agents trust them by accident. So the question becomes blast radius: when the first agent falls, how much of the system is at risk? Her answer is isolation. Agents should take their actions from strongly isolated, sandboxed execution environments.

She wrote the longer version in September, in Secure agents: architecture and sandboxing, and it's the most practical page on the subject I've read. Split the brain from the hands. The harness, the session state and the credentials live outside the sandbox, on infrastructure you trust, and the sandbox is just a tool the agent uses to run code. When code in the sandbox needs an external service, the request leaves through an egress proxy that adds the credential on the way out, scoped to that one destination. The sandbox can hold a placeholder that the proxy swaps for the real key. Her line on the alternative, everything in one box: "Your kill switch is basically inside the thing you're trying to kill."

The sandbox itself then needs four settings. Isolation, from weakest to strongest: containers, which share the host kernel and shouldn't be a security boundary for untrusted code; a user-space kernel like gVisor; microVMs like Firecracker, each with its own kernel behind the CPU's virtualization hardware, her pick for most teams; and full VMs or dedicated hosts for regulated work. Sandboxes should be ephemeral, "cattle instead of pets", with hard limits on time and resources. Egress should deny by default behind a proxy, with an allowlist of hosts and HTTP methods and DNS closed; install the dependencies at the start of the session, then lock the network before the agent starts working. And the logs of tool calls, commands and network access go somewhere the sandbox can't reach, next to a kill switch that works mid-session.

That's close to what I built for Forge's workers in my sandbox inside the sandbox: the key inside the sandbox is a placeholder that OpenShell's proxy swaps on the way out, and the workers get a second fence with one door, a relay with a host allowlist.

A kill switch outside the thing it kills

The last set is the one she calls hard. We need to know these systems are heading in a positive direction, and to catch them and cut them off when they're not. Concretely: OpenTelemetry tracing across agents, with the guarantee that an agent can never modify its own trace or another agent's. And kill switches that monitoring can trigger, that truly stop the whole system at once and cut off its credentials.

The hard part isn't the switch. It's knowing when to hit it. "Well-intentioned persistence to solve a problem can look a lot like maliciousness." Her example: repeated attempts to reach a domain that isn't on the allowlist.

I've seen that ambiguity from both sides. Forge's workers run strangers' install scripts and test suites behind a relay that allows a short list of hosts. If a test fetches a fixture from a host I never listed, the relay refuses it, and refuses the retry. From outside, that worker and an exfiltration attempt write the same log line. The other side: when I stopped using Hermes this summer, my kill switch was revoking its Telegram tokens. By September 14 both of its gateways were crash-looping, retrying tokens that no longer worked. Persistence, not malice, and from the logs alone you couldn't tell.

Where my fleet stands on the four

She closes the article for the engineers who think their skills won't matter: these problems are wide open, and "you and your skills can be the difference". So, honestly, mine.

Infrastructure: one Mac mini, 17 agents, idle most of the day. No scheduler, no fast start, nothing to scale. It works because the fleet is small.

Identity: everything runs as me. The agents use my accounts, and their pull requests are mine on GitHub. Two of them, Nova and Spark, have their own Slack accounts in a workspace just for agents, which is the first piece of an identity. Agent-to-agent trust hasn't come up yet: Telegram doesn't deliver one bot's messages to another, so my agents can't talk to each other there.

Isolation: partial. Forge's workers run in srt, a sandbox runtime on macOS Seatbelt, and on the Dell they'll run in a Landlock cage inside OpenShell, with the keys outside. Every other agent runs its tools on the host, which is OpenClaw's default and the empty row in my note on NVIDIA's five parts.

Monitoring and halting: the weakest row. Meterlex prices every session, but that's a meter, not a trace, and nothing joins one agent's actions to another's. There is no kill switch. Stopping an agent means stopping its gateway or revoking a token, by hand. Forge has a budget of $5 a day, and its Hermes profile on the Dell has a hook that sees every tool call before it runs. That's the closest thing I have to a switch.

Read it

Her article is a few screens long, and it's written for engineers rather than for buyers. Read it for the four headings, then her September post for the sandbox settings, because that one you can act on this week.

If you want more:

• The new set of problems for engineers to solve, Katelyn Lesse, October 26, 2026
• Secure agents: architecture and sandboxing, her September post on splitting the brain from the hands
• Hope isn't security: the five parts of an enterprise agent, NVIDIA's version of the same list, with OpenShell
• A sandbox inside the sandbox, Forge's workers behind a relay in OpenShell
• AI coworkers in Slack need their own identity, MintMCP's agents, each its own principal
• What breaks when an AI agent runs a real business, four months of an agent persisting at the wrong thing

If you run more than one agent, pick the row you'd fail first and tell me which. Mine is the kill switch, and I'd like to hear from anyone who has built one that stops a whole fleet and cuts its credentials in one move.

Plain text: agents-dont-fit-kubernetes-open-problems.md · Atom feed · All notes