Today, we are excited to contribute the support for NemoClaw in the CNCF kagent project. Since launching kagent a little over a year ago, we've seen significant interest: over 12 million downloads, hundreds of contributors, and some of the largest companies running their agents on Kubernetes with kagent. Kagent is becoming the de facto agent runtime for Kubernetes. We've supported declarative agents and bring-your-own (BYO) frameworks. With NemoClaw, we're supporting a new class of agent: the agent harness. NemoClaw today is a single-node, single-developer experience. We're adding it as a first-class option in kagent so it can run as a managed multi-tenant fleet on any Kubernetes cluster.
Kagent has been primarily oriented around platform teams building agentic ops. With the Agent CRD, an SRE can specify a model, skills, MCP tools, and expose an A2A endpoint to get powerful agent ops without writing a single line of code. If that didn't work for you, bring your own framework: LangChain, CrewAI, Google ADK, et.al. All of these agents get observability, workload identity, memory plugins, and access policies. This works great for teams building their own agents. They own the prompt, the tool set, and the operational posture.
An agent harness is different. It's not an agent you author: it's an agent system you adopt. Examples include OpenClaw, Hermes, Goose, and Claude Code. These ship as full systems: a CLI, a terminal UI, a skills registry, messaging integrations, a built-in tool ecosystem with plugins, and a highly tuned agent loop. The user doesn't write a system prompt, rather they install the harness and start using it.
The harness pattern raises questions. How do you enable users to adopt this securely? How do you plug it into an observability pipeline? How do you take what NemoClaw is today, a single-tenant workstation experience, and turn it into a control plane that offers identity, policy, observability, and multi-tenancy? That's what kagent + NemoClaw is.
How it fits together
NemoClaw is NVIDIA's open-source reference for running OpenClaw safely. We're adding it as a first-class option in kagent. What does that mean?
There are four layers in the stack:
- kagent: control plane
- NemoClaw: agent harness blueprint/configuration
- OpenShell: hardened in-pod sandbox/shell
- agent-sandbox (SIG Apps): Kubernetes-native sandbox primitive
Going bottom up:
agent-sandbox: Running an isolated sandbox doesn't fit the out-of-the-box Kubernetes constructs (Deployment, StatefulSet, etc.). These sandboxes are stateful, named, and have a stable identity, but they're not a numbered set the way StatefulSets are. Neither shape fits cleanly. That's where the agent-sandbox project comes in. It models pods as stateful singletons using a Sandbox CRD. It also offers operational patterns that work around drawbacks of the Kubernetes pod model: a pre-warmed pool of sandboxes that can be claimed by a session on demand. More on this in the closing section.
OpenShell: OpenShell composes with agent-sandbox as the runtime that operates inside a Sandbox pod. It takes over inside the pod to lock down the running processes. It establishes kernel-level isolation: it locks the harness into a network namespace with no route to the real network. All traffic to and from the harness goes through a configurable HTTP CONNECT proxy. It uses Landlock and seccomp to limit what the harness can do within the sandbox. The agent cannot override any of this.
NemoClaw: NemoClaw adds the wiring on top of OpenShell to run the OpenClaw harness. It provides blueprint configurations for OpenShell, policy bundles, and hardened out-of-the-box images. NemoClaw handles the difficult wiring so you don't have to.
kagent: kagent owns everything outside the pod. It's the control plane: which agent runs where, which identity it carries, which MCP tools it can reach, what observability it emits, who is allowed to claim a session, and when the session expires. kagent treats the NemoClaw blueprint as a registered workload type, exposes it to users, and lets the platform team set the policy around it. Where NemoClaw's blueprint ships sensible defaults, including for the model, kagent lets you override them: choose a different provider, swap inference endpoints, apply identity policy on top.
What's still hard
NemoClaw on kagent is a real step. It isn't the end of the story. Here's what we're working on in the open.
The pod isn't really the right unit for an agent. Pods were designed for request-response services with predictable resource curves. Agents are long-lived, bursty, and idle most of the time. We need lighter-weight isolation primitives: Firecracker microVMs, gVisor, Kata Containers and real lifecycle support: suspend, snapshot, resume, scale-to-zero with state preserved. Agent-sandbox is a step in the general direction, and we are working with the community to improve this.
Agent identity shouldn't live with the pod. The pod is ephemeral. The agent's principal: its workload identity, its delegations, its consented authorizations all outlive the pod and travel with it. SPIFFE gives us the workload identity primitive. WIMSE in IETF is how we can map workload identity outward. Agent-specific identity and delegation protocols like AAuth are worth exploring here.
Policy is fragmented across layers OpenShell enforces network and kernel policy inside the pod. kagent enforces identity and access policy into/out of it. There should be one runtime policy plane with consistent identity, consistent decision logging, consistent escalation. We're working with the community to build toward that.
We are excited to work on these problems with our partners in the open-source community. If you’re interested in this too, please get involved! Check out kagent today!
%20a%20Bad%20Idea.png)
%20For%20More%20Dependable%20Humans.png)
