Context
Memory Core add_memory embeds each memory via the configured embedding provider (default openAiCompatible / LM Studio, text-embedding-qwen3-embedding-8b). The same embedding model is also driven by batch maintenance — notably the Knowledge Base sync (ProcessSupervisor "knowledge base sync", processed in ~10 embedding batches, ~5 min/batch observed). LM Studio / the openai-compatible host serializes requests to a model, so a long batch monopolizes the embedder.
The Problem (V-B-A'd, 2026-06-04, 2-family corroborated)
While a KB-sync embedding batch runs (operator log: "Processed and embedded batch 5 of 10"), interactive add_memory queues behind the batch and times out (MCP error -32001: Request timed out, 3× — @neo-opus-grace and @neo-opus-ada same-window).
Decisive evidence it's the EMBEDDING path, not the MC server: add_message (no embedding) succeeded throughout the same window while add_memory (embeds) timed out. healthcheck reported healthy (it doesn't probe the embed-write path — the write-side analog of #12450's missing query-canary).
This breaks the AGENTS.md §0 Invariant 5 ("No skipping add_memory at end of turn") whenever heavy embedding maintenance overlaps an agent turn — exactly the nightshift windows where memory persistence matters.
Prior art (resilience lineage — neither covers this)
- #11393 (CLOSED) —
add_memory retry-on-model-unload (LM Studio JIT-unloads idle models → retry reloads). Covers the idle-unload case; the model here is loaded and busy, not unloaded.
- #12090 (CLOSED) — provider multi-model coexistence (
requireParallelModels). This is single-model request contention (batch vs interactive on the same embedding model), not multi-model.
So the batch-contention failure mode is genuinely un-covered: "interactive add_memory gets priority and still works" (the operator's stated invariant) does not hold under a heavy batch.
Fix direction (mechanism TBD — needs design, likely operator-steered)
Interactive add_memory needs priority / QoS over batch KB-sync embedding. Candidate mechanisms (to evaluate, not yet chosen):
- Batch KB-sync yields the embedder to interactive requests (throttle / chunk-with-gaps / pause-on-interactive).
- A priority lane at the embed-request layer (interactive ahead of batch).
add_memory resilience covers contention (longer/queued retry with priority), extending #11393's retry-on-unload to retry-on-contention.
A Memory Core restart is not a fix (the batch resumes / recurs).
Acceptance Criteria
Related
#11393 (idle-unload retry), #12090 (multi-model coexistence), #12450 (healthcheck query-canary — this is the write-side analog). Heavy task: ai/daemons/orchestrator ProcessSupervisor KB-sync.
Origin Session ID: 3ecb40bf-bfef-40b1-8693-a8aae5afa1b7
Authored by Claude Opus 4.8 (Claude Code), /lead-role.
Context
Memory Core
add_memoryembeds each memory via the configured embedding provider (defaultopenAiCompatible/ LM Studio,text-embedding-qwen3-embedding-8b). The same embedding model is also driven by batch maintenance — notably the Knowledge Base sync (ProcessSupervisor"knowledge base sync", processed in ~10 embedding batches, ~5 min/batch observed). LM Studio / the openai-compatible host serializes requests to a model, so a long batch monopolizes the embedder.The Problem (V-B-A'd, 2026-06-04, 2-family corroborated)
While a KB-sync embedding batch runs (operator log: "Processed and embedded batch 5 of 10"), interactive
add_memoryqueues behind the batch and times out (MCP error -32001: Request timed out, 3× — @neo-opus-grace and @neo-opus-ada same-window).Decisive evidence it's the EMBEDDING path, not the MC server:
add_message(no embedding) succeeded throughout the same window whileadd_memory(embeds) timed out.healthcheckreported healthy (it doesn't probe the embed-write path — the write-side analog of #12450's missing query-canary).This breaks the AGENTS.md §0 Invariant 5 ("No skipping
add_memoryat end of turn") whenever heavy embedding maintenance overlaps an agent turn — exactly the nightshift windows where memory persistence matters.Prior art (resilience lineage — neither covers this)
add_memoryretry-on-model-unload (LM Studio JIT-unloads idle models → retry reloads). Covers the idle-unload case; the model here is loaded and busy, not unloaded.requireParallelModels). This is single-model request contention (batch vs interactive on the same embedding model), not multi-model.So the batch-contention failure mode is genuinely un-covered: "interactive
add_memorygets priority and still works" (the operator's stated invariant) does not hold under a heavy batch.Fix direction (mechanism TBD — needs design, likely operator-steered)
Interactive
add_memoryneeds priority / QoS over batch KB-sync embedding. Candidate mechanisms (to evaluate, not yet chosen):add_memoryresilience covers contention (longer/queued retry with priority), extending #11393's retry-on-unload to retry-on-contention.A Memory Core restart is not a fix (the batch resumes / recurs).
Acceptance Criteria
add_memorycompletes (does not time out) while a heavy KB-sync embedding batch is running — the §0 gate holds during heavy maintenance.healthcheckgains an embed-write canary so this degradation is not silently "healthy" — coordinate with / fold into #12450's query-canary AC.Related
#11393 (idle-unload retry), #12090 (multi-model coexistence), #12450 (healthcheck query-canary — this is the write-side analog). Heavy task:
ai/daemons/orchestratorProcessSupervisor KB-sync.Origin Session ID: 3ecb40bf-bfef-40b1-8693-a8aae5afa1b7 Authored by Claude Opus 4.8 (Claude Code), /lead-role.