Daemon Architecture

• Users and operators: what starts, what hot-reloads, and what remains local.
• Third-party developers: where to extend Monad and which boundaries not to cross.

​

User-facing model

1. Runs preflight: resolves flags, paths, singleton/process mode, logging, and MONAD_HOME.
2. Builds the core runtime: opens the store, loads the four settings files (config.json, agents.json, mesh.json, auth.json), then starts lifecycle modules in dependency order.
3. Builds network state: resolves loopback host, port, TLS, local fallback, and remote-access policy.
4. Builds agent-facing services: model router, approval gate, hooks, commands, memory, scheduling, channels, and daemon handlers.
5. Launches transports: HTTP REST/SSE over TCP and Unix socket, WebSocket push, stdio mode, ACP mode, channels, and background monitors (binding and fallback semantics: runtime.md).

• filesystem watchers only invalidate the current snapshot;
• ConfigManager waits for a trailing quiet period before applying;
• only one apply is in flight at a time;
• if another change arrives while apply is running, the daemon marks itself dirty and applies the final latest snapshot after the active apply settles;
• accepted state changes only after the owning module commits successfully.

​

Startup and reload internals

apps/monad/src/main.ts
  -> application/lifecycle.ts:startDaemon()
    -> application/core-runtime.ts:createCoreRuntime()
      -> runtime/create.ts:createDaemonRuntime()
        -> RuntimeKernel
        -> ConfigManager
    -> application/network-runtime.ts
    -> application/agent-runtime.ts
    -> application/transport-runtime.ts

• id
• requires / after
• criticality
• start(ctx, signal)
• optional reload(current, snapshot, ctx, signal)
• optional stop(current, ctx)

​

Developer extension points

​

Ownership rules for core contributors

• Keep lifecycle adapters beside the behavior they own. Do not create a second hierarchy under runtime/modules.
• Keep runtime/create.ts as the composition root for core lifecycle modules. It imports descriptors; it should not contain business logic.
• Keep application/lifecycle.ts as orchestration glue for preflight, core, network, agent-facing services, handlers, and transport launch.
• Do not rebuild the agent loop at daemon startup. Model/provider services start at startup; per-session agent execution is assembled when a session turn runs.
• Keep runtime objects out of Zustand. Zustand stores serializable lifecycle state only; service instances live in RuntimeContext.
• Do not introduce RxJS, revision queues, or a global event log for local config reload. Use the existing trailing-debounce, single-flight ConfigManager.
• Settings writes go through ConfigManager.updateConfig() or ConfigManager.updateAuth() so persistence and hot-apply stay coupled.
• New reloadable subsystems should expose a stable facade and mutate/reconnect internal handles on reload where possible.

​

Text sequence

1. main.ts imports startDaemon() and exits.
2. startDaemon() runs preflight and returns early for supervisor-only modes.
3. createCoreRuntime() opens the data layer and loads the initial config/auth snapshot.
4. createDaemonRuntime() creates RuntimeKernel + ConfigManager.
5. RuntimeKernel starts lifecycle layers:
   store
   agent.model / platform.sandbox / services.log-maintenance
   capabilities
   atoms
   capabilities.skills / capabilities.mcp
6. createNetworkRuntime() resolves listener configuration from the accepted config.
7. createAgentRuntime() builds agent-facing services and stable registries.
8. createDaemonHandlers() binds HTTP/RPC/session/settings handlers to those services.
9. launchDaemonTransports() starts TCP, Unix socket, WebSocket, stdio/ACP, and channels.
10. File watchers invalidate ConfigManager; ConfigManager applies the latest snapshot through RuntimeKernel.reload().