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.
Yeah, I feel like k8s is adds unneeded complexity. I started this project to isolate via LXC/Incus containers on a VPS/server. Works nicely for my needs.
Makes sense, if your agents need full desktop and GUI automation VMs are the way to go. klaw is more on the headless side, agents talking to APIs, Slack, X, that kind of thing, so the lightweight binary model works. How many agents are you running on Proxmox?
Ahh, that makes sense. Yeah you likely have a very different business model. We're more using them as "AI employees" that help us with tasks. Currently running 4 of these VMs but planning to add more.
Note that each VM has a specific role: cluster monitoring, database stats, frontend/backend features (this is where VMs really shine) and a (very experimental) high-level manager.
We found that it works great for scraping but it's not so great for development. git worktrees in a VM are much faster over spinning up new containers with an existing codebase.
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.
Very interesting! I’ll certainly try it out. I am wondering though what’s the advantage over doing it with a K8s operator (disclaimer, I created and maintain https://github.com/openclaw-rocks/k8s-operator)?
Also, I am genuinely curious about the choice of license.
Given the „new (agentic) way“ in that software is being developed now, don’t you think it can be copied easily and that this kind of license will hinder adoption at some point?
Thanks! The main advantage is simplicity. klaw is a single binary with zero dependencies, no k8s cluster required. For teams already running Kubernetes your operator makes a lot of sense, but most teams we've talked to managing AI agents don't have or want a k8s setup just for that. klaw gives them the same mental model without the infrastructure overhead.
On the license, fair question. The SaaS restriction is narrow, it only prevents someone from reselling klaw as a hosted orchestration service. Internal use, building on it, extending it is all fine. We looked at what Elastic and HashiCorp did and felt this was the right balance for now. Could it slow adoption? Maybe. But we'd rather start here and open up further based on how the community evolves.
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.
It is under a license that prevents using the source in any way you choose:
You may not use the klaw source code to operate a multi-tenant managed
service (Software as a Service) where the primary value proposition is
providing AI agent orchestration capabilities to third parties, unless
you have obtained explicit written authorization from each::labs.
It's source-available, which is cool, but don't muddy the waters.
This looks like what I want. A few questions: is it possible to have a “mayor” type role that has the ability to start other agents, but at the same time be unable to access those secrets or infiltrate prompt data? The key piece I don’t see is the agent needs a tool for klaw itself, and then I have to be able to configure that appropriately.
Is there a unified human approval flow, or any kind of UI bundled with this? Maybe I missed this part.
Right now the controller can see secrets across namespaces, so that level of isolation isn’t there yet. It’s on the roadmap though. Namespace-scoped secrets where a controller agent can spawn agents but can’t read their secrets is the right model.
No human approval flow yet either, agents create directly. Would you want something like klaw dispatch --approve that queues until a human confirms?
My instinct is that it should be built in to tool calls. So if there was a "klaw dispatch tool", it would have the same approval flow as the "publish draft" tool, which is to say some easy way for a human to review and approve (or provide feedback).
helpful framing: this feels less like k8s itself and more like "fleet ops for agents". k8s solved deploy/observe/isolate for containers, youre mapping that control plane idea to agent workers.
would be great to add one concrete diagram in the readme (controller, namespace, agent runtime, secret boundary). i think that would remove most confusion in this thread quickly.
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.
You should consider looking at oh-my-opencode for inspiration (similar to gas town) for how to best orchestrate agents from your controller central brain.
This looks great though, will definitely give it a try
the binary is built from the repo, it's Go so we distribute compiled binaries like most Go CLI tools (kubectl, terraform, hugo). All agent communication goes through your own configured LLM provider, klaw doesn't proxy or store any prompts.
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.
Welcome to the future. We deploy infrastructure for managing bots that post on Twitter to get other bots to convince their people to buy our infrastructure. Our marketing is for the bots, by the bots.
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.
Yeah, I feel like k8s is adds unneeded complexity. I started this project to isolate via LXC/Incus containers on a VPS/server. Works nicely for my needs.
https://github.com/jgbrwn/vibebin
Makes sense, if your agents need full desktop and GUI automation VMs are the way to go. klaw is more on the headless side, agents talking to APIs, Slack, X, that kind of thing, so the lightweight binary model works. How many agents are you running on Proxmox?
Ahh, that makes sense. Yeah you likely have a very different business model. We're more using them as "AI employees" that help us with tasks. Currently running 4 of these VMs but planning to add more. Note that each VM has a specific role: cluster monitoring, database stats, frontend/backend features (this is where VMs really shine) and a (very experimental) high-level manager.
I got this issue too, but still found that a containerized desktop was superior due to resource efficiency
I have never had an issue with browser automation like selenium in containers. Is that actually an issue?
We found that it works great for scraping but it's not so great for development. git worktrees in a VM are much faster over spinning up new containers with an existing codebase.
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.
Is there any current solution elsewhere for hardware scheduling?
Yes, klaw has a controller-node architecture. You join machines to a cluster with klaw node join and deploy agents to specific nodes.
I added distributed agent management functionality
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.
Very interesting! I’ll certainly try it out. I am wondering though what’s the advantage over doing it with a K8s operator (disclaimer, I created and maintain https://github.com/openclaw-rocks/k8s-operator)?
Also, I am genuinely curious about the choice of license.
Given the „new (agentic) way“ in that software is being developed now, don’t you think it can be copied easily and that this kind of license will hinder adoption at some point?
Thanks! The main advantage is simplicity. klaw is a single binary with zero dependencies, no k8s cluster required. For teams already running Kubernetes your operator makes a lot of sense, but most teams we've talked to managing AI agents don't have or want a k8s setup just for that. klaw gives them the same mental model without the infrastructure overhead.
On the license, fair question. The SaaS restriction is narrow, it only prevents someone from reselling klaw as a hosted orchestration service. Internal use, building on it, extending it is all fine. We looked at what Elastic and HashiCorp did and felt this was the right balance for now. Could it slow adoption? Maybe. But we'd rather start here and open up further based on how the community evolves.
Fair enough!
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.
It is under a license that prevents using the source in any way you choose:
It's source-available, which is cool, but don't muddy the waters.Neither in letter (OSI) nor in spirit...
This looks like what I want. A few questions: is it possible to have a “mayor” type role that has the ability to start other agents, but at the same time be unable to access those secrets or infiltrate prompt data? The key piece I don’t see is the agent needs a tool for klaw itself, and then I have to be able to configure that appropriately.
Is there a unified human approval flow, or any kind of UI bundled with this? Maybe I missed this part.
Right now the controller can see secrets across namespaces, so that level of isolation isn’t there yet. It’s on the roadmap though. Namespace-scoped secrets where a controller agent can spawn agents but can’t read their secrets is the right model. No human approval flow yet either, agents create directly. Would you want something like klaw dispatch --approve that queues until a human confirms?
My instinct is that it should be built in to tool calls. So if there was a "klaw dispatch tool", it would have the same approval flow as the "publish draft" tool, which is to say some easy way for a human to review and approve (or provide feedback).
got your feedback, it can run cli commands but for tool calling / skill should be built in, will add that!
helpful framing: this feels less like k8s itself and more like "fleet ops for agents". k8s solved deploy/observe/isolate for containers, youre mapping that control plane idea to agent workers.
would be great to add one concrete diagram in the readme (controller, namespace, agent runtime, secret boundary). i think that would remove most confusion in this thread quickly.
will add that! thanks
just updated README file thanks for your feedback!
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.
There are a number of other aspects that make kubernetes what it is. In particular the API surface is well defined at a very good abstraction level.
For Ai, I'm using ADK. It's my "kubernetes for agents" from this perspective of abstractions and common task management handled by the system.
https://google.github.io/adk-docs/get-started/about/
You should consider looking at oh-my-opencode for inspiration (similar to gas town) for how to best orchestrate agents from your controller central brain.
This looks great though, will definitely give it a try
Thanks, will check it out! Let me know how it goes.
I know K8S and other software orchestration systems well, but I admit I don't understand this at all. Can someone ELI5?
fake git repository, no actual code, just an opaque binary. No way to know what these guys are doing with your prompts or code.
the binary is built from the repo, it's Go so we distribute compiled binaries like most Go CLI tools (kubectl, terraform, hugo). All agent communication goes through your own configured LLM provider, klaw doesn't proxy or store any prompts.
Looks like what your shipping is not what's in the repo...
``` klaw.sh git:(main) make go build -ldflags "-s -w -X main.version=v0.1.0-7-g02b1591" -o bin/klaw ./cmd/klaw stat /home/stobias/repos/personal/misc/klaw.sh/cmd/klaw: directory not found make: ** [Makefile:12: build] Error 1 ```
oops, will check that ASAP, can you please try with curl and sh?
fixed
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.
You should consider changing the subtitle then. Maybe "Kubernetes-like by AI" or "AI Kubernetes imitation" or ...?
I would agree. I don’t use k8s and assumed I couldn’t use this as a result…
let's call it clawshnikov next time
Welcome to the future. We deploy infrastructure for managing bots that post on Twitter to get other bots to convince their people to buy our infrastructure. Our marketing is for the bots, by the bots.