What is the Daemion kernel?

The kernel is the core of Daemion — 6 substrates that manage AI resources, conversation state, and runtime behavior. Everything else in the system — agents, jobs, themes, commands, integrations — exists as an extension that plugs into one or more substrates. You extend the kernel; you don’t modify it.

Architecture

┌─────────────────────────────────────────────────────────┐
│                      KERNEL                             │
│                                                         │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────────┐ │
│  │  Extension  │  │   Context   │  │    Execution    │ │
│  │  Substrate  │  │  Substrate  │  │    Substrate    │ │
│  └─────────────┘  └─────────────┘  └─────────────────┘ │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐  │
│  │ Presentation │  │   Trigger    │  │   Storage    │  │
│  │  Substrate   │  │  Substrate   │  │  Substrate   │  │
│  └──────────────┘  └──────────────┘  └──────────────┘  │
└─────────────────────────────────────────────────────────┘
              ▼                    ▼
┌─────────────────────────────────────────────────────────┐
│                    EXTENSIONS                           │
│  command  theme  job  renderer  integration  action     │
│  widget   app    artifact  capability  control          │
└─────────────────────────────────────────────────────────┘

1. Extension Substrate

Registers, loads, and validates all 12 extension types at runtime. Extensions are rows in SQLite — not compiled-in modules. The system resolves them by type and name, validates them against their Zod schema, and makes them available to the rest of the kernel.

Because extensions are data, an agent can create, update, or disable an extension mid-conversation — no deploy, no restart needed. The gateway also supports reseeding (POST /reseed) to re-sync built-in extensions and disk-backed configs without restarting the process.

12 extension types: command, theme, job, renderer, integration, action, widget, app, artifact, capability, control, plus agent itself.

Source: src/gateway/storage.ts, src/schema/extension.ts

2. Context Substrate

The context substrate decides what an agent knows before it generates a response. It is RLM-inspired: rather than compressing history into summaries, context is externalized into queryable stores and the agent decides what to retrieve.

Three layers are assembled in parallel via Promise.all before each response:

Layer 1 — Recent turns (~10) pulled from SQLite. These are always in context. They represent the live thread the agent is participating in.

Layer 2 — Engram recall — semantic search (vector + BM25 hybrid) over the Neo4j knowledge graph. Entities, facts, and insights stored across sessions. The agent can also call engram_recall mid-response as a tool if it needs more.

Layer 3 — History tools — five search tools the agent calls on demand:

No running summaries. No compression. Every message is stored at full fidelity in SQLite. The agent pulls what it needs; it doesn’t get handed a lossy digest.

Source: src/gateway/agent.ts, src/core/history-tools.ts

3. Execution Substrate

Manages all Claude invocations via the Agent SDK. Responsible for model selection, turn budgets, cost limits, streaming, cancellation, and per-thread concurrency. Every chat message and job run flows through this substrate.

The substrate streams partial responses over WebSocket as text-delta events, so the UI updates token-by-token. Tool calls emit tool-start events so the client can show progress in real time.

Source: src/core/invoker.ts, src/gateway/agent.ts

4. Presentation Substrate

Renders agent output to the client. Handles streaming text, tool call visibility, error states, and artifact display. Extension renderers can register custom display components for specialized content types — a code renderer, a diff renderer, a chart renderer.

The substrate is the bridge between the Execution substrate’s stream events and what the user actually sees in the PWA.

Source: app/components/

5. Trigger Substrate

Evaluates conditions that cause jobs or agents to fire. Five trigger types are supported:

Source: src/core/triggers.ts, src/gateway/scheduler.ts

6. Storage Substrate

Three backends, each with a distinct role:

SQLite — the primary operational store. Messages, threads, extensions, projects, and job run history all live here. Zero network dependencies; the file lives at ~/.daemion/daemion.db.

Engram (Neo4j) — the knowledge graph. Entities, facts, relationships, and free-form insights. Queried via hybrid semantic + BM25 search. This is where agents accumulate long-term memory across sessions.

Filesystem — agent identity files (agents/*.yaml, agents/*/system.md), job prompts (jobs/*/prompt.md), app source bundles, and project configs. Readable at startup; hot-reloadable for agent configs.

Source: src/gateway/storage.ts

General FAQ