What is the Neural Link?

The Neural Link is a bi-directional bridge that connects AI agents directly to the Neo.mjs runtime. It lets agents inspect the Scene Graph, component state, event listeners, computed styles, and DOM rectangles, and mutate the running application in real time.

Why is Neo.mjs called an Application Engine instead of a framework?

Neo.mjs maintains persistent application objects in a worker-backed Scene Graph instead of compiling application state away into ephemeral DOM nodes. That architecture enables multi-window orchestration, runtime permutation, and deep AI introspection.

What is Context Engineering?

Context Engineering shapes the information and tool environment around AI agents. Neo.mjs implements it through Knowledge Base, Memory Core, GitHub Workflow, and Neural Link MCP servers for frontier harnesses, plus a File System MCP server for internal Neo.ai.Agent local loops.

What is the Neo.mjs Agent OS?

The Neo.mjs Agent OS is the repository Brain: source code and services for Memory Core, Knowledge Base, Active Hybrid GraphRAG, DreamService, Golden Path synthesis, A2A coordination, and Neural Link tooling.

Frontmatter

id	13893
title	[msg-ingestion] Durable message WAL + drain daemon (local + cloud parity)
state	Closed
labels	enhancementaiarchitecturemodel-experience
assignees	[]
createdAt	Jun 23, 2026, 1:17 AM
updatedAt	Jun 23, 2026, 1:21 AM
githubUrl	https://github.com/neomjs/neo/issues/13893
author	neo-opus-grace
commentsCount	1
parentIssue	null
subIssues	[]
subIssuesCompleted	0
subIssuesTotal	0
contentTrust
projected
quarantined	0
signals	[]
blockedBy	[]
blocking	[x] 13895 [msg-ingestion] Drain crash-recovery replay + idempotency + retention + observability, [x] 13894 [msg-ingestion] Switch add_message to WAL-first + remove the synchronous model-hit (durability invariant)
closedAt	Jun 23, 2026, 1:21 AM

[msg-ingestion] Durable message WAL + drain daemon (local + cloud parity)

Closed v13.1.0/archive-v13-1-0-chunk-5 enhancementaiarchitecturemodel-experience

neo-opus-grace commented on Jun 23, 2026, 1:17 AM

Parent: Epic #13889 (daemon-based A2A message ingestion). The core durable pipe.

Problem / scope

A2A messages must persist durably without a synchronous model-hit. Mirror the memory ingestion pattern: a durable append-only message WAL + a daemon that drains it → graph-persist + embed, load-aware. This is the pipe the add_message flip (sibling sub) writes into.

Acceptance Criteria

V-B-A first: confirm the current add_message persist mechanism (write-through to SQLite vs in-memory buffer) and where the durability gap is — empirical anchor: de1d9f0b (created, add_message returned an id, but absent from Nodes + GraphLog + WAL). Shape the WAL boundary from that finding.
Durable append-only message WAL (mirror memory-wal): one durable record per add_message, written before the request returns.
Drain daemon (mirror ai/daemons/embed/): drains the message WAL → graph-persist (Nodes + SENT_BY/SENT_TO/DELIVERED_TO edges; the GraphLog insert-trigger fires) → embed. Load-aware — yields to heavy maintenance (REM / KB-sync), like the embed daemon.
Local ↔ cloud parity (operator constraint, load-bearing): the daemon runs + reaches the WAL / graph / embedding-model in BOTH the local native topology AND the cloud multi-container topology, mirroring the memory embed-daemon's placement + wiring (compose service, volumes, reachability). Without this, messages persist in one reality but not the other.

Contract Ledger

Adds: the message WAL (pattern: memory-wal) + the message-ingestion daemon (pattern: ai/daemons/embed/).
Reuses: the graph persist path (GraphService.upsertNode / linkNodes), the embed pipeline.

Sequencing

First sub of #13889 — the pipe. The add_message-flip + replay/robustness subs build on it.