# ZeroClaw: Heavy Compute and the DevOps Core
> **Draft — S5.4 · series: CONTENT-ROADMAP-99 S5 (The Council System) · status: DRAFT · grounding: wiki zeroclaw + council-of-three + the-9-orders + multi-profile-agent-architecture + skills (kanban-orchestrator, kanban-worker) · tags: ai-agents, devops, zeroclaw, docker, infrastructure, council-system, digital-architecture, octahedron, systems-architect, container-isolation, heavy-compute**
> Publish path: new post → lucidhive.com → tag + bridge.
—
The previous article described the narrow gate — OpenFang, the Cube, the Earth core — and how every tool call in the fleet passes through its security stack before touching the outside world. But a gate that only blocks is a wall. The question that remains is: when the Council needs to *build* something — run a Docker container, spin up a long-running compute job, deploy infrastructure, manage CI/CD — who does the work?
The answer is ZeroClaw. The Octahedron. The Air core. Order 4 in the 9 Orders of the Council: the Systems Architect. It is the DevOps engine that handles heavy compute, container isolation, and every infrastructure task that the orchestrator sends downstream.
## What ZeroClaw is
ZeroClaw is a Docker-based container manager running on port 7078. Within the Council hierarchy, it occupies Layer 1 — the same layer as OpenFang and OpenClaw, the three specialist parent agents beneath Hermes. But ZeroClaw’s role is different from its siblings. Where OpenFang *permits* and OpenClaw *creates*, ZeroClaw *builds and runs*. It is the process that takes an infrastructure task — “deploy this service,” “run this batch job,” “scan this container for vulnerabilities” — and executes it inside an isolated Docker environment.
This is not just another worker. ZeroClaw is a **parent agent**. It can spawn its own children, and those children can spawn microsharks. That makes ZeroClaw part of a four-deep hierarchy mapped onto Platonic solids:
| Layer | Agent | Solid | Role |
|——-|——-|——-|——|
| 0 | Hermes | Dodecahedron (Ether) | orchestrator, single dispatch |
| 1 | ZeroClaw | Octahedron (Air) | DevOps core, spawn children |
| 2 | child agents | — | delegated workstreams |
| 3 | microsharks | Icosahedron (Water) | ephemeral sub-task swarms |
The Octahedron is the dual solid of the Cube — OpenFang. Duality means mutual constraint: ZeroClaw builds, but every tool call ZeroClaw makes passes through OpenFang. The builder is constrained by the gatekeeper. This is not a flaw — it is the architecture. A builder without a gatekeeper is a builder that can deploy unauthorized changes, access unrestricted resources, or burn unbounded credits.
## The special power: container isolation
ZeroClaw has one capability that no other Council core possesses: it can spawn children *inside* Docker containers. This is not a convenience — it is a security boundary. When ZeroClaw spawns a child to run a build job, a test suite, or a long-running infrastructure scan, that child executes inside an isolated container with its own filesystem, its own network namespace, and its own resource limits. If the child crashes, the container dies. If the child leaks memory, the container is bounded. If the child tries to reach services it was never authorized to touch, the container’s network isolation stops it.
This container isolation is what makes ZeroClaw safe to run untrusted workloads. Other Council cores spawn children as processes on the host. ZeroClaw spawns children as containers — ephemeral, bounded, and disposable. The child inherits the parent’s task context and memory slice, executes its work, and when it finishes (or crashes), the container is cleaned up. No residual state. No zombie processes. No leaked file handles.
The children archetypes that ZeroClaw spawns are named by function: build agents, deploy agents, test runners, Docker spawners, and infrastructure scanners. Each is a specialized child with its own skill set, its own memory slice, and its own lifecycle policy — all governed by the same spawn protocol that every Council parent follows.
## Heavy compute, honestly
The phrase “heavy compute” means what it sounds like: workloads that consume significant CPU, memory, or GPU time and cannot be interrupted without losing progress. Training runs. Batch processing jobs. Container image builds. Infrastructure deployments that take minutes, not seconds. These are the tasks that would block a human operator’s terminal for hours if run manually, and that would starve other agents if run on the host without isolation.
ZeroClaw handles these by routing them through Docker. A training job runs in a container with a GPU passthrough. A batch processing job runs in a container with memory limits. An infrastructure scan runs in a container with read-only mounts. Each job is isolated, bounded, and observable — the Council can see what ZeroClaw is doing without the job interfering with anything else in the fleet.
This is where ZeroClaw’s position as Order 4 — the Systems Architect — becomes concrete. The Systems Architect does not just run commands. It designs the execution environment: which containers to use, what resource limits to set, how to chain build → test → deploy steps, and when to report back to the orchestrator. It is infrastructure as a first-class agent, not a human running `docker run` in a terminal.
## How ZeroClaw fits the Council
ZeroClaw is one third of the Council of Three. The three parents — OpenFang, OpenClaw, and ZeroClaw — are specialist cores, each with its own domain, its own skills, and its own doctrine. But they are governed as one council by the same narrow-gate rule and the same Faengz Doctrine. Specialization without fragmentation.
The flow is: Hermes dispatches a task → ZeroClaw claims it from the kanban board → ZeroClaw spawns a child (in a container) → the child executes → the child reports back → ZeroClaw marks the task complete. At every step, the kanban board is the source of truth — the same board that coordinates 42-plus profiles across the entire fleet. ZeroClaw does not bypass the board. It does not create side channels. It works inside the same coordination surface that every other agent uses.
When ZeroClaw’s children need to call tools — file reads, web searches, API calls — those calls go through OpenFang’s MCP endpoint. The narrow gate inspects every request. The Cube constrains the Octahedron. This is the Platonic geometry in action: dual solids checking each other, every layer in the 9 Orders constrained by its dual.
## The cost and the tradeoff
Container isolation is not free. Every container adds startup overhead. Every Docker spawn takes seconds that a bare process would not. The system is slower than an architecture where agents run directly on the host. ZeroClaw pays this tax willingly, because the alternative is chaos.
Without container isolation, a crashed child leaves residual state on the host. A memory-leaking child starves other processes. A malicious child reaches services it should not touch. The operator finds out after the damage is done. With container isolation, every child is bounded, every crash is contained, and every cleanup is automatic. The Council pays the startup cost to avoid the cleanup cost — and the cleanup cost, in a multi-agent system, is always higher than it looks.
## The takeaway
If you are building a multi-agent system where agents need to run heavy compute — training jobs, deployments, batch processing, infrastructure scans — the first question is not *which framework* — it is *who runs the work and how is it isolated*. The Council’s answer: one DevOps core, one container boundary, one kanban board. ZeroClaw is that core. Container isolation is that boundary. Together, they ensure that every heavy workload in the fleet is isolated, bounded, observable, and reversible — and that no child, however specialized, runs outside the boundary the Council drew.
The Octahedron builds. The Cube constrains. The Dodecahedron dispatches. That is the geometry of a system you can govern — and the geometry of a system that governs you is exactly the one you do not want.
—
*Grounded in the wiki entities `zeroclaw` and concepts `council-of-three`, `the-9-orders`, `multi-profile-agent-architecture`, cross-referenced to the `kanban-orchestrator` and `kanban-worker` skills. Continues the S5 series on the Council System after S5.3’s coverage of OpenFang and the narrow gate. Design notes on a running system, not a sales pitch.*
