This preview is intentionally narrow. It is a Unix CLI preview for Apple Silicon macOS, not a full agent runtime. The bundle includes:
- a governance-only host
- allow/block demos and audit receipts
- a mock OpenClaw-shaped harness
- a bounded release-packet Q&A command
Example:
./signal-core ask "what are the host requirements?"
That Q&A answers only from the bundled release docs. It is not repo search and not a general chat assistant.
The question I’m really trying to validate is whether this split is useful in practice: should runtime and sandbox stay separate from a dedicated contract/approval/receipt layer, or should those concerns live inside the runtime itself?
I’d especially value feedback from people already running agent/tool systems in production.
If you think this should just be a runtime feature and not a separate layer, that’s the criticism I most want.
d-milliken•1h ago
The design goal is to keep governance separate from the runtime:
OpenClaw = runtime / tool loop NeMo Claw = deployment / sandbox Signal Core = contracts, approvals, minimal durable memory, and append-only receipts
This preview is intentionally narrow. It is a Unix CLI preview for Apple Silicon macOS, not a full agent runtime. The bundle includes:
- a governance-only host - allow/block demos and audit receipts - a mock OpenClaw-shaped harness - a bounded release-packet Q&A command
Example: ./signal-core ask "what are the host requirements?"
That Q&A answers only from the bundled release docs. It is not repo search and not a general chat assistant.
The question I’m really trying to validate is whether this split is useful in practice: should runtime and sandbox stay separate from a dedicated contract/approval/receipt layer, or should those concerns live inside the runtime itself?
I’d especially value feedback from people already running agent/tool systems in production.
If you think this should just be a runtime feature and not a separate layer, that’s the criticism I most want.