Skip to main content
This developer-facing hub explains how the daemon owns Monad Mesh — the agent team runtime — while clients and agent runtimes attach through public contracts. Monad Agent Runtime is the first-party agent runtime that ships with it, one mesh member among several. It answers three questions:
  1. What are the pieces? See the layer map below
  2. How does the first-party agent execute a turn? Follow the request walkthrough
  3. Where should you read next? Choose one internals category
Internals are grouped by the part of the system they describe: User-facing feature docs live in ../usage/; repo norms live in ../engineering/.

​
1. The layer map

Everything in Monad follows one rule: the daemon owns state, clients only render and control it. Three consequences worth internalising before reading any deeper doc:
  • No client is authoritative. Closing the browser does not stop a turn; a CLI, a Telegram message, and an editor can drive the same session.
  • Workplace Experiences are a web-UI feature, not a runtime layer. They live inside apps/web and re-render a project’s page; the CLI, TUI, editors, and channels do not go through them. A capability that must exist on every surface belongs in the daemon, including tools, commands, hooks, and protocol. It never belongs only in an experience.
  • Everything crossing the process edge is parsed and never trusted: HTTP, WebSocket, disk, MCP, atom packs, and model output alike. See the runtime security model.

​
2. How the first-party agent executes a request

This sequence describes Monad Agent Runtime, the first-party member. Other agent runtimes use their adapter and observation contracts instead. Three invariants this diagram encodes:
  • Durable before published. State is committed to the store, then the event is emitted. A reconnecting client never sees an event for state it cannot fetch.
  • Two planes, never merged. Low-volume lifecycle rides the control WebSocket; token deltas ride a per-message SSE stream. Details: infra/realtime-channels.md.
  • The gate is fail-closed. A high-risk tool with no gate available is denied, not allowed. Details: agent-runtime/tools.md.

​
3. How the process comes up

Startup is a topologically ordered lifecycle graph, not an ad-hoc main(). Hot reload is deliberately conservative: trailing debounce, single-flight, commit-on-success. Full module table: infra/daemon-architecture.md.

​
4. Where state lives

Path layout is owned in one place (@monad/environment), including the XDG split on Linux. See infra/runtime.md. Managed project scope and access rules are documented in agent-team-runtime/project-sessions.md.

​
5. How the system is extended

Extension is declare-then-register: a manifest declares kinds, the host audits them, the runtime enforces them. Built-in tools are not an atom kind. They ship with the daemon so their security guards stay first-party. Details: infra/atoms.md, ../usage/skills.md, infra/hooks.md.

​
6. Containment layers

Each layer assumes the one above it failed. The runtime security model explains the threat boundary, and sandbox backends records per-platform enforcement. Monad Mesh: agent-team-runtime/ Monad Agent Runtime: agent-runtime/ Infra: infra/