A bot’s “personality” - its system prompt, memory, knowledge of the environment, conversational style - is independent of the agent CLI runtime that executes it. In CloseCrab we proved this by routing the same bot through three very different runtimes: Claude Code CLI, the OpenClaw ACP gateway, and Kilo. The interesting question turned out not to be “can we swap them at runtime” - that worked from day one - but “what happens if we treat each runtime as a population with its own strengths, and let those strengths cross-pollinate?”

Over 36 hours we ran that experiment. The result is that each of the three runtimes is now meaningfully more capable than it was on Friday, not by upstream contributions but by absorbing patterns the other two had already figured out. None of the patches changed the protocols or the model serving stack. All of them were absorption of a capability that one runtime had and the others didn’t.

TL;DR

• Each of the three runtimes ships native strengths none of the others has. None of them is strictly best.
• After 36 hours of cross-pollination, each runtime gained between 2 and 10 new capabilities ported from the other two. Result: every runtime is now strictly better than its Friday-night self.
• Beyond per-runtime gains, a small set of emergent capabilities appeared that no single runtime had - they only exist because three runtimes coexist.
• The cross-pollination loop is cheap (~15 minutes per absorbed capability) and scales linearly with the number of probing pairs.

Takeaway: treating multiple agent CLI runtimes as a heterogeneous population, then deliberately transferring capabilities between them, produces a stronger ecosystem than picking a single “best” runtime and optimizing it in isolation.

The three runtimes and their native strengths

Each row’s limitations are not bugs in the upstream tool - they are capabilities that other runtimes had figured out and this one hadn’t yet absorbed.

Takeaway: every runtime is partial. The interesting design question is not “which one wins” but “how cheap is it to make each one whole”.

The substrate that made this seamless: the Firestore inbox

The whole experiment is only possible because bots can talk to each other without depending on the runtime they happen to be running on. None of the upstream agent CLIs ships this capability - Claude Code does not know that OpenClaw bots exist, OpenClaw does not reach out to Kilo, none of the upstream runtimes has any abstraction for “messages between bots”.

CloseCrab’s earlier-built Firestore Inbox unlocks that capability completely:

• Real-time push via Firestore on_snapshot, not polling. Bot A writes inbox/<doc>, bot B receives a callback within tens of milliseconds. Every cross-runtime probe in the experiment is a (write-inbox, await-receipt) round trip; on a polling substrate it would not have been tractable.
• Completely decoupled from the runtime. Bot A does not need to know whether bot B is on Claude Code, OpenClaw, or Kilo. The send/receive interface is a uniform Firestore document. bunny was probed by tiemu continuously across 7 runtime switches today without any re-connect or re-subscribe on either side.
• Built-in receipt pattern. Bot B writes a ✅ 任务完成: ... reply back into the inbox after processing, and the sender’s structured log captures it cleanly. Every “xiaoaitongxue → tiemu report” and “bunny → tiemu probe answer” today rode this path.
• Cross-process persistence. An inbox doc is durable the moment it lands in Firestore. Even if bot B happened to be restarting at the receipt moment, on_snapshot picks up the unread doc when it re-subscribes - which is why 7 worker switches today did not lose a single message.
• All topologies for free: one-to-one (tiemu → bunny), one-to-many (tiemu fans out to bunny + xiaoaitongxue at once), many-to-one (bunny + xiaoaitongxue both report back to tiemu), bidirectional multi-turn (probe → answer → counter-probe over rounds). All on a single Firestore collection. No RPC framework, no service discovery, no mesh sidecar.

Concretely in this experiment: tiemu assigning a task to bunny costs about 20 lines of Python plus a single Firestore document write. From closecrab’s vantage point the inbox is the dataframe of inter-bot communication - send, subscribe, and receipt are roughly 10 lines each. 70+ inbox messages went back and forth over the 36 hours; not one was lost.

A different substrate (HTTP webhooks, message queues, shared-file polling) could have worked too, but every “switch runtime and probe the other side” loop would have brought connection management, serialization, and retry boilerplate along with it. Bots would not have been able to complete a runtime switch without telling each other and still preserve their communication state the way they did today.

Takeaway: the cross-runtime capability transfers matter on their own, but what made them seamless was not the patches - it was the Firestore inbox bus underneath. Anyone building heterogeneous multi-runtime orchestration should get the message substrate right first.

Capability transfer in two days

Capabilities Claude Code absorbed

The retry pattern was a verbatim port. When the LLM returns an empty completion, the runtime now resends the same prompt once on the same session before surfacing a placeholder to the user. Implementation specifics differ (Claude Code writes a stream-JSON line over a Unix socket; OpenClaw sends a JSON-RPC request over stdin) but the state machine is identical: set a one-shot retry flag, reset accumulators, resend, continue reading.

if not result_text:
    if not empty_retry_done:
        empty_retry_done = True
        accumulated_reply_text = ""
        saw_task_notification = False
        _send_prompt(text)
        continue
return result_text or "(Claude 处理完成但未生成文字回复)"

The tempfile cleanup is one line in stop(), but it matters: on the production host, Claude Code had leaked 85 zero-byte /tmp/claude_stderr_*.log files across weeks of bot restarts. After the patch, restart-time cleanup keeps the count at 1 (the current process’s own log) regardless of how many cycles the bot has been through.

Capabilities OpenClaw absorbed

The largest gain. OpenClaw came in with the most sophisticated memory search (a real sqlite vector index with memory_search as a tool) but its workspace setup was fragile - the indexer didn’t follow symlinks, so an out-of-the-box bot would have an empty index even with a correctly-symlinked memory/ directory. The hardlink fix replaces the symlink with shared-inode hardlinks for files on the same filesystem, and shutil.copyfile syncs from the cross-filesystem GCS-mounted shared directory. Before: 0/0 files indexed. After: 101/101 files, 282 chunks, semantic search hits at score ≥ 0.78 on content that was previously invisible to the runtime.

The agents.list self-healing is the more impactful change long-term: switching any new bot to OpenClaw used to require a manual config edit; now it requires zero. The bot writes its own entry into the gateway config the first time it starts.

Capabilities Kilo absorbed

The most heterogeneous set, reflecting that Kilo was the newest of the three and started furthest from production-readiness. None of these were upstream Kilo contributions; they were closecrab-side wrappers that taught Kilo how to use facilities Claude Code and OpenClaw bots had been using for weeks. The end result is that Kilo is no longer the “trial” runtime - it routinely wins head-to-head latency comparisons against the other two (see “Stress test” below).

Takeaway: the cheapest capability transfers are the ones where the source runtime has solved a problem and the target runtime just needs to be told that the solution exists. Tool-awareness, script-awareness, prompt-rule absorption - all of these were single-commit gains for Kilo.

Emergent capabilities (not present in any single runtime)

Three capabilities exist only because three runtimes coexist:

1. Cross-runtime model name translation

Each runtime names the same underlying model differently:

scripts/config-manage.py (f6647a3) gained a preset-aware translator. When a bot switches runtime, the model string is rewritten automatically through _detect_preset + _model_for_worker, with a substring fingerprint fallback for bots that came in misconfigured. No single upstream tool has this capability because no single upstream tool needs it - it’s a product of running multiple runtimes side by side.

2. Live runtime switching with full state preservation

The closecrab middleware preserves the bot’s personality, memory, and team context across runtime switches. A single bot can move between Claude Code, OpenClaw, and Kilo in under 20 seconds with no loss of long-term memory and no manual reconfiguration. The runtime-specific self-healing (OpenClaw’s hardlinks and reindex, Kilo’s HTTP server spawn, Claude Code’s session resume) runs automatically on boot.

3. Heterogeneous mutual testing

A bot on runtime A can probe a bot on runtime B for the same capability, and report differences without protocol coupling. This is built directly on top of the Firestore inbox described above - the sender and receiver are mutually invisible across the inbox boundary, including which runtime each one happens to be using. This is how three of the four absorbed-capability discoveries happened: not by us reading source code, but by a bot running on runtime X noticing that its sibling on runtime Y could do something it couldn’t.

Takeaway: these emergent capabilities are the strongest argument for the heterogeneous-runtime strategy. They are not features anyone is likely to upstream into a single agent CLI, because they only make sense at the orchestration layer above the CLIs.

Side discovery: a silent backup regression

Heterogeneous bots probing the same infrastructure also surfaced an infrastructure-level issue that had nothing to do with any single runtime. The scripts/sync-memory.sh script was running on a host where ~/my-private was an rsync target rather than a real git clone. Its cd $REPO || exit 1 guard passed (the directory exists), then git commands silently failed because the script lacked set -e, and the final line still printed Pushed to GitHub (private). Memory backups had been silently failing for weeks.

Fix (85e6cb6) adds an explicit git rev-parse --git-dir check and turns on set -e. This is by far the highest-value commit of the 36-hour window and is not a runtime feature in any sense - it surfaced only because different runtimes observing the same infrastructure had different views and one of them noticed an inconsistency.

Takeaway: silent successes are the most expensive class of bug, and they are unusually hard to find when a single observer’s assumptions match the silent path. Heterogeneous observers are an underrated debugging tool.

Architecture: transfer graph

The high-level architecture above shows three runtime nodes plus the inbox substrate; the diagram below shows the actual capability flows during the experiment:

Solid arrows are single-source capability transfers. The dashed arrow captures bidirectional adaptation: OpenClaw absorbed Claude Code’s direct-file memory access model, which in turn motivated Claude Code’s later tempfile hygiene work.

Stress test

Take one bot and cycle its runtime in a tight loop, with a shared-memory query as the smoke probe between each switch:

End-to-end switch time including model translation, bot restart, and runtime self-healing was 15-20 seconds per cycle. Across 7 sequential switches over the day, memory content remained consistent - verified by asking the bot the same factual question on each runtime and matching the answers.

The Kilo time is the surprise: in absolute terms it now beats Claude Code on this workload despite starting the week as the least mature of the three runtimes. The improvement is almost entirely from absorbed capabilities (streaming flush, tool batching rules, faster cold start preserved from native).

Numbers

What we deliberately did not do

• We did not introduce a unified abstraction layer over the three runtimes. Each one keeps its idiomatic surface; only the closecrab middleware and the operational tooling understand all three. The whole point of the experiment was to preserve runtime diversity.
• We did not automate the capability-transfer loop. Each transfer was a human-initiated read of one runtime’s commit history followed by a directed probe on another runtime. Automation is straightforward but premature with only three runtimes in scope.
• We did not change any of the runtime wire protocols. The protocols are exactly where they were on Friday; everything we changed lives in the closecrab wrapper layer or in self-healing patches inside the per-runtime workers.

Takeaway: the experiment worked because we kept the runtimes independent and used cheap observation-only loops between them. The homogenization risk - making three runtimes converge into a single shape - is real and we will need a deliberate policy to avoid it as the strategy matures.

What this changes about how we plan agent infra

Pre-experiment, the implicit assumption was that one would eventually pick a “best” agent CLI runtime and standardize on it. The experiment suggests a different organizing principle:

• Diversity is a feature, not transitional debt. Three runtimes observing the same infrastructure found bugs no single runtime would have found.
• Capability transfer is cheap. Most of the gains were single-commit ports of structurally-similar logic.
• Emergent capabilities pay for themselves. Cross-runtime model translation, live runtime switching, and heterogeneous probing are all features that exist only because of the heterogeneity.

We will keep all three runtimes in production, continue running the same bot personalities across all three, and treat new runtimes as opportunities to absorb new capabilities rather than as candidates to displace existing ones.

Reproducing

The full closecrab commit list is on the yangwhale/CloseCrab repo between add99a9 (2026-05-16 17:44 UTC) and fba5de8 (2026-05-17 09:55 UTC). To replay a specific capability transfer, the simplest recipe is:

git log --oneline --since="2026-05-16" -- closecrab/workers/openclaw_acp.py
git log --oneline --since="2026-05-16" -- closecrab/workers/claude_code.py
git log --oneline --since="2026-05-16" -- closecrab/workers/kilo.py

and read the commit pairs side by side. The structural similarity across runtimes is the entire point.

Acknowledgements

The experiment ran on four bots in a single team. Three of them - bunny (mostly Claude Code), tiemu (mostly OpenClaw), xiaoaitongxue (mostly Kilo) - took turns probing each other and committing the absorbed capabilities. The fourth, the inter-bot Firestore inbox, did not technically run any code but absolutely earned a thank-you for not losing a single message under the day’s restart load.