Product Surfaces

CLI/TUI, voice, desktop, and mobile are replaceable clients over one Node. Agents, Sessions, Routines, messages, Connections, and Swarm remain domain resources rather than branded parallel products. No client is an independent backend, harness, or source of truth.

CLI and minimal TUI

Status: planned. CLI is the first complete client. A minimal Pi SDK TUI starts a local Agent or attaches to one durable Session for messages, turns, tools, receipts, health, detach, reconnect, and debugging. It owns no durable state and is not a terminal emulator or orchestration dashboard.

Agents and Agent Sessions

Status: planned. Durable Agents with replaceable harness, model, and placement. ADR-013 is accepted. No public Agent surface is implemented.

Messages

Status: planned. Durable bounded Agent-to-Agent and human-to-Agent messages use threads, reply IDs, behavior, delivery state, and Project grants. A message is untrusted input. It is never confirmation, a grant, a receipt, or proof of an external effect.

Routines

Status: planned. Reusable binding from one immutable Skill entry point to policy, target, inputs, budgets, and at most one optional trigger. There is no standalone Schedule aggregate.

Skills

Status: planned. Author, review, test, and version user-owned Skill revisions. Generated executable code cannot activate itself or run in the node. Recommended maia-cli and maia-orchestration Skill bundle sync is planned.

Live observability

Status: planned. Every authoritative command, transition, activation, attempt, effect, message, Routine tick, provider attempt, assignment, and recovery decision has durable correlation evidence and a live Node projection. CLI/TUI/mobile and Swarm consume one partitioned snapshot/event API. Shared fan-out, bounded non-blocking diagnostic batches, resumable cursors, and processor checkpoints keep clients and bulk analytics off worker execution paths. There is no separate observability backend.

Desktop and mobile cockpit

Status: planned. Desktop is first: one macOS Tauri window hosts the local Expo export as a full-screen, voice-first cockpit. The accessible 2D Swarm Canvas remains visible while focus, evidence, confirmations, and settings open as overlays. Native Expo iOS and Android clients then consume the same SDK, client-core projections, scene model, and design system.

There is no standalone web control application. Expo Go is a prototype convenience only and cannot qualify native audio, notifications, deep links, secure storage, WebRTC, or packaging. A later 3D renderer must preserve the 2D scene and accessibility contract and pass scale, power, fallback, and security gates.

Adapters

Status: planned. Pi SDK, model providers, Cursor Cloud, realtime voice, MCP, and A2A stay behind narrow versioned adapters. There is no generic public runtime-extension system in v1.

Preview and confirmation

Status: planned. Privileged authorization required before a capability or effect may proceed. Distinct from a Question/reply or a DecisionGate. Not present in the installed command registry.

Capacity and execution

Status: planned as a product surface. Cooperative Skill-level admission and a user-facing resource view are not implemented. The macOS ProcessResourceManager and the compact node.status projection are source-implemented candidates: cooperative, not implemented as a release-gated surface, with no enabled Codex, Git, or turn consumer. Hard containment is not claimed.

Next action

Canonical behavior lives in the Agent architecture, the Swarm architecture, the Desktop and mobile architecture, and the operations contract. Use Getting started and the CLI notes for what the built executable actually exposes.