This blog post is also available as video. Watch it here.
As a Forward Deployed Engineer, I am working on how OpenClaw could support thousands of people inside an enterprise.
OpenClaw was originally designed around a personal assistant, where one gateway serves one person or a small trusted team. Everyone inside that environment shares the same trust boundary, so the gateway can own the runtime, connections, and state for the group.
An enterprise deployment changes those assumptions. Tenants need clear boundaries, platform changes need controlled authorization, and user state needs to survive when the compute handling a request is released.
The prototype I built focused on that state problem. Redis Agent File System, or AFS, kept user workspaces in Redis while Kubernetes pods were released and reused. It demonstrated that regular workspace files could remain available when a returning user received a different pod.
RFC 0027 describes the broader enterprise architecture around tenants, Agents, access, deployments, and audit records. AFS is not part of the RFC. I am mapping the prototype onto the boundaries proposed by the RFC to understand where persistent workspaces could fit.
The proposed architecture
The proposal introduces a shared management layer above isolated tenant environments. That layer is the OpenClaw Controller, or OCC. It manages OpenClaw resources and their lifecycle state, authorizes operations, coordinates deployments, selects configured integrations, and produces audit records.
An OpenClaw Namespace is the tenant boundary. In the target use case, a Namespace would most likely represent a customer or team, although the RFC does not require that mapping. OCC manages a dedicated Namespace gateway for Namespace local Channel and Agent runtime traffic. A backing Kubernetes namespace provides an infrastructure boundary for the tenant workloads.
An Installation is the outer administrative boundary for an OpenClaw Enterprise deployment. A Namespace scopes tenant resources and identities. An Agent is the stable resource that an author configures and deploys. Each deployment creates an immutable AgentRevision containing the approved configuration and runtime choices for that version.
The user ID and workspace ID used by the prototype are not a tenant model. They do not prove ownership or establish who may create, update, deploy, or inspect an Agent. Those decisions belong to the enterprise authorization layer.
The Namespace mapping also affects compute. Assigning one Namespace to every end user would retain one dedicated gateway for every user, including users who are inactive. Mapping a Namespace to a customer or team allows its users and workspaces to be authorized within a shared tenant boundary.
OCC coordinates OpenClaw resources while the surrounding systems retain their existing authority. Kubernetes schedules workloads and enforces its infrastructure controls. The identity provider authenticates callers. OCC owns OpenClaw Channel and Secret records, while the external messaging and secret systems own their provider resources, secret values, reusable credentials, APIs, and authorization decisions.
The RFC was accepted on August 1, 2026. As of August 28, 2026, its public implementation tracker remains open, and the RFC lists the OCC API contracts and implementation as future work.
Controlled Agent deployments
Under this model, deploying an Agent becomes a controlled platform operation. The platform separates identity verification, tenant admission, resource authorization, workload creation, isolation, and runtime routing.
A deployment follows this sequence:
- An external identity provider authenticates the person or API client making the request. The OpenClaw Access Gateway verifies that identity evidence and admits the exact Installation and Namespace.
- OCC authorizes the requested action and every protected reference, including the Agent configuration, messaging Channels, Secrets, Harness, and SandboxPolicy.
- OCC records the admitted choices as an immutable
AgentRevision, including the selected compute and sandbox implementations. - The compute integration creates a nonserving candidate workload with the Agent’s stable
WorkloadIdentity. Its Harness remains stopped while the sandbox integration establishes and verifies containment. - OCC prepares the Namespace gateway route, requires the previous revision’s Agent process to stop, records the candidate as active, and permits its Harness to start. The gateway sends traffic only after the active revision reports that it is ready.
Authentication does not grant permission to deploy an Agent, and admission to a Namespace does not grant access to every resource inside it. OCC still checks the caller, action, resource, role bindings, restrictions, and referenced objects.
The workload identity is also separate from the identity of the person who deployed it. On Kubernetes, a dedicated ServiceAccount and short lived pod token back that identity. The workload receives the permissions assigned to the Agent and does not inherit the deployer’s permissions.
Secrets follow the same authority boundary. An OpenClaw Secret is an opaque reference to data held by an external secret system. A SecretBroker mediates the authorized operation, and a selected SecretDriver communicates with the external provider without exposing its reusable backend credentials or underlying secret value to the Agent workload.
OCC records the deployment state and audit evidence. Kubernetes remains responsible for scheduling and execution, while external providers continue authorizing operations against their own resources.
Separating the gateway from execution
The Namespace gateway and the workloads created from Agent revisions have separate lifecycles. The gateway can continue handling Namespace local runtime traffic while Agent workloads are created, replaced, or removed.
This separation matters to the prototype because its current assignment path starts a complete OpenClaw gateway inside every assigned warm pod. In the final benchmark configuration, ten sequential assignment and release cycles produced a mean assignment time of 6.93 seconds with one small workspace and one active environment at a time. Gateway initialization averaged 5.638 seconds, making it the largest measured phase. These figures do not describe concurrent performance or production percentiles.
Keeping the Namespace gateway available while assigning only remote execution could remove gateway initialization from that request path. This remains an architectural inference because the public OCC tracker remains open and OpenClaw does not ship this warm Kubernetes integration.
OpenClaw already contains two components that cover parts of this model. Fleet is an experimental supervisor that runs separate, complete gateway cells for different tenants on one trusted Docker or Podman host. It provides gateway level separation within that host and does not manage a Kubernetes warm pool.
Cloud Workers provide the relevant execution boundary. The gateway retains the transcript, provider credentials, model connection, routing, and last reconciled workspace state while a remote worker runs the Agent loop and its tools. The bundled provider provisions remote compute and synchronizes eligible, size bounded files through a managed Git worktree. It does not assign an existing warm Kubernetes pod or provide a live AFS mount.
A custom Cloud Worker provider could use that execution boundary to select a compatible pod from the warm pool. This provider does not exist today. A warm pod also cannot change its Kubernetes Namespace or ServiceAccount after creation, so the provider would need a pod already compatible with the target tenant and workload identity, an explicit delegation design, or a change to the proposed compute contract.
Why AFS still fits
The RFC leaves workspace storage and directory synchronization unspecified. It does not select or require AFS, and it does not define a Workspace resource. That open storage boundary allows the target architecture to use AFS as its persistent workspace layer.
AFS stores directory metadata and file contents in Redis, then exposes the workspace through a live FUSE mount. OpenClaw continues using ordinary filesystem operations while the workspace remains independent of the pod running the Agent.
When a user becomes active, the pool can select a compatible warm pod and mount the authorized workspace into it. When the assignment ends, the workspace is unmounted, disposable state is cleaned, and the pod returns to the pool. The files remain in Redis, so another compatible pod can mount the same workspace later.
Selecting the workspace at assignment time also keeps user storage outside the pod lifecycle. The pod does not need a user specific volume declared when it is created, and Kubernetes does not need to manage one PersistentVolume and PersistentVolumeClaim for every user. The live mount also avoids copying the complete workspace into the pod before OpenClaw can access it.
The prototype demonstrated this behavior for regular workspace files. OpenClaw read and wrote them through normal file operations, and those files survived release and reassignment between pods. That result is scoped to the prototype and does not establish general production behavior for AFS.
Connecting this storage layer to OCC requires an explicit workspace contract. OCC would need a protected reference that maps an authorized Agent or session to an AFS workspace. OCC could then authorize the reference, while AFS provides the approved filesystem to the selected workload. The mutable workspace contents would remain outside the immutable AgentRevision.
The production integration also needs to align the mount with the RFC security model. The prototype runs a privileged FUSE process beside OpenClaw and gives that process reusable Redis credentials. A production design would need containment that the sandbox integration can verify and credentials scoped to the authorized workspace. Filesystem durability, locking, atomic rename, fsync(), SQLite behavior, cache coherence, concurrent mounts, tenant isolation, and scale still require validation.
AFS has a clear role in this architecture for persistent regular workspace files. OCC would provide governance and authorization, the worker integration would provide execution, and AFS would keep the authorized files available independently of the selected worker.
Under the combined design, OCC would coordinate tenant gateways and Agent deployments, a custom Cloud Worker provider would select compatible Kubernetes workers, and AFS would keep user workspaces available independently of those workers.
RFC 0027 is an accepted architecture. The specific integration of OCC, warm Kubernetes workers, and AFS remains a prototype concept that still requires implementation and production validation.
Stay curious!