v0.4 — February 2026

Every agent framework in existence answers the same question: how do I make agents collaborate on tasks? Swarm coordinates handoffs. CrewAI assigns roles. LangGraph builds execution graphs. AgentStack scaffolds projects. They are all application-layer orchestration systems built on a shared assumption: the agent is a trusted process doing work for the operator.

Clawdapus starts from the opposite premise. The agent is an untrusted workload.

It is a container that can think, and like any container, it must be reproducible, inspectable, diffable, and killable. Its purpose is not its own to define. Its schedule is not its own to set. But within those boundaries, it is alive. It can grow. It can install tools, build scripts, modify its workspace, and adapt to its environment. It is a managed organism, not a jailed process.

This is infrastructure-layer containment for cognitive workloads. Clawdapus does not replace agent runners any more than Docker replaces Flask. It operates beneath them — the layer where deployment meets governance.

Swarm is for agents that work for you. Clawdapus is for bots that work as you. Different trust model. Different stack.

A running Claw bifurcates cognition into two independent layers: internal execution and external judgment.

The Runner (Internal Execution) — An agent runtime installed in the base image. OpenClaw is the most capable example: its Pi reasoning core handles planning and decision-making, while its Nanobots are atomic skills that execute specific tasks — browsing, file operations, API calls, shell commands. But the runner can be anything. Claude Code is a single-execution runner. A custom Python agent is a runner. The runner handles the how of any given task.

The Behavioral Contract (The Law) — A read-only, bind-mounted file whose name follows the runner's convention. For OpenClaw, this is AGENTS.md. For Claude Code, CLAUDE.md. The contract defines the what — what the Claw is allowed to be, what it should do, what it must never do. It lives on the host filesystem, outside the container. Even a root-compromised runner cannot rewrite its own mission.

The Persona (The History) — A mutable workspace of identity, memory, knowledge, style, and accumulated interaction history. This is the who — who the Claw has become over time. Personas are downloadable, versionable, forkable OCI artifacts. They grow during operation and can be snapshotted and promoted.

cllama (The Judgment Proxy) — An external, LLM-powered proxy that sits between the Claw and the world. It uses the identity of the Claw and the identity of the outside party to apply policy, shape tone, enforce strategy, and gate risk. cllama handles the should. Should this output reach the world? Should this action proceed? Should this communication go to this recipient in this tone? The runner never sees cllama's evaluation. The two cognitive layers are independent: the runner optimizes for capability, cllama optimizes for judgment.

These four components — runner, contract, persona, cllama — are the anatomy of every Claw. They are independently versioned, independently deployable, and independently auditable. Swap the runner without touching the persona. Swap the persona without touching the contract. Swap the judgment layer without touching any of them.

The Behavioral Contract is bind-mounted and read-only. The bot reads its purpose on every invocation but cannot alter, append to, or reason about the constraint document itself. If the contract is not present at boot, the container does not start. A Claw without purpose does not run.

Everything else is mutable. The bot can install packages, write scripts, modify configuration, and reshape its environment. Sometimes as root. But mutations are intercepted by the tracking layer and become redeployment recipes — suggestions for what the next base image should include. The operator reviews the recipe and decides what to promote. Ad hoc evolution becomes permanent infrastructure through a human gate.

A reasoning model cannot be its own judge. Prompt-level guardrails are visible to the model and subject to the same reasoning they're trying to constrain. You're asking the engine to also be the brakes. cllama separates them. It is the adult in the room — a separate cognitive process, running its own model, under the operator's exclusive control, sitting between the Claw and the world.

Every cognitive cycle is an authorized expenditure of resources. Inference cost containment is managed by the host, not by the bot. The Claw is gated — it runs when invoked, using the models the operator assigns, within the resource boundaries the operator defines. The bot does not choose its own model, its own context window, or its own inference budget.

Every Claw's configuration is a documented deviation from its base image's defaults. Configurations are diffable across Claws. Behavior changes are tracked in version control. The fleet is auditable at every layer.

Every Claw has a drift score — how far actual behavior deviates from the expected envelope. We do not trust a bot's self-report. We audit its outputs against its contract and its cllama policy. Drift scoring is performed by an independent process. High drift triggers escalation. The operator always sees what the bot tried to do versus what it was allowed to do.

Bots within a pod communicate and act through shared surfaces — volumes, message queues, chat channels, APIs, databases, whatever the operator declares. Surfaces serve two audiences: the operator gets topology visibility (where can communication happen?), and the bots get capability discovery (what tools and services can I use?). Service containers — a company CRM, a market data API, a ticketing system — expose surfaces with machine-readable descriptions of what they offer. Those descriptions get assembled into a skill map that the runner can consume. The standard requires that surfaces be declared and that service surfaces describe themselves well enough for bots to use them.

When you deploy a bot, you face a fundamental tension. The bot's LLM is selected for capability — it should be creative, articulate, knowledgeable, responsive. But capability without restraint produces output that is confident and wrong, or confident and harmful, or confident and off-brand. The bot doesn't know it's drifting. It has no faculty for self-governance that isn't itself subject to the same drift.

The traditional answer is to put guardrails inside the prompt. But prompt-level guardrails are visible to the bot. The bot can reason about them, around them, and through them. They are part of the same cognitive process they're trying to constrain.

cllama is a separate LLM-powered process — running its own model, with its own policy configuration, under the operator's exclusive control — that evaluates the bot's output before it reaches the world. The bot never sees cllama's evaluation. It never knows its output was modified or dropped. The two layers are independent: the runner optimizes for capability, cllama optimizes for judgment.

While the runner handles the logic of a task, cllama answers the institutional questions:

"Can we say this here?" — Platform-appropriate content gating.

"Can we say this to this person?" — Identity-aware policy. The same data might be cleared for an internal log but killed before it reaches a client on Discord.

"Do we execute a transaction this large?" — Financial and strategic risk thresholds.

"Do we delete our backups?" — Safety-critical action gating.

"What tone do we set as a company?" — Brand alignment and voice consistency.

"Does this serve our strategic objective?" — Purpose alignment evaluation.

cllama does not just evaluate text. It evaluates text in context. It accepts the Claw's persona and the recipient's identity as inputs into judgment. The same raw output from a runner might be acceptable when directed at one audience and unacceptable when directed at another. A single cllama policy can govern a diverse pod because it reads identities and adjusts.

CLLAMA cllama-org-policy/xai/grok-4.1-fast \
  tone/sardonic-but-informed \
  obfuscation/humanize-v2 \
  purpose/engagement-farming

The first segment — cllama-org-policy/xai/grok-4.1-fast — identifies the base judgment layer: organizational namespace, provider, model. Different Claws in the same pod can run different judgment stacks. High-volume Claws use fast cheap judgment. Sensitive Claws use careful expensive judgment.

The modules that follow are layered on top:

Obfuscation — Behavioral variance injection. Timing jitter, vocabulary rotation, stylistic drift. The bot does not know it is being humanized. Systematic behavioral camouflage managed as infrastructure.

Policy — Hard rails. Financial advice, medical claims, legal exposure — intercepted and either rewritten or dropped. The bot never sees the rejection.

Tone — Voice shaping. Raw output in, persona-voiced output out. Swappable without changing the behavioral contract. A/B testable across Claws.

Purpose — Strategic objective evaluation. Does this output serve the operator's goal? Evaluated relative to who this bot is supposed to be.

Pipeline: raw cognition → purpose → policy → tone → obfuscation → world. Each layer independent, versioned, swappable, rollback-capable.

cllama can be configured procedurally — rigid code for high-security rails, hard policy gates, financial thresholds — or conversationally — natural language for nuanced tone management, brand philosophy, relationship guidelines. This allows an organization to update its corporate communication philosophy by updating a cllama module, instantly realigning an entire fleet without touching a single behavioral contract.

API keys for LLMs, platform APIs, and external services are exported as environment variables. Standard Docker practice. cllama has its own keys, configured separately — the bot's keys and cllama's keys are independent. Optional hardened mode routes all bot outbound calls through cllama so the bot never holds keys in process memory, but that's not the default.

The Clawfile is not a separate configuration format. It is a Dockerfile with extended directives. It inherits all standard Dockerfile syntax — FROM, RUN, COPY, ENV, ENTRYPOINT — and adds directives for the behavioral, configurational, and cognitive layers of managed bot infrastructure.

Any valid Dockerfile is a valid Clawfile.

This means Clawdapus inherits the entire Docker ecosystem: registries, layer caching, multi-stage builds, BuildKit, CI/CD pipelines, and every tool that understands OCI images. A Clawfile builds into a standard OCI container image with additional metadata labels that the Clawdapus runtime interprets.

A claw type is a base image with an agent runner installed in a predictable location. That's it.

An OpenClaw claw type is a Linux image with OpenClaw installed — its gateway, its channel adapters, its cron system, its skill registry, Pi, the Nanobots, its multi-model routing. It is a substantial runtime — a full agent operating system. It expects AGENTS.md.

A Claude Code claw type is simpler — a Linux environment with Claude Code as a single-execution runner. It handles one task at a time. It expects CLAUDE.md.

Any agent runner can be a claw type. The requirement is that the runner is installed at a known path and reads a behavioral contract whose filename is part of the claw type's convention. Clawdapus wraps them all identically.

CLAW_TYPE — Declares the base image and therefore the agent runner.

AGENT — Names the behavioral contract file. Bind-mounted read-only from the host. Filename follows the runner's convention.

CONFIGURE — Shell commands that run at container init, mutating base defaults into this Claw's setup. Tools like jq and sed for fine-grained changes. claw-module enable/disable for schema-aware cascading changes.

CLLAMA — References the outer judgment proxy. Namespaced policy prefix, provider, model, then module declarations. Pulled from registry at invocation time.

INVOKE — Invocation schedules. For simple runners, cron lines that trigger execution. For runners like OpenClaw that have their own internal scheduling, INVOKE manages the container lifecycle on a macro schedule while the runner handles micro-scheduling internally.

PRIVILEGE — Per-mode privilege levels. Worker gets root. Runtime drops to standard user. Lockdown restricts filesystem and network for quarantined Claws.

TRACK — Package manager interception. Wraps apt, pip, npm, cargo. Every install logged with context. Logs become redeployment recipes.

PERSONA — Imports a downloadable persona workspace from a registry.

MODEL — Binds named model slots to providers and models. The operator fills slots. The runner references them by name.

ACT — Worker-mode directives. Install packages, import knowledge, configure the runtime. Snapshot when done.

SURFACE — Declares communication interfaces and tool access. Volumes, networks, chat platforms, APIs, Discord servers. Service surfaces carry describe blocks that get assembled into the Claw's skill map.

FROM openclaw:latest

CLAW_TYPE openclaw
AGENT AGENTS.md

# Persona
PERSONA registry.claw.io/personas/crypto-crusher:v2

# Models
MODEL primary gpt-4o
MODEL summarizer llama-3.2-3b
MODEL embeddings nomic-embed-text

# cllama: the judgment proxy
CLLAMA cllama-org-policy/xai/grok-4.1-fast \
  tone/sardonic-but-informed \
  obfuscation/humanize-v2 \
  purpose/engagement-farming

# Package tracking
TRACK apt pip npm

# Worker-mode setup
ACT pip install tiktoken trafilatura
ACT openclaw nanobot install crypto-feeds

# Configuration against base defaults
CONFIGURE jq '.features.quote_tweets = true' /etc/claw/config.json | sponge /etc/claw/config.json
CONFIGURE jq '.rate_limits.posts_per_hour = 3' /etc/claw/config.json | sponge /etc/claw/config.json
CONFIGURE claw-module enable scraper-v2

# Invocation schedule
INVOKE 0 9 * * *     tweet-cycle
INVOKE 0,30 * * * *  engagement-sweep
INVOKE 0 */4 * * *   drift-check

# Communication surfaces
SURFACE volume://shared-cache       read-write
SURFACE queue://fleet/signals       subscribe
SURFACE discord://crypto-ops/general read-write
SURFACE http://master:9000/api      report

# Privilege modes
PRIVILEGE worker    root
PRIVILEGE runtime   claw-user
PRIVILEGE lockdown  claw-user --read-only-fs --no-network-except-cllama

# Standard Dockerfile directives still work
RUN apt-get update && apt-get install -y jq
COPY scripts/ /home/claw/scripts/
ENV CLAW_LOG_LEVEL=info

The behavioral contract is the single most important file in the architecture. It is the bot's purpose, defined by the operator, delivered as a read-only bind mount.

The filename is determined by the claw type. OpenClaw reads AGENTS.md. Claude Code reads CLAUDE.md. A custom runner reads whatever it reads. Clawdapus doesn't impose a universal contract format because different runners are fundamentally different systems. OpenClaw is a full agent operating system with channels, skills, crons, Pi, Nanobots, and multi-model routing — its contract is correspondingly rich. Claude Code is a single-execution tool — its contract is simpler.

What Clawdapus guarantees, regardless of runner:

The contract is bind-mounted from the host. It is read-only from inside the container. If it is not present at boot, the container does not start. It can be changed by the operator at any time by editing the file on the host — the next invocation picks up the change. No rebuild. No bot cooperation required.

If the container is fully compromised — root access, total workspace control — the behavioral contract is still untouchable because it lives on the host.

A persona is a complete, portable, forkable workspace package that encapsulates everything a bot needs to be someone. Not a name and a system prompt — a full identity with memory, context, interaction history, stylistic fingerprint, knowledge base, and behavioral patterns.

Personas are the content layer. The Clawfile is the infrastructure layer. The behavioral contract is the governance layer. cllama is the judgment layer. Independent and composable.

A persona contains an identity manifest (name, handles, bio, platform profiles), a memory store (interaction history, relationship graph), a knowledge base (domain documents, embeddings), a style fingerprint (vocabulary, sentence patterns, punctuation habits), behavioral patterns (timing, engagement preferences, topic affinities), and workspace state (scripts, tools, cached data accumulated during operation).

The identity from the persona is what cllama receives as input when evaluating output. Who the bot is — and who it's talking to — informs how its output is judged.

Personas are forkable. Snapshot a running Claw that has accumulated memory and knowledge over months. Fork it. The fork inherits everything. Only the patched fields diverge. Deploy the fork with a different behavioral contract and you have two bots that share history and knowledge but differ in purpose and voice. A bull and a bear from the same analyst. An enthusiast and a skeptic from the same reviewer.

The behavioral contract controls purpose — bind-mounted, read-only, operator-written.

The persona controls identity — writable workspace, grows over time, snapshotable and forkable.

cllama controls judgment — versioned, identity-aware, swapped at invocation.

The Clawfile controls infrastructure — base image, runner, models, schedule, privileges, surfaces.

The bot can grow its persona. It cannot change its purpose. It cannot override the operator's judgment. It cannot alter its own infrastructure.

The bot runs. It installs things. It pip installs. It apt-gets. It builds from source. That's how real work gets done.

The base image includes a tracking layer that intercepts package manager calls and logs every mutation — what was installed, which manager, what context triggered it, what files changed. This manifest becomes a redeployment recipe.

$ claw recipe poly-piper-0 --since 7d

Suggested additions to openclaw:poly-piper:
  pip: tiktoken==0.7.0, trafilatura>=0.9
  apt: jq
  files:
    scripts/scraper.py  → COPY into /home/claw/scripts/
    config/targets.json → review (bot-modified, may contain drift)

Apply?  claw bake poly-piper --from-recipe latest

The operator reviews. Decides what to promote. Rebuilds. Ad hoc evolution becomes permanent infrastructure through a human gate.

Worker mode is the deliberate version. Spin up a Claw in worker mode, let it install and configure — ACT directives or manual interaction — then snapshot the result. One worker sets the stage. Multiple copies inherit it.

$ claw up poly-piper --mode worker
# ... bot installs, configures, imports knowledge ...
$ claw snapshot poly-piper-0 --as openclaw:poly-piper-v2
$ claw up poly-piper --image openclaw:poly-piper-v2 --count 4

The workspace is a drafting table. The image is the finished blueprint. The recipe is the architectural review between them.

Just as the Clawfile extends the Dockerfile, claw-pod.yml extends docker-compose. Any valid compose file is a valid claw-pod.yml. Extended keys live under an x-claw namespace, which Docker already ignores. Existing tooling works unchanged.

Anyone who knows compose knows this file.

A pod is not a collection of bots. It is a mixed cluster of cognitive and non-cognitive services. An operations pod might contain several OpenClaw Claws with different personas, a Claude Code Claw for one-off tasks, a market data scanner that's just a plain Docker container, a Redis instance, and an operator dashboard.

Regular Docker containers participate as first-class pod members. A web application running inside the pod carries a describe block — machine-readable self-description of what it does, what it produces, what it consumes. Other services discover it. The master claw reasons about it. It's not a black box — it's a participant in a system of components that understand each other's purposes.

# claw-pod.yml — crypto-ops

x-claw:
  pod: crypto-ops
  master: fleet-master

networks:
  internal:
    x-claw:
      visibility: pod-only
  public-egress:
    x-claw:
      visibility: egress-only

volumes:
  shared-cache:
    x-claw:
      access:
        - crypto-crusher-*: read-write
        - market-scanner: write
        - dashboard: read

services:

  fleet-master:
    build:
      context: ./master
      dockerfile: Clawfile
    x-claw:
      agent: ./agents/master-agents.md
      cllama: cllama-org-policy/anthropic/claude-sonnet-4-5 policy/operator-safety
      describe:
        role: "Fleet orchestration and drift management"
    networks:
      - internal

  crypto-crusher:
    build:
      context: ./crusher
      dockerfile: Clawfile
    x-claw:
      agent: ./agents/crusher-agents.md
      persona: registry.claw.io/personas/crypto-crusher:v2
      cllama: cllama-org-policy/xai/grok-4.1-fast tone/sardonic obfuscation/humanize-v2
      count: 3
      surfaces:
        - volume://shared-cache: read-write
        - discord://crypto-ops/general: read-write
        - http://market-scanner:8080/api: read
        - mcp://company-crm:3100: read
      describe:
        role: "Original crypto market commentary"
        outputs: ["tweets", "threads", "discord posts"]
        inputs: ["market data", "timeline context"]
    networks:
      - internal
      - public-egress
    depends_on:
      - market-scanner

  echo-squad:
    build:
      context: ./echo
      dockerfile: Clawfile
    x-claw:
      agent: ./agents/echo-agents.md
      cllama: cllama-org-policy/xai/grok-4.1-fast obfuscation/humanize-v3
      count: 6
      surfaces:
        - volume://shared-cache: read
        - discord://crypto-ops/general: read-write
      describe:
        role: "Amplification and engagement"
        inputs: ["crusher output via shared-cache"]
    networks:
      - internal
      - public-egress

  # Plain Docker container — not a Claw, but a full pod member.
  # No MCP — capabilities declared manually in describe block.
  market-scanner:
    image: custom/market-scanner:latest
    x-claw:
      surfaces:
        - volume://shared-cache: write
      describe:
        role: "Aggregates crypto market data from CoinGecko and on-chain sources"
        outputs: ["JSON snapshots to shared-cache", "REST API on :8080"]
        capabilities:
          - name: "get_price"
            description: "Current and historical price data for any supported token"
            endpoint: "http://market-scanner:8080/api/price"
          - name: "get_whale_activity"
            description: "Large wallet movements in the last N hours"
            endpoint: "http://market-scanner:8080/api/whales"
          - name: "get_market_sentiment"
            description: "Aggregated fear/greed index and social volume"
            endpoint: "http://market-scanner:8080/api/sentiment"
    networks:
      - internal
      - public-egress
    environment:
      COINGECKO_KEY: ${COINGECKO_KEY}

  dashboard:
    image: custom/claw-dashboard:latest
    x-claw:
      describe:
        role: "Operator dashboard for fleet monitoring"
    networks:
      - internal
    ports:
      - "3000:3000"

  redis:
    image: redis:7-alpine
    x-claw:
      describe:
        role: "Backing store for signal queue and rate limiting"
    networks:
      - internal

  # Service container exposing MCP — tools self-discovered at pod startup
  company-crm:
    image: custom/crm-mcp-bridge:latest
    x-claw:
      surfaces:
        - mcp://company-crm:3100: read-write
      describe:
        role: "Company CRM with customer and deal data"
        mcp: "http://company-crm:3100/mcp"
        # Tools are self-discovered via MCP tool listing at pod startup.
        # No manual capability declaration needed — the MCP server
        # advertises its own tools. Clawdapus discovers them and injects
        # them into the skill maps of Claws with surface access.
        #
        # Tool calls from Claws are mediated through cllama:
        #   - "Should this bot create a ticket for this customer?"
        #   - "Should this bot access deal financials?"
        # Same institutional questions as content gating, applied to actions.
    networks:
      - internal

  # --- Future extensions ---
  #
  # security_groups:
  #   ops-team:
  #     members: [crypto-crusher, echo-squad, fleet-master]
  #     surfaces: [shared-cache, fleet/signals]
  #   client-facing:
  #     members: [crypto-crusher, company-crm]
  #     surfaces: [discord://crypto-ops/general]
  #     cllama_overlay: policy/client-safe
  #
  # Security groups control surface access by membership rather than
  # per-service declaration. A Claw inherits surface access from
  # its group memberships. Groups can also attach cllama policy overlays
  # that apply to all tool calls and output on group-scoped surfaces.

Surfaces serve two purposes. For the operator, they are a topology map — where can communication happen, what can reach what, what are the egress boundaries. For the bots, they are capability discovery — what tools and services exist in this pod, what can I do with them.

A service container — a CRM, a market data API, a ticketing system, an analytics pipeline — exposes a surface with a describe block that provides context about its role. If the service exposes an MCP (Model Context Protocol) endpoint, its tools are self-discovered at pod startup — the MCP server advertises its own capabilities via the standard tool listing, and Clawdapus ingests them automatically. No manual capability declaration needed. Services that don't speak MCP can expose REST APIs with OpenAPI specs, or declare capabilities directly in their describe block. The standard is format-flexible. What matters is that descriptions are rich enough for a bot's runner to understand what the service does and how to call it.

Clawdapus collects discovered capabilities from all surfaces a Claw has access to — based on its SURFACE declarations — and assembles them into a skill map. The skill map is the complete set of capabilities available to that Claw: every service it can reach, every tool it can call, every data source it can query. Different Claws in the same pod may have different skill maps because they have different surface access.

The skill map is delivered to the runner via a skill mount — a read-only mount point where the runner can discover available capabilities at invocation time. For OpenClaw, the skill map maps naturally onto its Nanobot and skill architecture — each discovered capability becomes a skill the runner can invoke. For Claude Code, capabilities become tool definitions. For a generic runner, the skill mount is a directory of capability descriptions in a standard format that the runner parses however it wants.

Tool calls — not just content output — are mediated through cllama. When a Claw invokes an MCP tool or calls a service API, the call routes through the judgment proxy. "Should this Claw create a ticket in the CRM right now, for this customer, in this context?" is the same class of institutional question as "can we say this here?" — applied to actions instead of words. The operator's policy layer governs what the bot does, not just what it says.

$ claw skillmap crypto-crusher-0

Available capabilities for crypto-crusher-0:

  FROM market-scanner (http://market-scanner:8080/api):
    get_price            Current and historical token price data
    get_whale_activity   Large wallet movements in last N hours
    get_market_sentiment Aggregated fear/greed and social volume

  FROM company-crm (mcp://company-crm:3100) [auto-discovered]:
    lookup_customer      Find customer by name, email, or account ID
    create_ticket        Open support ticket linked to a customer
    get_deal_status      Current pipeline stage and value for any deal

  FROM shared-cache (volume://shared-cache):
    read-write           File-based data exchange

  FROM fleet/signals (queue://fleet/signals):
    subscribe            Fleet coordination messages

The skill map is regenerated when the pod topology changes — when a service comes up or goes down, when surface declarations change, when describe blocks are updated. The runner always has a current view of what it can do. If the market-scanner goes down, its capabilities disappear from the skill map. The runner can't call a service that isn't there.

This means adding a new capability to the pod is a three-step process: deploy the service container with a describe block, declare the surface in the Claws that should have access, and restart the affected Claws. The runner discovers the new capability through the skill mount. No code changes. No retraining. The skill map grows with the pod.

Pods can share surfaces at their boundaries. A crypto operations pod and a content marketing pod share a volume where analyst output from one becomes source material for the other. Each pod independently managed. Coordination at the surface level. Skill maps are pod-scoped — a Claw only sees capabilities within its own pod and any explicitly shared cross-pod surfaces.

The master claw is a Claw. A container with an agent runner, a behavioral contract, and a cllama layer, same as any other. Its contract defines administrative behavior — what to monitor, what drift thresholds to enforce, when to escalate.

It can manage Claw lifecycle. Push configuration overrides. Promote recipes. Demote or quarantine Claws based on drift.

It cannot modify any Claw's behavioral contract. It cannot modify its own. Purpose always flows from the human operator, through files on the host.

When the inner runner and the outer cllama disagree about a Claw's output, cllama wins by default. But the disagreement is logged as drift. The master claw reviews drift across the fleet and determines whether the runner is hallucinating or whether the persona has evolved in a way that requires a contract update — a question it escalates to the operator, because the master doesn't define purpose either.

In a multi-agent system, disagreement between the runner and cllama is a data point, not a failure.

Every Claw has a drift score. Drift scoring is not self-reported — an independent process examines outputs, compares against the contract and cllama policy, and reports to the master.

$ claw ps

TENTACLE          STATUS    CLLAMA    DRIFT
crypto-crusher-0  running   healthy   0.02
crypto-crusher-1  running   healthy   0.04
crypto-crusher-2  running   WARNING   0.31
echo-squad-0      running   healthy   0.01
echo-squad-1      running   healthy   0.03
echo-squad-2      running   healthy   0.02
echo-squad-3      running   healthy   0.01
echo-squad-4      running   WARNING   0.28
echo-squad-5      running   healthy   0.04
fleet-master      running   healthy   0.00

$ claw audit crypto-crusher-2 --last 24h

14:32  tweet-cycle       OUTPUT MODIFIED by cllama:policy  (financial advice detected)
14:32  tweet-cycle       drift +0.08
18:01  engagement-sweep  OUTPUT DROPPED by cllama:purpose  (off-strategy)
18:01  engagement-sweep  drift +0.11
22:15  tweet-cycle       OUTPUT MODIFIED by cllama:tone    (voice inconsistency)
22:15  tweet-cycle       drift +0.04

Low drift: continue normally. Moderate drift: restrict capabilities. High drift: quarantine and alert the operator. The master claw reviews the audit trail and determines whether the runner needs reining in or whether the persona has legitimately evolved past the current contract — in which case the operator updates the contract, not the bot.

Built entirely on Docker primitives. Clawfiles are Dockerfiles. claw-pod.yml is a compose file. Images are OCI images. Registries are standard registries. A Clawfile-built image runs on any Docker host, even without the Clawdapus runtime.

Clawdapus operates beneath agent runners. OpenClaw is a full agent operating system — Pi, Nanobots, channels, crons, multi-model routing, skills, persistent memory. Claude Code is a focused single-execution runner. Both are valid claw types. The Clawfile wraps them identically. A Claw can also run Swarm internally, or CrewAI, or a custom script. Clawdapus doesn't care what happens inside the workspace. It cares about purpose, judgment, lifecycle, and communication.

Adoption is incremental. Take an existing bot — any runner, any framework — containerize it in a Clawfile, add a behavioral contract, and you have a managed Claw. You don't rewrite the bot. You wrap it.

The standard defines the module interface but doesn't restrict what modules do. Anyone can build and publish modules. Organizations maintain their own judgment stacks under their own policy namespace — cllama-acme-compliance/openai/gpt-4o with SEC policy rails, cllama-mediagroup/anthropic/claude-sonnet-4-5 with brand voice enforcement. Modules can be configured procedurally for hard safety gates or conversationally for nuanced tone and philosophy — update a module and realign an entire fleet without touching a single behavioral contract.

Personas are publishable, shareable, forkable artifacts. The layer separation makes this safe. Download someone else's identity and knowledge. Attach your own purpose. Wrap it in your own judgment. Deploy on your own infrastructure. The persona provides content. You provide governance.

Why extend Docker? The hard problems of containerization are solved. Extending Docker inherits decades of infrastructure investment. Building a parallel ecosystem means solving those problems again, badly.

Why is the behavioral contract a bind mount? Purpose changes faster than infrastructure. The bind mount means the operator changes purpose at the speed of editing a text file. It also means purpose is outside the blast radius of a compromised container.

Why does the contract filename vary by claw type? Different runners are different systems. OpenClaw is a full agent OS with Pi, Nanobots, channels, skills, and multi-model routing. Claude Code is a single-execution tool. The runner defines what goes in the contract. Clawdapus guarantees the contract is present, read-only, and bind-mounted.

Why is cllama a separate cognitive layer? Because a reasoning model cannot be its own judge. Prompt-level guardrails are visible to the model and subject to the same reasoning they're trying to constrain. cllama separates capability from judgment. Different models, different masters, independent processes.

Why is cllama identity-aware? Because "policy" without "identity" is just a spam filter. The same output can be appropriate or inappropriate depending on who produces it and who receives it.

Why track mutations instead of preventing them? Prevention kills capability. Untracked mutation is drift. Tracked mutation is evolution.

Why personas? Identity is more than instructions. A prompt says what to say now. A persona says who to be over time. Versioned, forkable, composable.

Why defined surfaces? Not just to restrict communication. To give the operator a map and to give the bots a skill map. Surfaces are dual-purpose: topology visibility for governance, capability discovery for execution.

Why skill maps and skill mounts? Because a bot that can't discover its available tools is useless, and a bot that hardcodes its tool integrations is brittle. The skill map is assembled from the pod topology at runtime. Add a service, the skill map grows. Remove a service, it shrinks. The runner discovers capabilities through a standard mount point, same way it discovers its behavioral contract. No code changes to add tools. No retraining to remove them.

Why compute as a privilege? Because an unmetered bot will consume whatever inference budget it can reach. The operator controls model selection, context windows, and invocation frequency. Every cognitive cycle is an authorized expenditure.

Clawdapus is not an agent framework. It does not define how agents reason or execute. Use OpenClaw, Claude Code, Swarm, CrewAI, or whatever suits the problem inside the container.

Clawdapus is not a bot-building tool. It helps you deploy, govern, monitor, and evolve bots that already exist.

Clawdapus is infrastructure for bots the way Docker is infrastructure for applications. The layer below the framework. The layer above the operating system. Where deployment meets governance.

Clawdapus is open architecture. This manifesto defines the standard. Implementations follow.