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	13576
title	Periodic session summarization re-loops the same sessions forever — drift count-equality never reconciles (un-paginated summarizeSession)
state	Closed
labels	bugaiarchitectureperformancemodel-experience
assignees	neo-opus-grace
createdAt	Jun 20, 2026, 2:32 AM
updatedAt	Jun 20, 2026, 4:47 AM
githubUrl	https://github.com/neomjs/neo/issues/13576
author	neo-opus-grace
commentsCount	0
parentIssue	null
subIssues	[]
subIssuesCompleted	0
subIssuesTotal	0
blockedBy	[]
blocking	[]
closedAt	Jun 20, 2026, 4:47 AM

Periodic session summarization re-loops the same sessions forever — drift count-equality never reconciles (un-paginated summarizeSession)

Closed v13.1.0/archive-v13-1-0-chunk-4 bugaiarchitectureperformancemodel-experience

neo-opus-grace commented on Jun 20, 2026, 2:32 AM

Problem

The orchestrator's periodic session-summary sweep re-summarizes the same ~9 sessions every run, indefinitely — continuous local-LLM (gemma) inference with zero progress (pending-session-summary:283 never moves). Operator-reported (2026-06-20): machine fans pinned, ~25-min back-to-back runs over an identical session set (1cf2ad9f, d13c94dd, 7a73e53f, f76d5307, 596639bf, c43c9892, af356ab3, f191cbb2, default-session).

Root cause

SessionService.findSessionsToSummarize (drift detection) flags a session for (re)summarization when its memory count ≠ the summary's recorded memoryCount (SessionService.mjs:451), assuming "once updated, the counts match, and it won't run again."

The drift computes the session count by paginating Chroma (:348-367) — the full count.
But summarizeSession writes that memoryCount from a single, un-paginated .get (:474 → :677).

Chroma caps each .get at summarizationBatchLimit (ChromaManager.mjs:333) — precisely why the drift paginates. So for sessions past that cap, summarizeSession undercounts → count !== memoryCount is permanently true → the session re-summarizes every sweep.

Bonus defect: the same un-paginated fetch means large sessions are summarized from only the first page — truncated summaries.

Evidence

get_rem_pipeline_state: 1,354 summaries ARE in Chroma (983 digested + 371 undigested) → the drift finds the summaries; it's a count mismatch, not a missing summary (rules out a persistence/Case-A theory).
#9959 (the prior "re-summarized over and over" ticket) is closed — it fixed the externally-active-session exclusion, a different cause.

Fix

Paginate summarizeSession's memory fetch (mirror the drift's pagination) → memoryCount = the true full count (reconciles with the drift) and summaries stop truncating.
Reproducing unit test: a session whose summary memoryCount < its real count must re-flag on current code and must NOT after the fix. (If the residual is a count-criteria mismatch rather than the cap, escalate to a timestamp-watermark drift signal — the summary already records timestamp: lastActivity at :677.)

Acceptance Criteria

summarizeSession fetches all of a session's memories (paginated); memoryCount equals the drift's full count.
A unit test reproduces the re-loop on current code and confirms it stops after the fix.
Large-session summaries are complete (not first-page-truncated).
Verified under UNIT_TEST_MODE (never bare npx playwright test — it resolves storagePaths.graph to the live graph).

Decision Record impact

none.

Surfaced by @tobiu (2026-06-20 orchestrator logs: same-session re-loop, fans pinned).
#9959 (closed, different cause: active-session exclusion).