Dialog Ecosystem v0
Scope
Defines how AIOS v0 extendsdialog into a multi-channel ecosystem while preserving canonical AIOS ownership over session, routing, lease, and policy models.
This page formalizes what AIOS reuses from OpenClaw, cc-connect, and bridge-style channel projects, and what MUST remain under AIOS control.
Terminology
- Dialog: the canonical multi-channel ingress layer in AIOS.
- Target: the concrete dialog-backed destination such as
codex,claude_code,opencode,wechat, ortelegram. - Protocol compatibility: adapter compatibility without handing over core platform authority.
- Implementation reuse: selectively reusing channel adapter implementations behind AIOS contracts.
Normative Spec
Ecosystem Strategy
AIOS v0 MUST treat dialog ecosystem reuse with this priority order:- protocol and transport semantics may reference
cc-connect - channel ecosystem boundaries may reference OpenClaw
- bridge-style operational experience may reference WeChat and Telegram channel projects
- canonical session, route, lease, desired-version, and policy models MUST remain AIOS-owned
Core Reuse Rule
AIOS MUST follow this principle:reuse channel ecosystem, not platform sovereignty.
What AIOS Reuses
From OpenClaw
- channel adapter boundary model
- centralized Gateway routing mindset
- multi-channel access shape
- unified health, retry, and event handling patterns
From cc-connect
session_id / msg_id / seq- dedup semantics
- reconnect semantics
- resume cursor semantics
- at-least-once with receiver idempotency
From bridge-style WeChat/Telegram projects
- owner or allowlist gating
- polling versus webhook transport tradeoffs
- context cache and cursor window experience
- product mindset that remote channels are entrypoints, not the primary development authority
What AIOS MUST Keep Canonical
The following MUST NOT be delegated to OpenClaw or any channel adapter:- canonical session model
- stable route key
workspace_id + agent_id - lease, desired_version, and fencing model
- platform-level approval and policy boundary
- forward-only and metadata-only persistence boundary
- DevBox, Probe, and Worker Sandbox lifecycle authority
Target Set
The initial dialog target set in v0 SHOULD include:codexclaude_codeopencodewechattelegram
Reuse Levels
- Level 1: protocol compatibility first. This is the v0 default.
- Level 2: implementation reuse by adapter evaluation. This is a later-stage option.
- Product-level control-plane wholesale reuse MUST NOT be the v0 approach.
Examples
Ownership split
| Concern | Reuse allowed | AIOS canonical owner |
|---|---|---|
| envelope semantics | yes | shared contract enforcement |
| channel adapter boundary | yes | AIOS Gateway and Probe integration |
| stable routing key | no | AIOS only |
| lease and fencing | no | AIOS only |
| transcript persistence boundary | no | AIOS only |
Target normalization example
Error & Recovery
- A channel ecosystem integration MUST NOT bypass canonical dialog contracts during reconnect or replay.
- Adapter-specific transport recovery MAY exist, but canonical route and lease ownership MUST remain with AIOS.
- Any attempt to persist transcript bodies as part of ecosystem reuse is a policy violation.
Security & Audit
- Multi-channel reuse MUST preserve forward-only and metadata-only audit boundaries.
- OpenClaw-compatible adapters MUST still emit AIOS-compatible metadata and health signals.
- Channel reuse MUST NOT create a parallel control plane.
Status
Current status:draft
Source discussions:
docs/maintainers/conversation-records/agent-platform/2026-03-24-dialog-channel-ecosystem-reuse-strategy-v0.mddocs/maintainers/conversation-records/agent-platform/2026-03-24-openclaw-to-aios-architecture-crosswalk.mddocs/maintainers/conversation-records/agent-platform/2026-03-24-p1-freeze-result-accepted.md
Changelog
- 2026-03-24: Initial formal dialog ecosystem specification created from frozen discussion drafts.