Architecture
Responsibility, authority and execution are different things.
DaemonCore combines a governed agent kernel with an execution platform. Its operating contracts define the rules; runtime services apply those rules along configured execution paths. A specification and an implemented check are related, but they are not interchangeable.
Define the agent. Then bind the worker.
Agent Definition
Role carries responsibility and its authority boundary. Profile supplies a reusable operating mode or specialisation. Persona shapes interaction, without adding authority or expertise.
Runtime identity
The worker, vendor, model, project assignment and session remain separate inputs. A runtime worker can occupy a responsibility without becoming the definition of that responsibility.
Structured definitions feed a deterministic prompt compiler. The generated operating prompt and its source provenance can be inspected. Deterministic compilation does not mean deterministic model responses.
Project scope narrows the context
The catalogue defines the components. Project and runtime configuration select the operating identity and binding. Profile and Persona cannot grant authority that the Role and governance do not permit.
Changing a worker or its communication style does not expand its authority.
How much worker selection is implemented?
The current runtime binding resolves eligible Hermes workers from project persona records using role IDs, aliases and archetypes. It records provider, model and profile information. The homepage’s broader host, adapter and capability evaluation is an architectural illustration, not a recording of a universal scheduler.
Follow the request through the runtime
MAX Bus provides structured messaging and role-directed routing. Admission creates an execution record; the eventual outcome is a separate state. The configured governance mode determines whether a finding blocks admission or is reported as advisory.
recorded · RUN-001 · MAX bus → governance gate
[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=reviewerInspect the enforcement boundary
A secure deployment must connect the governed path to the tools that act on the world. The existence of policy text or a successful admission does not prove that every possible tool path is mediated. Evaluate the configured mode, external credentials, host permissions and result capture for the deployment being considered.
RUN-001 demonstrates partial advisory admission. It does not demonstrate model execution, universal bypass prevention or hardware-backed isolation.
The explorer below describes the architectural contracts and their relationships. Its recorded evidence links retain the limits of the individual capture.
Architecture Explorer
How does this fit into everything else?
The same architecture described above, organised around its relationships. Start from a perspective, then follow the links between concepts. Every relationship is named, so you can explore the whole system without relying on a diagram.
This view is composed from the architecture described on this page and the kernel documents it summarises. It organises that material; it does not add to it.
Start from a perspective
- Subsystem Entry perspective
Kernel
What decides what is allowed?
The declarative operating contract. Its specification it defines lineage and integrity, safety invariants, the capability envelope, the identity framework, governance limits, and the rules for governed execution.
Responsibilities
- Declare the safety invariants that execution must respect.
- Define the capability envelope as ceilings that may be reduced but never raised.
- State what governance may restrict and what it can never override.
- Remain read-only to the runtime and to agents.
Leads to
- The invariants it declares Non-negotiable rules that every execution must respect.
- The ceilings it defines The maximum reach available to any session.
- The limits it places on governance What policy is never allowed to override.
- How it is extended without being weakened Extensions run inside the envelope; they cannot widen it.
Reached from
- Runtime Entry perspective
Runtime
What actually performs the work?
The implementation tier. It carries the message-bus handlers, the scheduler and tool execution. It must obey the kernel’s rules and capability ceilings, and cannot modify lineage or safety invariants.
Responsibilities
- Perform how work is done, within the envelope the kernel defines.
- Operate the MAX bus and route work to roles.
- Coordinate multi-agent operation and keep an audit trail.
- Never grant a capability the kernel did not permit.
Leads to
- Obeys the rules and ceilings the kernel defines The component doing the work is never the one that decides what is permitted.
- Performs how the kernel’s declarations are carried out
- The bus it operates Agents exchange typed messages rather than calling one another.
- How it coordinates agents and records history
- How an agent reaches a governed state
Reached from
- Agent
Governed agents
What produces the outputs?
The third tier. Agents receive structured instructions over the message bus and produce outputs — plans, code, patches, analyses. They operate through configured runtime interfaces; direct access depends on host and tool permissions.
Responsibilities
- Receive typed instructions and produce structured outputs.
- Operate strictly within the capability envelope fixed at boot.
- Reach the governance gate with every output before it becomes an Execution.
Leads to
Reached from
- Workflow
Deterministic boot
How does an agent reach a governed state?
The boot contract orders configuration, operating-definition resolution and context assembly. The RPP compiler supplies one part of that chain; enforcement depends on the runtime path and its configuration.
Responsibilities
- Establish structure, then boundaries, before operation.
- Fix the capability ceiling for the session at boot.
- Make behaviour reconstructable, and therefore reviewable.
Reached from
Evidence
A genuine execution captured after boot (RUN-001)Partial — recorded, unsealed and not independently verified.
- Policy
Capability envelope
What limits what an agent can do?
Capabilities expressed as an envelope with defined ceilings. One asymmetric rule does most of the work: capabilities may be reduced at runtime, but never increased after boot.
Responsibilities
- Fix the maximum reach of a session at boot.
- Allow narrowing at runtime; forbid any widening.
- Bound governance, identity overlays and extensions alike.
Reached from
- Policy
Governance limits
What constrains governance itself?
Governance decides policy within the envelope, but is itself constrained: it cannot add capabilities outside lineage, permit safety-invariant violations, grant capabilities beyond the envelope, or introduce nondeterministic overrides. Where policy conflicts with these limits, policy loses.
Responsibilities
- Decide policy strictly within the capability envelope.
- Yield to the safety invariants whenever they conflict.
- Separate governance from mere configuration — a setting the governed can override is only advice.
Reached from
- Policy
Safety invariants
What can never be overridden?
The non-negotiable rules all execution must respect. They are declared by the kernel and are not reachable from the layers above them.
Responsibilities
- Hold the rules that no policy, identity or extension may override.
- Remain foundational rather than retrofitted from above.
Reached from
- Component
Identity overlay
How do persona and role shape behaviour without expanding power?
Role, Profile and Persona compose an Agent Definition. Role supplies responsibility and authority boundaries; Profile specialises application; Persona shapes interaction without adding authority. Runtime worker and session identity remain separate.
Responsibilities
- Shape how an agent behaves, not what it is permitted to do.
- Narrow behaviour where appropriate; never widen capability.
Reached from
- Protocol
MAX bus
How do agents communicate and stay auditable?
Agents do not call one another; they exchange typed messages over the MAX bus, which routes by role rather than by agent or vendor. Schema validation rejects malformed messages at the bus, and typed routing sends work to the role permitted to perform it.
Responsibilities
- Route messages by role — developer, reviewer, orchestrator, system.
- Reject messages that do not match the expected schema.
- Move messages through an explicit, auditable queue lifecycle.
- Enable vendor isolation: a role is the same role whichever model serves it.
Reached from
Evidence
See this exercised in a genuine recorded execution (RUN-001)Partial — recorded, unsealed and not independently verified.
- Subsystem
Coordination and audit
How is multi-agent work coordinated and recorded?
The coordination layer manages multi-agent operation through context handoff, scope isolation and audit trails. Because messages move through an explicit lifecycle rather than being consumed invisibly, the record of what was requested, by whom, and what became of it is a property of the transport.
Responsibilities
- Coordinate agents as components of one system, not isolated instances.
- Prevent conflict through scope isolation.
- Keep an audit trail of operational history.
Leads to
Reached from
- Component
Governance gate
Where is an output allowed to become an execution?
The admission point every execution passes through. It decides what an agent’s output is allowed to become, is defined before agents run, and cannot be altered from above.
Responsibilities
- Admit or reject an output before it becomes an Execution.
- Apply governance policy within the limits the kernel fixes.
- Stand between every agent output and its effect, without exception.
Reached from
Evidence
Watch a real request pass this gate (RUN-001)Partial — a genuine recorded admission through the gate, unsealed and not independently verified. The gate was advisory in this capture.
- Component
Extension model
How is DaemonCore extended without weakening it?
Extension happens through defined interfaces — custom role profiles, environment-specific boundary configurations, integration hooks. Extensions inherit the envelope’s asymmetry: an extension runs inside the ceiling and may narrow it, but nothing added later can widen what the kernel permitted at boot.
Responsibilities
- Allow domain-specific extension through defined interfaces.
- Run inside core constraints; never override safety or coordination.
Leads to
Reached from