Architecture

Explicit subsystems instead of one opaque agent blob.

OpenCAS is organized around runtime concerns: bootstrap, memory, embeddings, autonomy, scheduling, telemetry, platform trust, phone, control plane, and channel integration.

Primary subsystems

bootstrap/

Configuration resolution, store wiring, provider material, and runtime assembly.

runtime/

Conversational loop, scheduler, creative cycles, Telegram lifecycle, and phone lifecycle.

memory/

Episodic storage, distilled memories, graph edges, and artifact-backed memory ingestion.

context/

Session context, retrieval fusion, resonance signals, and memory-backed prompt assembly.

somatic/

Arousal, fatigue, tension, valence, focus, energy, certainty, and modulation logic.

autonomy/

Self-approval, creative ladder, work store, commitments, and executive state.

scheduling/

Durable schedules, calendar views, and run history.

platform/

Capability inventory, extension descriptors, and trust control surfaces.

telemetry/

Append-only runtime events and query helpers for the Logs view.

daydream/

Reflection storage, conflict storage, keeper flow, and promotion lineage.

api/

FastAPI server plus config, chat, memory, operations, usage, identity, executive, platform, phone, schedule, telemetry, and Telegram routes.

dashboard/

Single-page operator UI for inspection, control, and configuration.

Runtime loops

Loop	Role
Conversation	Handles user input, retrieval, tool use, and response persistence.
Voice	Transcribes microphone input and synthesizes spoken replies when enabled.
Creative / background	Checks idle opportunities, evaluates the creative ladder, and generates daydream sparks.
Scheduling	Drives durable task and reminder schedules on a fixed cadence.
Consolidation	Reweights memory and continuity state over time.
Telemetry	Appends events, aggregates usage, and feeds the Logs tab.

Persistence

The state directory is configurable. Under the current CLI, the default is ./.opencas.

memory.db for episodes, memories, and graph relationships
context.db for session context and message history
tasks.db and work.db for background execution state
plans.db for commitment and planning state
daydream.db for reflection and conflict tracking
tom.db for belief and intention state
telemetry/ for event and usage logs
provider_material/config.json and provider_material/.env for gateway credentials

API and dashboard

API route groups

Config, monitor, chat, daydream, memory, operations, usage, identity, executive, platform, phone, schedule, telemetry, and Telegram.

Dashboard tabs

Overview, Health, Chat, Operations, Schedule, Usage, Daydream, Memory, Identity, Executive, Platform, System, and Logs.

Architectural truths

The repo currently has a strong operator surface and broad internal observability.
The repo is not yet documented here as a polished package-manager install.
The release docs should not describe the system as cloud-free unless the configured model lanes are truly local.
Phone, voice, schedule, platform, and telemetry are first-class runtime surfaces, not side experiments.