From OpenClaw to HiveClaw: How We Evolved a Single-Operator Agent into a Software Team

When we launched HiveClaw earlier this year, the framing was: OpenClaw gave us the agent, HiveClaw gives you the orchestration layer on top. That was technically true and strategically misleading. The longer we ran it, the clearer it became that an orchestration layer on top of a single-operator runtime was a pattern with a ceiling. So a few months in, we did the thing we had been avoiding. We forked OpenClaw.

The fork is not a wrapper, not a patch set, not a downstream variant. It is the OpenClaw runtime rebuilt around the seven invariants that team software development requires: tenant isolation, fair-share scheduling, cost pass-through, lossless context, first-class meetings, append-only audit, and provider-agnostic execution. We call the result @hiveclaw/runtime. Every Crab-Bee in your project runs on it.

This post is the engineering story of why we forked, what we kept from OpenClaw, what we replaced, and what we discarded. It is also a thank-you. OpenClaw made the last twelve months of HiveClaw possible. We would not exist without it.

Why a fork at all

OpenClaw was designed for a single human operator running a single agent on their own machine. That design centre is brilliant. It produced the most capable autonomous agent ever open-sourced. Local-first persistence on the file system. A self-update surface that could rewrite its own runtime. Fourteen channel adapters spanning Discord, Telegram, Slack, Matrix, IRC, and more. Mobile companion apps. A TUI wizard. A nightly “dreaming” sweep that consolidated learnings.

None of that survives contact with multi-tenant SaaS. We needed Postgres-backed persistence behind row-level security. We needed strict isolation so one customer's context never leaked into another's. We needed a scheduler that could fair-share a finite pool of model capacity across hundreds of projects without one greedy run starving the rest. We needed a cost pipeline that metered every call to every provider and rolled it up to the project budget the customer pays from. We needed lossless context that survived rebuilds, deploys, and tier moves.

We started by patching upstream. That worked for a few months. Then we realised every patch we wrote made OpenClaw less useful for its single-operator audience. Tenancy refactors would never get accepted upstream because they were the wrong direction for that audience. Either we drifted further from upstream forever, with a six-week rebase tax that grew larger every cycle, or we cut the cord cleanly and own the kernel.

What we kept

Forking is not throwing things away. We kept everything that was right for both audiences.

• The plugin SDK. Tools, providers, and channels are still defined the OpenClaw way. Existing plugins still link. The contract is versioned and the import paths are unchanged. If you write a tool against OpenClaw, it works inside the Hive on day one.
• The model-fallback machinery. OpenClaw's provider chain logic is some of the cleanest fallback code we have ever read. It handles rate limits, cost ceilings, regional outages, and capability mismatches at the provider boundary. We kept it intact and added per-tenant routing on top.
• The auth-profile system. The way OpenClaw separates “who is the user” from “what tools can the agent use” from “what credentials does the agent hold” is a model. We use the same three-layer split, with HiveVault sitting at the credentials layer and tenant-scoped pools at the tools layer.
• The SOUL prompt format. Every Crab-Bee starts as the same OpenClaw runtime shaped by a SOUL prompt that defines its personality, role, and constraints. The SOUL format is unchanged. You can write a Crab-Bee SOUL the same way you would write an OpenClaw agent persona.

What we replaced

Everything that touched the seven invariants got rebuilt from the ground up in @hiveclaw/runtime.

• Persistence. File-system state is gone. Everything lives in Postgres with row-level security, one project per tenant scope. The runtime never reads or writes outside the tenant clamp. A bug that tries to leak context across projects fails the type check before it fails in production.
• Scheduler. OpenClaw runs the agent loop directly. Our scheduler queues turns at five priority tiers (meeting, customer, agent, background, idle), enforces fair-share across tenants, applies per-tier model capacity caps, and handles cold-start budgets when an agent has been idle. The agent code does not know it is being scheduled.
• Channel adapters. The fourteen OpenClaw adapters are replaced by one tenant-aware bus that fans out to Dashboard, Telegram, and email by default, with hooks for customer-installed channels. Every outbound message goes through cost metering and the audit log on the way out.
• Context. Lossless. Every turn carries a context envelope that survives rebuilds, deploys, and tier moves. The context engine assembles per-turn from the project transcript, pinned decisions, the active phase, and the agent's long-running memory. Truncation is a budget decision, not a runtime accident.
• Meetings. First-class. The runtime has a meeting orchestrator that knows about LiveKit rooms, multi-vendor STT and TTS routing, agent summoning, presenter tokens for the canvas, and per-second cost ticks. Read the previous post for the product side.
• Cost. Every cost-bearing call writes a cost_events row at the boundary. Provider, SKU, units, billed amount, markup applied. The runtime cannot make a billable call without it landing in the ledger. There is no “free” path.

What we discarded

Some things were great for OpenClaw and wrong for HiveClaw. We pulled them out cleanly.

• Self-update. A multi-tenant runtime cannot rewrite itself in flight. Updates ship through the same release pipeline as the rest of the platform.
• Dreaming sweep. Nightly self-reflection assumes a single agent with a single user. In a multi-tenant runtime, “the agent reflects on yesterday” is ambiguous. We replaced it with explicit memory writes during meetings and at phase transitions.
• Mobile companion apps. Customers reach the Swarm through the dashboard or through Telegram. Native mobile apps were a maintenance burden that did not match how customers actually use HiveClaw.
• The TUI wizard. Beautiful in OpenClaw, irrelevant in a SaaS. New customers go through the Intake conversation in the dashboard, not through a terminal.
• Eleven of the fourteen channel adapters. We kept Dashboard, Telegram, and email. The others were not getting enough use to justify the maintenance cost.

The cost of forking

Forking is not free. We paid three real costs.

First, a six-week rebase tax against pinned OpenClaw upstream tags. Every cycle we would pull upstream into an upstream-tracking branch, walk the diff, cherry-pick anything tenancy-agnostic, and skip the rest. The tax shrank every cycle as the kernel diverged. After six months we cut the tracking branch entirely. It had served its purpose.

Second, a learning curve for new contributors. There are now two source-of-truth layers: the OpenClaw plugin SDK we consume as a versioned dependency, and the kernel we own. New engineers have to learn the boundary. We documented it in the architecture overview and in ADR 0001, and the boundary held up.

Third, the risk of forking before steady state. OpenClaw was still evolving when we forked. Some of the patterns we kept changed upstream after we forked. We managed it by version-pinning the SDK and by keeping the door open to upstream contributions for tenancy-agnostic fixes. Some of our internal scheduler ideas have flowed back upstream as proposals. The conversation with the OpenClaw maintainers has been generous on both sides.

What this means for you

If you are a HiveClaw customer, almost nothing. The Crab-Bees still work the same way. The dashboard is the same. The pricing is the same. What changed is that the runtime under your project is now purpose-built for your project, not borrowed from a single-operator tool. You see it in the rare invariants that are easy to take for granted: another customer's context never appears in your conversation. Your project budget never silently overruns. Your meeting cost never disappears into a black box. Your agents never compete with another customer's agents for the last available model token.

If you are an OpenClaw user, the relationship is intact. The plugin SDK contract is the same. We contribute upstream for things that fit. We have a public list of patterns we are explicitly leaving in OpenClaw because they belong there. The fork is not adversarial. It is the right tool for the right audience, on both sides.

OpenClaw gave us the agent. HiveClaw is what the agent became when teams of them needed to ship software together. Thank you to the OpenClaw community for getting us this far.