Architecture

How does DaemonCore work?

One idea runs underneath everything else: an agent's output is checked against a governance layer that is defined before the agent runs and cannot be altered from above. Governance is foundational here, not a setting bolted on afterwards. The rest of this page follows that idea from structure to a real, recorded execution.

Authority is separate from execution

The central decision in DaemonCore is that the component doing the work is never the component that decides what work is permitted.

Agents are a third tier. They receive structured instructions over the message bus and return plans, code, patches or analyses — but never touch kernel state or queues directly. An agent cannot grant itself a capability, because the authority to grant one does not live where the agent runs. The diagram below shows that separation.

How an agent is assembled

Every agent is assembled from three structural inputs before it operates: a rulebook (behavioural constraints), a scope boundary (operational range) and a context focus (current workload). Assembly is not a suggestion — it happens through an ordered, mandatory boot sequence.

The order is the point. Boundaries are set in phase 3, before the agent becomes operational, so there is no window in which an agent is running but ungoverned — it starts running only once its limits are in place. And because the same configuration produces the same initial state, an execution can later be reasoned about from the conditions it started from.

What an agent may do

Capabilities are an envelope with defined ceilings, and one asymmetric rule does most of the work:

Identity overlays follow the same asymmetry — an identity changes behaviour and tone and may narrow what an agent does, never widen it. So the maximum reach of a session is fixed at boot; nothing afterwards can extend it. Extension points exist too — custom role profiles, environment-specific boundary configurations, external tooling hooks — but each runs inside that ceiling and can only narrow it.

Policy is decided within the envelope, but governance is itself constrained: it cannot add capabilities outside lineage, permit safety-invariant violations, grant capabilities beyond the envelope, or introduce nondeterministic overrides.

How work flows — and becomes evidence

Agents never call one another. They exchange typed messages over the MAX bus, which routes by role — developer, reviewer, orchestrator, system — not by agent or vendor. Two properties make the bus a governance mechanism rather than plumbing: a message that does not match its schema is rejected before it routes, and the message type decides which role may receive it.

Messages move through an explicit lifecycle in role-scoped queues, so the record of what was requested, by whom, and what became of it is a property of the transport itself. That is what makes an execution reviewable — and what lets a real run be recorded and replayed rather than merely described.

[INFO] [MAX Bus] Published: reviewer/EVID-e9b58172-reviewer.json
[INFO] [MAX Bus] Claimed: reviewer/EVID-e9b58172-reviewer.json
[WARN] [EnforcementGate] Advisory: No skill match: No candidates found in any registry
[INFO] [Execution] Created exec-a41c2c95cbc8 | intent=code_review_request | trigger=queue_message:EVID-e9b58172 | participant=reviewer

Routing by role is also what allows vendor isolation: a reviewer is a reviewer whether it is served by Claude, GPT, Gemini or a local model, because the bus addresses the role and the governance layer applies the same rules beneath all of them. Replay the full recording to watch this lifecycle line by line.

You have read the layers in order. The same architecture can also be read by its relationships — start from any concept and follow what depends on it.

Where this goes next

This page is the conceptual level. Each destination below takes it somewhere concrete.