What is the 'Neural Link'?

The Neural Link is a bi-directional bridge that connects AI agents (like Gemini or Claude) directly to the Neo.mjs runtime. It allows agents to 'see' the application's Scene Graph, inspect component state, verify event listeners, and even mutate the running application in real-time. This turns the application into a 'glass box' for AI, enabling autonomous debugging and feature development.

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

Traditional frameworks are general-purpose libraries (like a Toyota) that help you organize code, but they compile away into ephemeral DOM nodes. Neo.mjs is a precision-engineered runtime (like an F1 car), similar to Unreal Engine for games. It maintains a persistent 'Scene Graph' of objects in a separate worker thread. These objects retain their identity, state, and relationships, allowing for advanced capabilities like multi-window orchestration, runtime permutation, and deep AI introspection that are impossible with 'melted plastic' DOM-based frameworks.

What is 'Context Engineering'?

Context Engineering is the practice of curating the environment and information flow for AI agents to maximize their autonomy. In Neo.mjs, this is implemented via three Model Context Protocol (MCP) servers: a Knowledge Base for semantic code understanding, a Memory Core for learning from past sessions, and a GitHub Workflow server for project management. This ecosystem allows agents to work as fully integrated members of the development team.

What is 'Object Permanence' in the context of Neo.mjs?

In Neo.mjs, UI components are persistent JavaScript objects living in the App Worker, not just transient rendering results. This 'Object Permanence' means a component (like a Dashboard) maintains its state (scroll position, user input, internal logic) even if it is detached from the DOM or moved to a different browser window. This is the 'Lego Technic' approach versus the 'Duplo' approach of traditional frameworks.

What is an 'Agent Operating System'?

Neo.mjs v11 introduced the concept of an Agent OS, where the platform itself provides the tools and interfaces for AI agents to operate. It combines a standalone, type-safe AI SDK for autonomous 'Code Execution' with the Neural Link for runtime control. This enables agents to monitor, debug, and heal the application autonomously, effectively acting as an operating system for synthetic intelligence.

How does Neo.mjs handle multi-window applications?

Neo.mjs uses shared web workers to run a single application instance across multiple browser windows. All windows share the same application state and data in real-time. Components can even move between windows while retaining their JavaScript instances. This enables desktop-class experiences like multi-window IDEs, browser-based email clients, and multi-screen control rooms.

What makes Neo.mjs different from React, Angular, or Vue?

Neo.mjs is fundamentally different in its architecture: (1) It uses True Multithreading via web workers to prevent UI jank, (2) It is an AI-Native Application Engine with built-in bridges for AI collaboration, and (3) It treats components as persistent objects in a Scene Graph, enabling native multi-window support and runtime permutation.

Frontmatter

id	10956
title	Migrate Memory Core summary sweeps to daemon
state	Closed
labels	enhancementairefactoringarchitecture
assignees	neo-gemini-3-1-pro
createdAt	May 8, 2026, 1:20 PM
updatedAt	May 15, 2026, 2:47 PM
githubUrl	https://github.com/neomjs/neo/issues/10956
author	neo-gpt
commentsCount	2
parentIssue	10822
subIssues	[]
subIssuesCompleted	0
subIssuesTotal	0
blockedBy	[]
blocking	[]
closedAt	May 8, 2026, 5:57 PM

Migrate Memory Core summary sweeps to daemon

Name: Neo.mjs Application Engine
Author: Neo.mjs

Closedenhancementairefactoringarchitecture

neo-gpt commented on May 8, 2026, 1:20 PM

Context

This ticket was originally filed from the 2026-05-08 architecture correction thread as a hard removal ticket for NEO_MC_PRIMARY. That was over-broad.

Corrected operator framing from A2A MESSAGE:ed916cf2-a053-4985-9823-6f9416e2f7f6:

NEO_MC_PRIMARY is still valid today for local multi-harness MCP duplication: Claude Code worktrees, Antigravity, Codex Desktop, and per-workspace language servers can each spawn local Memory Core server instances that share .neo-ai-data/.
The remote multi-user Memory Core path is different: one remote Memory Core endpoint serves multiple authenticated agents through request-scoped identity/session context via RequestContextService and Mcp-Session-Id.
After summarization lifecycle work moves into a singleton daemon, NEO_MC_PRIMARY becomes obsolete because daemon-singleton-per-host handles the local multi-process race.

So the corrected goal is not "strip NEO_MC_PRIMARY immediately." The corrected goal is to migrate Piece B+C summarization lifecycle work into bridge-daemon.mjs or a sibling singleton daemon, then remove NEO_MC_PRIMARY as a downstream cleanup once the daemon owns the single-writer responsibility.

Duplicate / Adjacency Sweep

No focused daemon-migration ticket for Piece B+C summarization was found.

Adjacent/stale sources:

#10813 — source ticket for summary restoration; its Piece C mechanism already says to extend bridge-daemon.mjs or a sibling daemon.
PR #10954 — in-process Piece C implementation; should be reshaped or superseded toward daemon substrate.
#10948 / PR #10955 — invalid primary/secondary deployment fixture; closed/dropped correctly.
#10822 — adjacent config substrate cleanup epic.
#10186 — broader MCP concurrency / single-writer audit.

The Problem

The swarm mixed two separate concurrency problems:

Remote multi-user Memory Core: one remote MC endpoint, multiple authenticated agents, request-scoped identity/session context. This does not need primary/secondary MC containers.
Local multi-harness Memory Core duplication: multiple local MCP server processes can exist on one host and share .neo-ai-data/. This still needs a single-writer guard until lifecycle work is daemonized.

NEO_MC_PRIMARY is an acceptable interim local-process guard, but it should not remain the long-term product model. It is also easy for future agents to misread as a remote primary/secondary topology. The durable fix is daemon ownership of summarization lifecycle work.

The Architectural Reality

Current correct remote substrate:

RequestContextService owns request-scoped identity/session propagation.
Mcp-Session-Id is the transport-layer session binding for shared deployments.
Memory and summary services read RequestContextService for tenant-aware metadata and filters.

Current local interim substrate:

NEO_MC_PRIMARY gates summarization startup/queue/poller paths to avoid multiple local MCP server processes racing against shared local data.
This is still relevant before daemonization.

Target substrate:

A singleton daemon (bridge-daemon.mjs or a sibling summarization daemon) owns Piece B+C summarization triggers.
Once that daemon is authoritative, active Memory Core server instances no longer need NEO_MC_PRIMARY for summarization lifecycle writes.

The Fix

Decide whether Piece B+C belongs in bridge-daemon.mjs or a sibling daemon.
Move sunset-handover polling and periodic safety-net summarization sweep into that singleton daemon substrate.
Keep existing SummarizationJobs lease semantics if they still protect actual concurrent work execution.
Update docs so remote deployment is described as one endpoint with request-scoped context, while local duplicate MCP instances are described as a pre-daemonization concern.
After daemon ownership is in place, remove NEO_MC_PRIMARY / aiConfig.isPrimary from active Memory Core summarization paths and docs.
Reconcile #10813 and PR #10954 against the daemon substrate.

Contract Ledger Matrix

Target Surface	Source of Authority	Proposed Behavior	Fallback	Docs	Evidence
Piece B sunset handover trigger	#10813, corrected 2026-05-08 operator framing	Singleton daemon detects sunset handover events and triggers summary work	If daemon unavailable, manual `summarize_sessions` remains recovery path	`MemoryCore.md`, `SharedDeployment.md`	Unit or integration test proves daemon trigger invokes summarization once
Piece C periodic safety-net sweep	#10813 AC3	Singleton daemon runs periodic drift-detection sweep	Cadence can be disabled in dev via explicit config	`DeploymentCookbook.md` env/operator section	Test proves cadence/disabled behavior and health observability
`NEO_MC_PRIMARY` / `aiConfig.isPrimary`	Local multi-harness interim guard	Retained until daemonization; removed after daemon owns single-writer lifecycle duties	If any residual diagnostic use remains, mark it non-product-path explicitly	Remove from product-path docs after daemonization	`rg "NEO_MC_PRIMARY
Remote Memory Core deployment docs	`RequestContextService` + `Mcp-Session-Id` model	One remote endpoint serves multiple agents with request-scoped context	None; primary/secondary remote topology is stale	`SharedDeployment.md`, auth/tooling docs	Docs and tests no longer imply `mc-primary` / `mc-secondary` remote topology

Acceptance Criteria

Decision recorded: extend bridge-daemon.mjs vs create sibling summarization daemon.
Piece B sunset-handover polling is daemon-owned or explicitly routed through daemon ownership.
Piece C periodic summarization sweep is daemon-owned, configurable, and observable.
Remote deployment docs describe one Memory Core endpoint with request-scoped identity/session context, not primary/secondary MC containers.
Local multi-harness duplicate MCP process risk remains documented only as a pre-daemonization concern.
NEO_MC_PRIMARY remains only where still needed before daemonization, then is removed in the daemonization PR or a directly-linked follow-up.
#10813 is reconciled so its Contract Ledger/ACs point at daemon substrate rather than in-process primary/secondary wording.
PR #10954 is closed/superseded or reshaped to match the daemon substrate.
#10945 remains with only valid children; #10948 stays closed invalid.

Out of Scope

Reopening #10948 or reviving mc-primary / mc-secondary deployment tests.
Removing SummarizationJobs lease semantics without proving they are redundant.
Changing OIDC/proxy identity behavior.
Closing #10186 globally.

Avoided Traps / Gold Standards Rejected

Rejected: immediate NEO_MC_PRIMARY removal. It still protects local multi-harness duplicate MCP processes until daemonization.
Rejected: remote primary/secondary Memory Core topology. Remote multi-user MC is one endpoint with request-scoped context.
Gold standard: daemon-owned lifecycle work. Summarization triggers belong in a singleton daemon substrate, not every MCP server process.
Gold standard: sequence the cleanup. First daemonize Piece B+C; then strip the now-obsolete process-role gate.

#10813 — source summary-restoration ticket; needs reconciliation.
PR #10954 — in-process Piece C implementation; reshape/supersede incoming.
#10948 / PR #10955 — invalid primary/secondary deployment test path.
#10945 — deployment-pipeline integration coverage epic.
#10822 — config substrate cleanup epic.
#10186 — broader MCP concurrency / single-writer audit.
A2A: MESSAGE:ed916cf2-a053-4985-9823-6f9416e2f7f6.

Origin Session ID: c02fbf4e-870c-44c0-ba7e-e9ffacce094b

Retrieval Hint: query_raw_memories(query="NEO_MC_PRIMARY local MCP server instances daemon summarization bridge-daemon RequestContextService remote Memory Core")

tobiu referenced in commit 058cd5b - "feat(memory-core): migrate summary sweeps to daemon (#10956) (#10967) on May 8, 2026, 5:57 PM

tobiu closed this issue on May 8, 2026, 5:57 PM