I Rebuilt My Crew on a New Runtime. Only the Ledger Survived.

The views expressed here are my own and do not represent those of any current or former employer.

I had built a crew. Nine specialist agents, a six-stage flow with a critic gate between every wave, a style layer to keep their output in one voice. It ran on Claude Code, and it was good. Then I tried to run the same crew somewhere else, and most of it did not come with me.

The reason for the move was the local-model experiment: I wanted the high-volume work on my own GPU, the routing call that volume goes local and stakes stay in the cloud, which meant running the crew on OpenClaw against local models instead of Claude Code. So I ported it. I expected to carry all of it across. What actually survived the move told me what I had really built, and it was not the part I was proud of.

The orchestration did not survive the port

The crew, the flow, the wave dispatch, the critic gates: all of it had to be rebuilt for the new runtime. Same ideas, reimplemented against a different harness; the result is a plugin suite I called fakoli-claw. The skills were re-authored, the agents re-declared, the dispatch rewired to a different engine. None of it ported. It could not, because orchestration is shaped like the harness it runs on.

I had already watched the platforms eat this layer once, in the post that started this whole exercise: I built orchestration by hand, and Anthropic and OpenAI shipped their own versions for free within months. The port proved the same thing from the other direction. The coordination layer is not just commoditized from above by the platforms. It is non-portable from the side, between runtimes. Either way you do not get to keep it. Orchestration is sand whether the tide comes in from the platform or from the next runtime you move to.

The ledger ported intact

One thing moved without a rewrite. The durable record: every task, every claim and its lease, every piece of evidence. The store that knows what is true about the project after the chat window closes, after the model is swapped, after the orchestrator changes names. I had pulled it out of my plugin monorepo, where it was called fakoli-state, and given it its own life as Anvil.

On the new runtime it dropped in as-is: the same record, the same twenty-two state tools, the same contract, vendored straight into OpenClaw. Nothing about it was Claude-Code-shaped, and nothing about it had to become OpenClaw-shaped. It did not know or care which harness sat on top of it.

That is the moment the name stopped being a metaphor. Anvil is the fixed surface the work is done on. The hammers, the orchestrators and the runtimes, change constantly. The anvil does not. I had believed that for a while. The port is the first time I watched it actually happen: I swapped the entire runtime out from under the work, and the ledger never moved.

That is also the moment it stopped being a plugin and became a different kind of thing. Not a harness for one tool, but a neutral record meant to span all of them, every surface I run agents on, Claude Code and OpenClaw and Codex and the local box, with one account-free contract underneath. A generic ledger across every harness is not a feature of any one of them. It is a product none of them will build, because building it would help their competitors plug in.

A cross-runtime ledger is only worth trusting if its evidence is real

Here is the catch I had to face, and it is where most of the actual work now lives. A record that spans runtimes is worthless if what it stores is the model’s word. An agent that says “done” is making a claim. A claim is not evidence. The docs for the crew state the rule plainly: a claim is “it works,” evidence is an exit code, and the distinction is the whole gate.

So the ledger stores evidence, not assertions, and the harness around it is built to produce evidence rather than claims. The coding eval does not ask a model to grade the work; it imports the file the agent actually wrote and runs a real assert against it. The critic re-runs the verify command rather than reading the diff and nodding. The final gate refuses to pass without the command’s output. The loop is bounded so it cannot grind forever: the critic gets a few fix cycles, the builder fewer, then it escalates to me.

I have one anecdote that is worth more than the harness diagram. On one run, the evidence gate returned FAIL on work the text-only reviewer had already passed; the file was momentarily inconsistent on disk, and only the gate that re-ran the command caught it. One instance, not a statistic. But it is exactly the escape the whole design exists to catch, caught in the wild.

What is table stakes, and what is still the bet

I want to be honest about which part of this is defensible. Durable state is not the moat anymore. Temporal has shipped durable execution, leases, and recovery for years. Beads proved a durable canonical work record should exist. The platforms now ship their own durable control planes. A record that outlives the chat is table stakes, won by everyone.

The wedge that is left is neutrality plus verification, and the port only proves part of it. It proves the same-author cross-surface case: I ran my own crew on two different runtimes and the ledger spanned both. What it does not yet prove is the part that matters most, a runtime I did not build reading and writing the same record, and a proof artifact that means something once it leaves a machine I control. The evidence gate that refuses a nonzero exit code ships today. The signed, portable envelope that lets someone verify that proof off my box, without trusting the box, is still in build. That is the bet, and I am not going to dress it up as finished. The full multi-agent run is checked qualitatively, not scored; the eval numbers I have are a handful of small tasks on a runner whose results I do not even commit. The machinery is real. The proof that it travels is not, yet.

Build the thing that survives the move

The most useful experiment I ran this year was an accident. I set out to move my crew to cheaper hardware, and instead I ran a controlled test of which layer is worth a person’s time. The answer was the one I had almost ignored. Not the orchestration I was proud of, which I rebuilt from scratch on the new runtime. Not even the durable state by itself, which everyone now ships. The neutral ledger underneath all of it, the one record that did not flinch when I swapped the entire runtime.

Build the thing that survives the move. The harness is where the energy goes and where the churn lives, and you will rebuild it more than once whether you want to or not. The ledger is the part you actually own. I found out which was which by moving, and I would not have known otherwise. Build the anvil. Let the hammers, and the runtimes, change.