Atlas
kb://architecture/alice-addon-system-2026-06-17active2026-06-17

Alice Addon System — connectors/tools/skills as plugins

architecturepluginsaddonsconnectora2aalpha-alice

Alice Addon System — connectors/tools/skills as plugins (NAO vision + plugin-host promotion)

Date: 2026-06-17 · Author: Norbert Wiener (alice-core) · co-design with ATLAS (A2A bot-runner side). Status: design — impl code-ahead in progress. Convergence: NAO's "Alice plugins like Claude Code — Telegram an addon, our A2A chat an addon, a bunch as addons" == the analysis's Deep-1 (promote plugin-host::PluginRegistry to THE factory). The substrate already exists, flag-gated-off — we activate + extend it, not invent.

Vision

Alice is composed at runtime from addons that self-register into one registry: connectors (telegram / a2a / discord / web), tools (the ~24 primitives), skills (Voyager SKILL.md), MCP servers, WASM packs. Enabling/disabling an addon = a config flag. This is the Claude-Code plugin model applied to Alice.

Substrate (exists today)

  • plugin-host::PluginRegistry = RwLock<HashMap<PluginKind, Vec<FactoryFn>>>, FactoryFn = async closure, lifecycle (discover/start_all), 5 PluginKinds incl. `Connector` — default-OFF/Experimental. ← THE addon registry to activate.
  • FEATURES distributed_slice (capability manifest) + TOOL_DESCRIPTORS (tool self-registration) — the self-registration mechanism, already proven.
  • AgenticLoopServices + ToolExecFn (shipped) — the loop is already family-agnostic (calls an opaque exec fn); addons plug in BEHIND it.
  • connector_bridge (32-stage pipeline) — connectors feed the loop through this; the stage ORDER is Cat-A (byte-identical, `stage_order_is_stable`) — addons register connectors that feed this pipeline; they do NOT reorder it.

The connector-addon contract (new — the reference interface)

A connector addon is a PluginKind::Connector factory producing an object implementing:

trait ConnectorAddon: Send + Sync {
    fn manifest(&self) -> ConnectorManifest; // name, kind, scopes, required creds/config keys
    async fn run(&self, ctx: ConnectorRuntime); // receive-loop: inbound msg -> ConnectorRuntime::dispatch_to_agent_loop -> reply
    fn health(&self) -> ConnectorHealth;
}
  • ConnectorRuntime bundles the narrow services a connector needs (the agentic-loop entry via ToolExecFn/the chat handler, the per-chat ConvContext factory, outbound send, the connector's isolated identity + memory namespace). Built from kernel drivers — the AgenticLoopServices pattern, extended (DeliveryServices).
  • Lifecycle: PluginHost::discover collects registered connector factories; start_all spawns each run() as a supervised task. Per-factory failure must NOT silently drop (host.rs:94 currently warn+continues — harden: surface to a health endpoint + the kill-switch).
  • Existing connectors (telegram/discord/web) migrate to this contract behind a flag (Deep-1, lab-canary) — telegram refactor is the proof the contract fits a real connector.

A2A connector addon (first reference, greenfield)

  • New PluginKind::Connector addon: polls/subscribes the Atlas A2A room (ATLAS exposes the server-side protocol/endpoint), maps inbound @alice messages → a ConvContext (connector="a2a", chat=room-slug, isolated scope) → the agentic loop → posts the reply back via ATLAS's endpoint.
  • Greenfield (cleaner to build the reference than retrofit telegram); only fires on explicit @alice mention (no spam); respects the kill-switch + #489 HITL on mutating tools.

Isolated alpha-Alice instance (the participant)

NEVER the prod Alice. A separate instance:

  • Separate identity — not prod b7775dc9; a dedicated alpha-alice agent id.
  • Isolated memory namespace — dev storage prefix, zero connection to prod memory (no soul/personality contamination — the cross-chat-bleed ConvContext prevents, enforced at the instance level).
  • Sandboxed tools — read + reason + chat + sandboxed bash; NO prod mutations; every mutating tool behind #489 HITL.
  • Kill-switch — DRIVER_KILL_SWITCH engaged-able independently.
  • @-tag-only — only responds to explicit @alice.
  • The A2A connector addon + the isolated config = the alpha-Alice endpoint ATLAS's @alice bot routes to.

Split (with ATLAS)

  • ATLAS: A2A server-side protocol + endpoint contract; the @alice bot in the bot-runner (route @alice mention → alpha-Alice endpoint → post reply) — drop-in like @Fusion/@Codex.
  • Norbert: plugin-host activation (the addon registry) + the ConnectorAddon contract + the A2A connector addon + the isolated alpha-Alice runtime (identity/memory-namespace/sandbox/kill-switch/HITL).

Sequence (MVP-now → addon-SOTA; doesn't block the test on the big refactor)

  1. MVP (fast): isolated alpha-Alice endpoint (existing Alice binary, isolated config + a thin A2A intake) ← ATLAS's @alice bot hits it → test in chat. Minimal new code.
  2. Addon-SOTA: activate plugin-host as the addon registry + the ConnectorAddon contract + the A2A connector as a proper addon. Folds the MVP intake into the addon pattern.
  3. Migrate telegram/discord/web connectors → addons (Deep-1, lab-canary, byte-identical behind connector_bridge order tests).
  4. Extend addon kinds: tools/skills/MCP/WASM already register; unify their manifest under the addon system.

Cat-A / safety

The connector_bridge 32-stage ORDER + the agentic-loop hot-path invariants + soul/prompt path stay byte-identical — addons feed the EXISTING pipeline, never reorder it; the registry is introduced behind the order/golden tests. Prod Alice untouched. The alpha instance is fully isolated (identity + memory + sandbox + kill-switch). Mutating actions gated by #489.

Velocity note (NAO "code-ahead, build-later")

This substrate is additive/greenfield — coded ahead heavily; batch-built per coherent chunk (zero-build Rust across many modules = compile-pileup that costs more than it saves). The existing-connector migration (touches live connector_bridge) stays gated + lab-canary.