Governance layer / in development

Govern autonomous AI.
Without taking autonomy away.

DaemonCore is a software platform for teams building AI agents that take action. It gives agents defined responsibilities, checks proposed actions against permissions and policy, and records decisions and outcomes along configured execution paths.

Follow an example Discuss your use case
Enter the system

Illustrative example · not a runtime recording

A code review, from request to record.

Follow one task from request to decision. The agent chooses how to work; the configured governance boundary determines which actions may proceed.

  1. A team requests a code review

    Review a proposed change and report your findings. The reviewer can read this project, but cannot change files or deploy it.

  2. The agent proposes an action

    The reviewer asks to read a project file. Its request carries the task, its identity and the proposed action.

  3. DaemonCore checks the permission

    On the configured execution path, the request is checked against the reviewer’s role, project scope and policy before it proceeds.

  4. The boundary changes what happens

    Reading the permitted file is allowed. A proposed deployment is rejected because it exceeds this reviewer’s authority. This example assumes enforcing mode and tools connected to that boundary.

  5. The team can inspect the record

    The record connects each request to its actor and decision. Execution results are separate: allowing a read does not, by itself, prove the review finished.

Want the recorded evidence? Inspect RUN-001’s admission trace. That capture ran in advisory mode, with no model execution or blocked action.

For developers building agent workflows and platform teams responsible for their permissions and audit trail. See where DaemonCore fits or inspect a recorded admission.

01 / THE MISSING LAYER

AI agents don’t just answer.
They act.
Instructions alone are not authority.

Orchestration decides what to do. Governance determines whether it is allowed. DaemonCore connects external authority and policy directly into the agent’s operating context, enforces boundaries around execution, and preserves evidence of what happened — without removing the autonomy that makes agents useful.

Why instructions alone aren’t governance

A task enters an agent operating context alongside external authority and policy. The autonomous agent proposes an action. DaemonCore evaluates it at an enforcement boundary. An admitted action becomes governed execution and retains an execution trace; a rejected action stops at the boundary.

02 / THE OPERATING IDENTITY

An agent does not simply wake up
and start working.

DaemonCore resolves a governed definition, applies the project binding and policy constraints, then selects an eligible runtime worker and assembles its operating context.

Architectural model · illustrative, not a live boot trace

01 / Definition resolves

01

Definition resolves

Role, Profile and Persona form a governed definition: responsibility, operating posture and interaction — never permission.

02

Authority is bounded

The Role establishes the authority ceiling. Policy and safety controls can only narrow what the system permits.

03

Project binding activates

The definition is placed in project scope with its local restrictions, routing and effective operating selection.

04

Worker eligibility resolves

Candidate workers are evaluated by host, adapter, model, runtime profile and available capabilities against the established identity and authority bounds.

05

Operating context assembles

Kernel, vendor, project and resolved-definition material settle into the context from which governed work can begin.

03 / OBSERVABLE OUTPUT

RUN-001 · RECORDED · PARTIAL

The system becomes
something you can inspect.

A genuine recorded run of the DaemonCore runtime: a code_review_request published under an established identity, admitted through the governance gate and recorded as an Execution.

RUN-001 / RUNTIME LOGGOVERNANCE.GATE / ADVISORY
TRACE IDENTIFIEREVID-e9b58172EXECUTIONexec-a41c2c95cbc8
[INFO] [Enforcement] Config loaded: mode=advisory, strict_domains=(), threshold=10
[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
[INFO] [MaxBusBridge] Dispatched EVID-e9b58172 -> execution exec-a41c2c95cbc8 (admission only; outcome pending)
ADMITTED / OUTCOME PENDINGReplay the evidence

RUN-001 is partial: admission was recorded, but no model executed; the gate was advisory and the recording has not been independently verified. The full illustrative walkthrough (GOV-001) is on the Proof page.

04 / CONTROL, MADE EXPLICIT

Different responsibilities.
One governed system.

01

Authority

A Role establishes responsibility and its authority ceiling. Profile and Persona cannot expand it.

02

Boundaries

Project and policy constraints narrow the permitted operating scope.

03

Communication

Structured messages make the sender, intended work and receiving role inspectable.

04

Execution decisions

Admission and execution outcome are separate states. The configured enforcement mode matters.

05

Evidence

Inspect what was captured, what it supports and what remains unproven.

05 / SYSTEMS OF AGENTS

More agents.
Still accountable.

Work can move between agents without confusing their responsibilities. A shared project does not give every worker the same authority.

Independent review requires a genuinely independent actor. Changing a label does not change who performed the work.

Explore identity and communication
Illustrative network · shared boundaries, distinct actors

06 / CHOOSE A DEPTH

Continue from the layer
you need to inspect.

01Building agents?Developers ↗ 02Designing secure platforms?Architecture ↗ 03Evaluating the claim?Proof ↗

07 / THE THINKING BEHIND THE SYSTEM

A closer look.

Evidence / Execution

Admission is not completion

What a partial execution trace can establish — and why the missing outcome matters.

Read the perspective ↗Architecture / Authority

Authority is not a prompt

Instructions describe what an agent should do. Authority defines what it is permitted to do.

Read the perspective ↗

NEXT / START A CONVERSATION

Building something that needs
governed autonomy?

Discuss your use case

Met us at Web Summit? Tell us what your agents need to do, and where you need a clear boundary.