There’s a joke going around DevOps circles right now: “Dad, please, promise me you’ll never put a coding agent in Kubernetes inside a container.”
It’s funny because everyone who has tried knows exactly why the kid is begging.
The impedance mismatch
Kubernetes was built around a beautiful, hard-won idea: treat your workloads as cattle, not pets. Any pod can die at any moment and be replaced by an identical one. State lives elsewhere. Nothing is precious. This philosophy gave us self-healing infrastructure, and it deserves every bit of its success.
A coding agent violates every single assumption in that paragraph.
An agent session is precious. It holds hours of accumulated context: the codebase it has explored, the plan it negotiated with you, the half-finished refactor sitting in a git worktree, the test run it’s currently watching. Kill the pod and you don’t get a fresh replica — you get amnesia. The replacement doesn’t remember what it promised you, what it already tried, or why the third approach failed. You don’t restart a coding agent the way you restart a stateless API server. You lose it.
Then there’s the resource profile. An agent is bursty in the worst possible way: minutes of near-idle waiting on a model response, then a sudden compile-and-test storm that eats every core and gigabyte it can find. Set the pod’s memory limit low and the OOM killer executes your agent mid-refactor — the K8s equivalent of shooting a surgeon during the operation because he breathed too heavily. Set it high and your cluster bin-packing is fiction.
And the security story is where your platform team starts to sweat. A useful coding agent needs a shell, git credentials, package registries, API keys, and outbound internet. That’s not a workload profile; that’s the textbook description of the thing your cluster policies exist to prevent. Wrapping it in a pod doesn’t contain it — it just gives root-flavored capabilities a service account.
Pets need a stable, long-lived environment with an owner who knows them by name. Cattle infrastructure is engineered — proudly, deliberately — to make that impossible.
What I run instead
I run a fleet of coding agents on a dedicated machine. Not because I read a whitepaper — because I paid for the lesson.
My agents live in tmux sessions, each in its own git worktree, on a host where state survives as long as I need it to. A session can run for thirty hours across seventeen releases, and when I detach and come back, everything is still there: the context, the worktree, the logs, the half-typed plan. The machine is a stable — every horse has a name and a stall.
It’s not free. I’ve become the babysitter the joke warns about: checking tmux liveness, tailing JSONL transcripts to see what a session actually did, nursing sessions that outlived their context window. My orchestration layer has real code whose only job is to answer “is this agent still alive, and what is it doing?” — a question Kubernetes answers for cattle in one line of YAML, and that I had to build by hand for pets.
So no, the answer is not “a home server and tmux forever.” That’s the correct architecture wearing a duct-tape costume.
The wrong lesson and the right one
The wrong lesson from the joke is “never host agents on managed infrastructure.” Agents absolutely need proper hosting: isolation, lifecycle management, remote access, the ability to survive their operator closing a laptop.
The right lesson is that the unit of management is wrong. Kubernetes manages processes and pretends state is someone else’s problem. For coding agents, the session is the state, and it must be the first-class object: created, persisted, attached, detached, handed from one client to another, resumed after the host reboots. A pod is an execution detail underneath that — never the thing itself.
Yes, StatefulSets and persistent volumes exist — but they answer a different question. A PVC gives a pod stable storage and a stable name; it does not checkpoint a conversation. The problem was never that Kubernetes can’t attach durable state to a workload. It’s that the thing it manages — the pod — is still the wrong unit. You can bolt a disk onto an amnesiac; you haven’t given it a memory.
In other words: agents don’t need cattle infrastructure. They need a stable — purpose-built housing where long-lived, stateful, named residents are the design center, not an anti-pattern to be stamped out by a reconciliation loop.
The industry just admitted it
This isn’t me rationalizing my server rack. Watch what shipped in the last few weeks.
VS Code’s latest release restructured around an “agent host” — an explicit runtime for agent sessions, with sessions you can view, attach to, and hand off. Underneath it, Microsoft published the Agent Host Protocol: sessions as portable, first-class objects over JSON-RPC, with multi-client sync and remote execution. Read that spec closely and you’ll notice what it is not: it’s not a scheduler for ephemeral replicas. It’s a protocol for keeping pets alive, findable, and transferable between owners.
The convergence is the tell. When an industry-wide protocol appears whose core abstraction is “a long-lived session with durable state and interactive control,” the debate is over. Nobody writes a portability protocol for cattle. You only need one for things you can’t afford to lose.
I drove one of those sessions over raw JSON-RPC this week. When the last client disconnected, the host logged a single line: Releasing idle session from memory (durable state preserved). That sentence is the whole thesis in passing — you preserve durable state only for residents you intend to see again. You don’t write it for a replica you designed to be identical and disposable.
I’m now spec’ing the migration of my own fleet from hand-rolled tmux babysitting onto that protocol — same architecture, standardized plumbing. The part I got right by scars, the industry is now shipping as infrastructure. The part I built with duct tape, I get to delete.
The closer
The DevOps kid in the joke is right, but not for the reason he thinks. The problem was never the container. The problem is asking infrastructure built to make workloads forgettable to run the one workload whose entire value is that it remembers.
Treat coding agents as cattle and you’ll spend your days herding amnesiacs. Treat them as pets — named, housed, stateful, supervised — and they’ll do thirty-hour shifts for you.
Just don’t make them live in a barn that’s designed to burn down nightly.
I run a fleet of coding agents that ships real software under deterministic gates and human approval steps — the trust ladder I wrote about last time. This piece is about the layer below: where those agents live.