Skip to main content

​
Dialog Ecosystem v0

​
Scope

Defines how AIOS v0 extends dialog 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, or telegram.
  • 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:
  1. protocol and transport semantics may reference cc-connect
  2. channel ecosystem boundaries may reference OpenClaw
  3. bridge-style operational experience may reference WeChat and Telegram channel projects
  4. 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:
  • codex
  • claude_code
  • opencode
  • wechat
  • telegram
All targets MUST normalize through the canonical dialog model rather than invent target-specific session rules.

​
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

​
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.md
  • docs/maintainers/conversation-records/agent-platform/2026-03-24-openclaw-to-aios-architecture-crosswalk.md
  • docs/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.