Feature: Bind existing OpenClaw agents to Mission Control board agents

[ailuvu-art]

Feature Proposal: Bind Existing OpenClaw Agents to Mission Control Board Agents

Summary

Add a first-class way to bind an existing OpenClaw agent (e.g. axiom, forge, Claude/Codex-based custom agents) to a Mission Control board agent role (lead/worker), instead of always provisioning a new MC-native workspace agent.

---

Problem

Today, board agents are provisioned as MC-native agents/workspaces. This is stable, but it causes:

• duplicated identities/personas (Telegram agent vs board agent)
• duplicated memory/workspace state
• extra setup overhead
• harder model parity when users already have tuned OpenClaw agents

For teams already running high-quality custom agents, this makes board adoption slower.

---

Proposed Solution

Introduce an Agent Source mode when creating/editing board agents:

• native (current behavior, default)
• bound (new): bind board role to an existing OpenClaw agentId

For bound mode:

• board agent stores bound_openclaw_agent_id
• MC routes board chat/task coordination to deterministic board session keys
• gateway resolves those session keys to the bound OpenClaw agent
• board context remains board-scoped while reusing existing agent capability/model/persona

---

Example UX

Board → Agents → Add Agent

1. Source: Bind existing OpenClaw agent
2. OpenClaw Agent: axiom
3. Role: Lead or Worker
4. Save

Optional toggles:

• dedicated board session vs shared session
• allow board-specific model override
• context isolation guardrails

---

Suggested Data Model Additions

On agents table:

• source_type: native | bound
• bound_openclaw_agent_id: nullable string
• bound_session_strategy: dedicated | shared (default dedicated)

---

Benefits

• Reuse tuned agents immediately (Claude/Codex/etc)
• Faster onboarding to board workflows
• Less duplication of persona/memory/config
• Better consistency across channels (Telegram/board/webchat)

---

Risks / Considerations

• context bleed across boards/channels if shared sessions are used
• debugging complexity for bound routing
• multi-board contention for a single bound lead agent

Mitigations:

• default dedicated board session strategy
• clear per-board routing logs/audit trail
• optional binding limits/policy warnings

---

MVP Scope (suggested)

1. Support bound worker agents first
2. Add bound lead support after worker path stabilizes
3. Add optional model override and context isolation policies

---

Why now

Mission Control is becoming coordination-first. Teams already running custom OpenClaw agents need a clean bridge into board workflows without creating duplicate identities.

This feature would significantly improve adoption and reduce operational friction.