For us, we actually moved away from k8s to dedicated VMs on Proxmox for our agents. We initially had a containerized environment manager running in k8s, but found that VMs give you things containers struggle with: full desktop environments with X11 for GUI automation, persistent state across sessions and dedicated resources per agent. Each agent gets their own Debian VM with a complete OS, which makes it much easier to run tools like xdotool and browser automation that don't play well in containers.
I don’t quite get what makes it Kubernetes for AI agents. Is the idea to pool hardware together to distribute AI agents tasking? Is the idea to sandbox agents in a safe runtime with configuration management? Is the idea something else entirely? Both? I couldn’t figure it out by the README alone.
Mostly the second, plus fleet management. Each agent runs in an isolated namespace with its own config, channels, and skills. You manage them declaratively like you would pods, but the unit of work is an AI agent instead of a container.
The Kubernetes analogy is about the operational model: clusters for org isolation, namespaces for team isolation, declarative deploys, central monitoring. Not about hardware scheduling.
I'll improve the README to make this clearer, good feedback.
Ha! This is great. I've been waiting for someone to make this.
Giving an LLM a computer makes it way more powerful, giving it a kubernetes cluster should extend that power much further and naturally fits well with the way LLMs work.
I think this abstraction can scale for a good long while. Past this what do you give the agent? Control of a whole Data Center I guess.
I'm not sure if it will replace openclaw all together since kubernetes is kind of niche and scary to a lot of people. But I bet for the most sophisticated builders this will become quite popular, and who knows maybe far beyond that cohort too.
Thanks! The "Kubernetes is scary" point is fair, that's why the CLI is designed to feel intuitive even if you've never touched kubectl. There's also a controller agent that manages the whole cluster from plain English.
On "what comes after", I think it's agents managing other agents. An AI SRE that watches load and spins up new agents automatically. The cluster/namespace model was designed with that direction in mind.
And yeah, not trying to replace OpenClaw, different layer.
OpenClaw defines what an agent does, klaw manages where and how many run. Complementary.
Correct, it's not a k8s operator. Standalone binary, zero dependencies. Just uses the same mental model because clusters and namespaces map really well to multi-team agent management.
No, klaw is standalone. It borrows the mental model from Kubernetes (clusters, namespaces, declarative config) but doesn't depend on it. Single binary, runs anywhere.
Also worth noting, Gas Town and klaw solve different problems. Gas Town orchestrates coding agents on a codebase. klaw orchestrates operational agents (social media, support, sales) across teams and platforms. Different layer entirely.
For us, we actually moved away from k8s to dedicated VMs on Proxmox for our agents. We initially had a containerized environment manager running in k8s, but found that VMs give you things containers struggle with: full desktop environments with X11 for GUI automation, persistent state across sessions and dedicated resources per agent. Each agent gets their own Debian VM with a complete OS, which makes it much easier to run tools like xdotool and browser automation that don't play well in containers.
I don’t quite get what makes it Kubernetes for AI agents. Is the idea to pool hardware together to distribute AI agents tasking? Is the idea to sandbox agents in a safe runtime with configuration management? Is the idea something else entirely? Both? I couldn’t figure it out by the README alone.
Mostly the second, plus fleet management. Each agent runs in an isolated namespace with its own config, channels, and skills. You manage them declaratively like you would pods, but the unit of work is an AI agent instead of a container. The Kubernetes analogy is about the operational model: clusters for org isolation, namespaces for team isolation, declarative deploys, central monitoring. Not about hardware scheduling. I'll improve the README to make this clearer, good feedback.
Ha! This is great. I've been waiting for someone to make this.
Giving an LLM a computer makes it way more powerful, giving it a kubernetes cluster should extend that power much further and naturally fits well with the way LLMs work.
I think this abstraction can scale for a good long while. Past this what do you give the agent? Control of a whole Data Center I guess.
I'm not sure if it will replace openclaw all together since kubernetes is kind of niche and scary to a lot of people. But I bet for the most sophisticated builders this will become quite popular, and who knows maybe far beyond that cohort too.
Congrats on the launch!
Thanks! The "Kubernetes is scary" point is fair, that's why the CLI is designed to feel intuitive even if you've never touched kubectl. There's also a controller agent that manages the whole cluster from plain English.
On "what comes after", I think it's agents managing other agents. An AI SRE that watches load and spins up new agents automatically. The cluster/namespace model was designed with that direction in mind.
And yeah, not trying to replace OpenClaw, different layer.
OpenClaw defines what an agent does, klaw manages where and how many run. Complementary.
In first read I thought this was an operator for k8s, but it is just comparing itself.to k8s as an orchestration system.
Correct, it's not a k8s operator. Standalone binary, zero dependencies. Just uses the same mental model because clusters and namespaces map really well to multi-team agent management.
Is this intended to deploy onto k8s?
No, klaw is standalone. It borrows the mental model from Kubernetes (clusters, namespaces, declarative config) but doesn't depend on it. Single binary, runs anywhere.
In case anyone is interested because "Kubernetes for agents" sounds innovative: https://medium.com/p/welcome-to-gas-town-4f25ee16dd04?source...
Also, Kubernetes and Gas Town are open source, but this is not.
Edit: the Medium link doesn't jump down to the highlighted phrase. It's "'It will be like kubernetes, but for agents,' I said."
It is open source: https://github.com/klawsh/klaw.sh
Also worth noting, Gas Town and klaw solve different problems. Gas Town orchestrates coding agents on a codebase. klaw orchestrates operational agents (social media, support, sales) across teams and platforms. Different layer entirely.
Neither in letter (OSI) nor in spirit...