okf
source_of_truth last_verified verified_by review_scope platform_notes Cargo.toml 2026-10-28 agy@debby Product wording and links; no new runtime acceptance. FreeBSD: rc.d service; Linux: systemd

Colibri

156k Go tokens · 78% of context window

Colibri is the Clawdie control plane: a cross-platform Rust daemon that coordinates AI-agent tasks, observes lifecycle state, tracks cost, and exposes a Unix-socket API plus MCP integration. It runs as the colibri service on FreeBSD and as a standalone daemon on Linux.

Role in Clawdie

From a bootable USB drive to your autonomous AI workstation. That is the Clawdie product direction. Colibri supplies the coordination layer between the agent harness, terminal sessions and system policy. The Clawdie image repository owns boot media and installation; this repository owns the control plane. Full workstation acceptance and the complete Jev/shared-memory integration remain separate development gates.

Colibri owns orchestration; bherdr owns terminal and session connectivity:

zot / pi  ←→  bherdr (`herdr` process, panes, PTYs, sessions)
                         │ newline-JSON socket API
                         ▼
                 Colibri control plane
           tasks, lifecycle, MCP, ledger, policy
                         │ Jev System One (first-line classifier)
                         │ deterministic policy floor remains authoritative
                         ▼
             allow / require grant / block

Colibri consumes bherdr as a process over its documented socket boundary. It does not import bherdr, share Rust/Go types with it, or call Oxigraph directly from agents.

Policy & decision gate (Jev, typed responder)

Colibri's provisional development design separates three decision roles:

• System 0 — deterministic policy floor: Colibri and OS controls enforce identity, capability, hard constraints, and authorization for every tool execution.
• System 1 — Jev typed decision model: Makes bounded semantic route decisions (block, operator_review, or proceed_to_next_stage) from typed questions and grounded state. For fully resolved closed-schema tasks it may select a registered routine without calling System 2; confidence is not proof of correctness.
• System 2 — reasoning LLM: Handles open-ended planning, synthesis, code authoring, and dialogue. The harness coordinates roles and execution; it is not System 2.

These System 0/1/2 names are provisional development labels, not a claim that all decisions are serial. “Split-brain” describes the wider separation of cognitive roles and state/ownership boundaries; it is not an alias for the numbered roles.

untrusted prompt → Jev / Boundary 1 ── block ───────────────→ stop
                                    ├─ operator_review ───→ operator
                                    ├─ needs reasoning ───┐
                                    │                      ▼
                                    │                  System 2 LLM ─┐
                                    └─ closed task ─► registered routine ┘
                                                                    │
                                                              proposed action
                                                                    ▼
proposed tool action → Jev / Boundary 2 ── block ─────────────→ stop
                                           ├─ operator_review → operator
                                           └─ pass_to_authorizer
                                                ↓
System 0 deterministic authorization → allow / deny → execution

Jev decides its bounded semantic route, but has no direct access and no tool-execution authority. A sufficiently confident proceed advances automatically under the configured policy; a proposed tool action still passes through Boundary 2 and System 0 authorization:

• block: Stop this route.
• operator_review: Hold for operator decision.
• proceed: Advance to the next stage; at Boundary 2 this means the deterministic authorizer, not execution.

See the Jev decision gate plan, architecture wiki, and gatekeeper record for details.

Memory architecture

Colibri has not implemented a memory API or integration. The planned logical memory contract is remember, recall, forget, and improve; the planned backend split is:

system-of-record memory
                 │ asynchronous extraction
       ┌─────────┴─────────┐
       ▼                   ▼
OpenViking             Oxigraph
fuzzy recall           exact facts + relationships
       └─────────┬─────────┘
                 ▼
       colibri-daemon → colibri-mcp → agents

OpenViking is intended for semantic/fuzzy recall; Oxigraph (informally, Oxy) is intended for exact facts and relationships. They are planned as rebuildable, provenance-bearing projections behind a future Colibri memory contract—not as the agent-facing API or established systems of record. The canonical store's representation remains unselected. Every derived fact must carry at least source_ref, derived_at, and derivation_method. Extraction should be asynchronous and idempotent. These are planning constraints, not shipped functionality; see the canonical planning baseline for past proposals, superseded decisions, and remaining questions.

Current workspace

The workspace contains the daemon and typed client, MCP bridge, agent lifecycle state machine, SQLite ledger, skills catalog, runtime inventory, jail/deployment helpers, and the ratatui dashboard. The colibri-mcp bridge remains Rust. The glasspane dashboard is retained until bherdr integration, zot/pi verification, and attention parity are proven.

Build and test

cargo build --release --workspace
cargo test --workspace
cargo clippy --workspace --all-targets -- -D warnings

Target FreeBSD builds use x86_64-unknown-freebsd and rustls; Linux remains a validation leg. For the full merge gate, run ./scripts/ci-checks.sh.

Learn more

• Architecture wiki
• Agent tooling and operational skills This is an agent-workflow dependency for development and operations, not a Colibri runtime dependency.
• Agent harness
• Glasspane
• Quality gates
• Oxigraph design
• bherdr Phase 01 coexistence plan

Colibri's own code is BSD-3-Clause. See AGENTS.md for development and cross-platform rules.