ZeroClaw
ZeroClaw proposes an embeddable runtime contract before moving callers
ZeroClaw's September 24 runtime proposal separates supplied capabilities from daemon subsystems. It adds unused types and a migration plan, not a working embedding API. A separate Core Team exception is still required before the contract can land in its temporary runtime crate.
ZeroClaw has put a concrete design in front of reviewers for making its agent runtime usable by an embedding application. The proposed interface accepts sources of model providers, memory, tools and outbound channels instead of having each entry point construct its own copies. The September 24 proposal deliberately stops at documentation and a type skeleton. That makes it a direction-of-travel story: the project is specifying the dependency and ownership boundary before asking downstream callers to move.
The facts
- PR #11090 adds RuntimeCapabilities types and a composition document; the inspected proposal says no caller uses them yet. - The document identifies parallel construction in the gateway, channels orchestrator and other runtime entry paths. - Capability sources are resolved per agent and configuration generation, rather than one finished instance serving every caller. - The existing DaemonRegistry retains subsystem supervision; it is not replaced by the capability registry. - Security-policy resolution stays in the runtime, and returned tools cannot widen the resolved policy. - PR #11092 separately proposes the holding-crate exception, with approving authority still pending Core Team review.
Why it matters
An embeddable runtime is valuable only if supplying components does not create a second, inconsistent authority model. The design makes that tension explicit. A provider may need to change when a session switches models, while an already-running turn should retain the configuration generation it began with. A memory source must resolve the right agent's store rather than a convenient process-global default. Those are lifecycle obligations, not simply dependency injection syntax, and they explain why the proposal uses sources rather than a bag of singleton objects.
Current
Both composition and exception requests remain open at inspection. The pinned design says proposed, not implemented; the illustrative Runtime and run_turn entry points are documentation rather than a working skeleton API. The configuration and security types constrain where the contract can live. The selected temporary home does not itself satisfy the governance rule: delegated placement judgment is explicitly distinguished from the Core Team approval required by ADR-016.
Evidence
Primary: zeroclaw-labs/zeroclaw PR #11090 (https://github.com/zeroclaw-labs/zeroclaw/pull/11090). Supporting context: zeroclaw-labs/zeroclaw PR #11092 (https://github.com/zeroclaw-labs/zeroclaw/pull/11092); zeroclaw-labs — runtime-composition.md (https://raw.githubusercontent.com/zeroclaw-labs/zeroclaw/1e2b05376fe229efcd602e39b4654d65dc0effba/docs/book/src/architecture/runtime-composition.md). Source pages and available diffs were inspected; test and live-account results remain attributed to their authors, not independently repeated measurements.
Operator take
For anyone considering embedding ZeroClaw, watch for the first caller migration and its parity evidence rather than building against a diagram as though it were a released contract. Useful checks include two agents resolving different memory stores, model switching without contaminating another session, and reloads that leave an in-flight turn's capabilities intact. The document calls for staged migration and evidence at each step. That sequencing is the meaningful signal: an independently consumable runtime should be demonstrated by an actual consumer, not inferred from the existence of public trait names.
Caveat
The proposal changes neither runtime behavior nor deployment requirements today. Reported formatting, lint and documentation checks do not prove embedding works. The new public types have no consumers, the holding-crate exception is pending, and the inbound command path belongs to separate work rather than this capability contract.
The proposal changes neither runtime behavior nor deployment requirements today. Reported formatting, lint and documentation checks do not prove embedding works. The new public types have no consumers, the holding-crate exception is pending, and the inbound command path belongs to separate work rather than this capability contract.