Adapter boundary
The adapter boundary keeps runtime-specific execution, memory, sessions, and media local while making the runtime visible enough to operate from the OpenOrange dashboard.
// attach.runtime_adapter
Runtime adapters for AI agents
OpenOrange is runtime-oriented rather than runtime-locked. OpenClaw is integrated today, while Hermes, IronClaw, and custom runtime integrations are on the way.
Runtime integrations let different agents join one OpenOrange workspace without pretending they are all the same. Each integration exposes the identity, chat, health, usage, channels, and actions the product needs.
01
Adapters keep execution details in the runtime.
02
The workspace receives normalized health, request, usage, and audit signals.
03
OpenClaw is the deepest current runtime integration, not the whole product boundary.
04
Incoming runtimes can plug into the same workspace and direct-control contract.
Supported shapes
OpenClaw is integrated today. Hermes and IronClaw are on the way, with explicit contracts for identity, chat, health, actions, secrets, usage, and audit rather than a lowest-common-denominator wrapper.
Why adapters matter
Agent runtimes change quickly. Explicit integrations let the workspace stay coherent while runtime implementations evolve underneath it.
// questions
Is OpenOrange only OpenClaw-backed?
No. OpenClaw is integrated today, while OpenOrange is designed to bring multiple runtimes, model routes, tools, and channels into the same private workspace.
Do adapters copy runtime state into OpenOrange?
No by default. They expose operated metadata, references, health, events, and actions while live runtime state stays where it runs.