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, serving shared memory, running the Voice assistant, handling mail. 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) — nothing about the design exposes them to the network, and they are local components of a desktop product, not hosted endpoints.

Read that boundary precisely: loopback bounds the network, not the machine. Any other user signed in to the same computer, any other process running on it, and anything executing in a browser on it can reach these ports, and most of them carry no authentication of their own — they are built on the assumption that reaching localhost already means you are the operator. On a personal workstation that assumption holds. On a shared or centrally-managed machine it is the thing to think about before you treat this as privacy.

The roster

Ports are defaults, configurable per service in the configuration reference. The provisioned-local graph server (ArcadeDB) runs on the same loopback-only posture but is managed from Settings ▸ Database rather than as one of the daemon cards. Its ports depend on which backend mode you run:

The BOLT port is the one worth reading twice. An unqualified "7687" against a container-profile instance is the likeliest way to get a connection refused from a graph server that is running perfectly — the container publishes its internal 7687 as 7688 so it cannot collide with anything else that conventionally owns 7687 on the same host.

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 starts whenever its autostart toggle is on, with or without an image key, and reports unconfigured until one is present — the archive browser, the generation history, and its settings all work in that state; only generating an image does not. That is deliberate: a service that refused to start for want of a key could never tell you that was the reason. Doctor's image-key check is where the missing key is named.

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 serves the fleet's shared store over local HTTP. It is an ordinary managed service with its own Platform Health card, its own Start / Stop / Restart, and its own autostart toggle — start it there when the Memory view's Shared tab reports the store offline.

It has one property no other service has: an agent session can host the same surface as a hot spare. The memory tooling a session loads carries its own copy of that HTTP surface, so if the managed daemon is not running and you start a session, the port is answered anyway. Two consequences are worth knowing. The store can come back on its own, without you starting anything. And Stop can look like it did nothing — the app stopped the process it owns, a session picked the surface back up, and the card goes green again. Its Doctor row names which of the two is answering, so you can tell them apart at a glance. Closing the session releases it.

The agents' own memory tools do not depend on any of this: they read and write the database file directly, and keep working with Command Center closed.

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.

Email is the service under the Email view: it lists and reads your mailboxes, sends what you compose, and runs the inbox monitor that watches for new mail and feeds the agent queue. The agent-facing mail tools are a separate surface over the same mail client underneath — which is why the Email-sending control plane stops both at once. See Autonomy and controls.

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. Every service in the roster above — observer, routines, knowledge base, image generation, Voice, shared agent memory, the MCP gateway, and email — is an independent process 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. The local graph server is managed the same way but from Settings ▸ Database, since it is a database rather than a service card.
• 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