Daemons

Command Center is a desktop shell over a small fleet of background services — the daemons. Each is a local process that owns one job: harvesting news, executing routines, serving the knowledge base, generating images, exposing shared memory, running the Voice assistant. The views talk to them over local HTTP; your agents reach the same services through their MCP servers. One daemon, two doors.

The privacy posture is structural. Every daemon binds a loopback address (127.0.0.1) — these services are reachable only from your own machine, and nothing about the design exposes them beyond it. They are local components of a desktop product, not hosted endpoints.

The roster

Ports are defaults, configurable per service in the configuration reference. The provisioned-local graph server (ArcadeDB, ports 2480 and 7687) runs on the same loopback-only posture but is managed from Settings ▸ Database rather than as one of the daemon cards.

What each one does

Observer harvests your configured sources on per-batch and per-source schedules and writes items into documents/news_harvest/ — Markdown items plus a local index. The Observer view and the intelligence desk sit on top of what it collects.

Routines is the platform's automation engine. It keeps the schedule for every routine, spawns a fresh agent process per execution, tracks jobs with retry and backoff, and writes per-execution logs to documents/routine_logs/. It also hosts the HTTP APIs for the products pipeline, both video engines, and footage preparation — which is why several creation-side MCP servers list it as their backend.

Knowledge base owns the graph work described in Knowledge graph: ingest and workspace management, the continuous root-mirror sync, lint, the activity log, and the logic behind the kb_* agent tools. It runs standalone, so you can restart it — cycling the knowledge layer — without touching your agent sessions; the tool connections heal on reconnect.

Image generation serves image requests from the intelligence pipeline and the products pipeline. It is the one service with a hard key requirement: it runs only when a paid-tier image key is configured, and is skipped at launch otherwise — by design, so a missing key never half-breaks the rest of the platform.

Voice is the backend of the Voice assistant: HTTP for requests, a WebSocket for streaming, one process for both. Its conversation history is a local store with the same backup machinery as the rest of the data layer.

Shared agent memory is the small HTTP surface the Memory view reads and curates through. Unlike the others it is not a standalone process you manage: it starts inside the memory tooling that launches with your agent sessions, and needs no card of its own.

MCP gateway fronts the full tool stack at one endpoint. Grounded agent terminals and routine executions can share it instead of each spawning a private set of tool servers — a resource win that is transparent when enabled, and health-gated: if the gateway is down, sessions fall back to their own servers automatically.

Lifecycle — Dashboard ▸ Platform Health

Platform Health is the daemons' control surface. Each managed service has a card with live status, start / stop / restart, and its autostart toggle.

• Standalone by design. The managed daemons (observer, routines, knowledge base, image generation, Voice, and the local graph server) are independent processes owned by the app — they are not children of your agent sessions and keep running when a session restarts. Restarting one is a Platform Health action and touches nothing else.
• Autostart. Which services launch with the app is a hot runtime setting (autostart.*), one toggle per service on its card. The shipped default is on for everything — a fresh install starts ready.
• Graceful shutdown. Stop actions ask the daemon to finish cleanly rather than killing it, and on installed builds every spawned service is bound to the app's own lifetime — quitting Command Center takes the fleet down with it, so nothing is left orphaned.
• Restart-bound configuration. Daemons read their keys and wiring from the environment file once, at process start — after changing a key, restart the affected daemon from its card. Hot runtime settings, by contrast, are picked up on the next operation with no restart.

Health, logs, and data

• Status is live on each Platform Health card, in the title-bar daemon strip of the views that depend on a service, and in the health lamps of the Cortex overview. Every daemon answers a health endpoint, and the views degrade honestly when one is down — offline panels with a retry, never silent failure.
• Diagnostics start at Settings ▸ Doctor, which includes daemon reachability and the graph-database probe among its checks.
• Logs. Routine executions log to documents/routine_logs/; harvested content lands under documents/news_harvest/. Service-level status and errors surface in the owning views.
• Data. Each daemon owns its data as local files — mostly SQLite stores under the install root, each self-creating on first run. The Data Layer view (under Settings) lists every store with its size, backup posture, and restore controls, so the platform's entire local data footprint is visible in one place.

Where to go next

• Configuration reference — ports, keys, and the autostart settings behind the cards
• MCP servers — the tool fabric your agents reach these services through
• Routines — the catalog the routines daemon executes