ClawManager: A Kubernetes Control Plane for AI Agent Instances

The problem ClawManager targets: many agent runtimes, no shared governance

Running one agent runtime is a script. Running four of them across a team is an inventory problem. The README lists OpenClaw, Hermes, OpenCode and DeepSeek Harness as supported runtimes, and the Northbound API entry for 2026-09-02 mentions provisioning for all four plus asynchronous lifecycle operations and Share Link management. Each runtime brings its own desktop, its own skill format and its own way of reaching a model provider. Without a shared layer you end up with per-runtime credentials, per-runtime audit gaps and no single place to answer who is running what.

ClawManager's answer is to make the agent instance the unit of management and put it behind a control plane. The stated scope is governed AI access, runtime orchestration and reusable resources across multiple agent runtimes. The audience follows from that: platform or infrastructure engineers who already run Kubernetes and are being asked to support agent workloads for other people, not individual developers experimenting on a laptop. The MIT licence removes the licensing conversation, but it does not remove the cluster.

Lite and Pro: the isolation decision is the architecture

The most consequential design choice visible in the material is the split between Lite and Pro runtime modes, added on 2026-06-14. Lite instances run through shared gateway runtime pools. Pro instances get dedicated desktop deployments. That is a real trade-off rather than a marketing tier: shared pools reduce the number of pods and desktops you have to schedule, at the cost of co-tenancy between agent instances. Dedicated desktops invert it.

The DeepSeek Harness entry from 2026-08-16 repeats the pattern, describing shared runtime-pool isolation plus dedicated Webtop desktops and dedicated Lite browser origins. The phrase shared runtime-pool isolation suggests the pool boundary is the isolation unit, so two Lite instances in the same pool are not isolated from each other in the way two Pro instances are. The documentation does not spell out the threat model for that boundary in the README, which is the first thing I would look for in the runtime guides before putting untrusted agent workloads into a shared pool.

A separate detail worth noting: Lite instances get their own browser origins. That matters if agents drive a browser, because origin separation is what keeps cookies and storage from bleeding between instances. It is a small line in the release notes and one of the more specific security claims in the material.

What the control plane actually coordinates

Three subsystems recur across the release notes. The AI Gateway handles model access: the 2026-03-26 documentation refresh covers model governance, audit and trace, cost accounting and risk control, and later entries add model-managed Thinking and Session Usage reporting. The Agent Control Plane handles instance registration and lifecycle, with Hermes provisioning described as including Agent Control Plane registration, AI Gateway injection, channel and skill bootstrap, and .hermes import/export. The security layer, called secplane, is a frontend console covering runtime defense across input, state, decision and output surfaces, asset tamper-proofing, human approval, host hardening and container isolation, outbound trusted-endpoint governance, policy governance, a kill-switch and circuit-breaker, full-chain audit, and input detection.

So the data flow implied by the README is: an instance is provisioned into a runtime, registered with the control plane, injected with gateway configuration, bootstrapped with channels and skills, and then observed and constrained by the gateway and secplane. The README does not include a diagram of this flow or the CRD definitions, so the exact Kubernetes objects ClawManager creates are not confirmable from the supplied material. If you need to know whether it uses custom resources, operators or plain Deployments, that has to come from the repository, not from the README.

Getting it running: what the material does and does not give you

This is where the supplied material is thinnest, and it is worth being blunt about it. The README has a Get Started section in its navigation, but the text provided here is truncated before that section's content. The only concrete installation requirements I can confirm are the badges: Go 1.21+ and React 19, with Kubernetes Native as the deployment target. There are no helm install commands, no kubectl apply examples, no manifest paths and no configuration keys in the material I have.

What the material does name are documentation files you would read next: docs/northbound-api-guide.md for the Northbound API, docs/aigateway.md for the gateway, docs/hermes-runtime-agent-development.md for Hermes, and docs/opencode-lite-pro-agent-development_en.md for OpenCode workspaces. Those are the entry points. I have not installed or run ClawManager, and I am not going to invent a quickstart. Treat the absence of a copy-pasteable install path in the README as a signal about who the project expects: someone comfortable reading manifests and the repository tree.

The one operational detail the release notes do give is version-aware preflight. The 2026-09-08 entry describes hardened data-safe OpenClaw Lite rollouts with version-aware preflight, migration verification, bounded recovery and source-identity rollback, and states that legacy images without the 8.1 capability marker continue to use the established rolling-update path. That is a real upgrade constraint: if your images predate the marker, you stay on the old path, and you should confirm which path your images take before scheduling a rollout.

Team workspaces and the collaboration layer

The Team workspace MVP landed 2026-05-18 with one-click Team creation, OpenClaw member orchestration, Redis Team Bus injection, shared storage, member status, task dispatch and event and result views. The 2026-08-18 update expanded it with eight read-only built-in templates, natural-language custom templates, optional Hermes Lite Workers, a live Execution Kanban, shared artifacts and member-session visibility.

Redis Team Bus injection is the mechanism to note. It means team coordination runs over Redis rather than through the control plane's own API, which implies a Redis dependency in the cluster and a message bus that agent members share. That is a sensible way to get low-latency coordination between agents, and it also means the bus becomes part of your availability and access-control surface. The README does not describe how the bus is authenticated or segmented, so that is another item for the runtime guides.

The eight built-in templates are read-only, and custom templates are described as natural-language. That is a lower ceiling than a schema-driven template system, and it suggests the templates are prompts and scaffolding rather than strictly validated configuration.

Where ClawManager is the wrong tool

If you run exactly one agent runtime and one operator, ClawManager is overhead. You would be adopting a control plane, an AI gateway, a security console and a portal to manage a single instance that a container and an environment variable would cover. The Lite and Pro distinction, the Team bus, the skill scanning and the secplane console all exist to solve multi-instance, multi-user problems.

There is a second case: teams without Kubernetes. The README is explicit that this is Kubernetes-native, and nothing in the material suggests a non-Kubernetes deployment path. If your infrastructure is a single VM or a managed container service, you would be standing up a cluster to run the manager.

The third case is subtler. The security console is described as covering a long list of surfaces, and a long list of surfaces is also a long list of things to configure and keep current. A team that wants agent isolation but not policy governance, outbound endpoint allowlists and human approval workflows may find secplane to be surface area they have to disable rather than use. The material does not indicate whether secplane components can be omitted cleanly, so this is a question for the deployment docs.

How it compares to running agents directly on Kubernetes

The obvious alternative is not another agent manager. It is doing this yourself: write Deployments or a small operator for each runtime, put an API gateway such as Envoy or LiteLLM in front of model providers, and use your existing policy tooling for egress control. That approach gives you exactly the primitives you choose and nothing else, and it fits teams that already have a gateway and a policy stack.

The difference in approach is where the abstraction sits. A hand-rolled setup treats each agent runtime as an application you deploy. ClawManager treats the agent instance as a first-class object with a lifecycle, a runtime mode, a gateway binding, a skill set and a security posture, and it spans four runtimes with that same object model. The 2026-09-02 Northbound API entry, with asynchronous lifecycle operations and Share Link management, is the clearest expression of that: lifecycle is an API concern, not a kubectl concern.

The cost of that abstraction is that you inherit ClawManager's opinions about runtimes and its release cadence. The release list shows v2026.9.8, v2026.9.9 and v2026.9.10 on three consecutive days. Daily patch releases are a good sign for responsiveness and a warning for anyone who wants a frozen version. If you pin, pin deliberately and read the upgrade notes, because at least one recent release changed the rollout path for OpenClaw Lite.

Maintenance, licence and what to verify before adopting

ClawManager is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the whole of the licence implication I can state; anything about your organisation's obligations beyond the licence text is a question for your own counsel, not for this article.

Maintenance cost is dominated by the number of moving parts rather than by the codebase. A deployment implies Kubernetes, the control plane, the portal, the AI gateway, and for Team workspaces a Redis bus, plus whichever runtimes you enable and their desktops. Each of those has its own upgrade path, and the release notes show that runtime integrations change: Hermes arrived 2026-04-29, OpenCode workspaces 2026-08-19, DeepSeek Harness 2026-08-16. Budget for reading release notes on every bump, not just for applying them.

The upgrade risk is concentrated in the OpenClaw Lite path. The 2026-09-08 note describes preflight, migration verification, bounded recovery and source-identity rollback for data-safe rollouts, with legacy images without the 8.1 capability marker staying on the established rolling-update path. Verify which path your images take, and verify it on a non-production namespace first. Beyond that, read the Northbound API guide before building anything against the API, because asynchronous lifecycle operations mean your integration has to handle operations that are not complete when the call returns. That is the detail most likely to bite an integration written against the wrong assumption.

Editorial conclusion

Adopt ClawManager only if you already operate Kubernetes and need several agent runtimes governed through one gateway and one portal; teams without a cluster, or anyone wanting a single-runtime local setup, will pay more in operational surface than they get back. Before installing, verify three things against the docs: how Lite versus Pro runtime modes map onto your isolation requirements, whether the 8.1 capability marker applies to your existing OpenClaw images given the preflight and rollback path described for the 2026-09-08 release, and which runtimes your version actually provisions.

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. Yuan-lab-LLM/ClawManager on GitHub