OpenClaw as a runtime shape
OpenClaw-backed agents can plug into OpenOrange through adapter signals: agents, channels, tools, health, requests, model routes, usage, and operator events.
// operate.openclaw_runtime
OpenClaw runtime operations
OpenOrange can operate OpenClaw-backed agents through private instances, runtime health, channels, adapter signals, reviewed workflows, local secrets, usage accounting, and audit proof.
OpenClaw is one runtime OpenOrange can understand. The operator layer can expose OpenClaw agents, channels, health, request traces, model usage, local secret references, reviewed workflows, and audit proof without making OpenClaw the only supported runtime.
01
OpenClaw agents can be represented as operated surfaces.
02
Channels, adapters, heartbeats, and health signals stay visible.
03
Runtime state remains with OpenClaw while OpenOrange stores operator proof.
04
The same operator contract can extend beyond OpenClaw.
Dashboard visibility
Admins should be able to see OpenClaw agents, ownership, runtime health, heartbeats, last-known state, request attribution, model usage, and audit context from the same surface.
Not the whole boundary
The product idea is bigger than OpenClaw. OpenOrange should operate multiple AI runtime shapes through the same governed contract.
// questions
Does OpenOrange require OpenClaw?
No. OpenClaw is an important runtime shape, but OpenOrange is the operator layer for a broader AI infrastructure surface.
What should OpenClaw keep locally?
Execution details, sessions, memories, media, raw logs, local caches, and secret values should stay in the runtime boundary by default.