MemSidecar Architecture: Event-Hooked Memory Delivery, Speculative Prefetch Caches, and Taking Memory Scheduling Off the Agent's Critical Path

AGENT SYSTEMS

Agents pause mid-task to remember. MemSidecar moves the scheduling of memory out of the task loop: LLM-written condition hooks deliver memories when execution state matches, and a foresight agent prefetches predicted queries into a task-scoped cache. The result is better task scores at lower latency and token cost.

By Ossam Hashim

KEY FINDINGS

• In the standard on-demand pattern, the main agent itself must notice a memory need, build a query, and wait for retrieval while the task stalls; repeated access puts demand identification and retrieval waits directly on the critical path.
• MemSidecar splits memory into two layers: Global Memory holds cross-task knowledge and user preferences, while Workspace Memory tracks skills, experience and task state inside one workspace.
• Hooks mode binds memory entries to LLM-generated condition functions evaluated against execution events, state and pending actions; when a condition holds, the memory arrives without the agent asking.
• Foresight mode runs an independent memory agent that predicts likely queries from the initial instruction and a memory topic directory, retrieves in parallel with execution, and serves matching results from a task-scoped cache after a validity check.
• On MCP-Persona, a checkpoint-scored benchmark over stateful personal-app simulators, Hooks scores 41.23% overall and Foresight 44.34%, against 36.53% for the strongest on-demand scheduling baseline and 29.49% for Mem0 (authors' reported results).
• The efficiency story matches the accuracy story: Hooks runs 82.5 seconds per task versus the baseline's 147.3 and retrieves 1.72K tokens versus 3.69K, so the scheduling win is not bought with more context.

The Wait Hidden Inside Every Agent Loop Long-horizon agents live on continuity: budgets set three sessions ago, resources chosen yesterday, dependencies still unresolved. Memory research has concentrated on what to store and how to retrieve it. The question this paper, from Nanjing University and Northeastern University, isolates is when retrieval happens and who initiates it. In the prevailing on-demand interface, the answer is the main agent, inside its task loop, at the moment it notices a gap. That placement has two costs the paper names precisely. First, waiting: retrieval latency lands on the critical path, because the agent cannot act on a memory it is still fetching. Second, coverage: a query built from the current instruction misses constraints and dependencies that live in earlier sessions and are phrased nothing like the present step. The paper's motivating example is a hotel-booking task resumed across sessions, where retrieval never fires, fires late, or fires with an incomplete query, and the stored budget simply never reaches the decision it was meant to constrain.

Hooks: Memory That Arrives Unasked The first mode inverts the initiation. When a memory is stored or a task starts, an LLM generates a condition function binding that memory to executable checks, and the runtime evaluates these conditions against the current event, the execution state, or the pending action. When a condition holds, the bound memory is delivered to the main agent directly, without the agent constructing or issuing a query. In systems terms, Hooks is a trigger layer over the memory store: declarative conditions, event evaluation, push delivery. This is what removes the coverage failure for standing constraints. A budget written to Global Memory weeks earlier is not something a resumed task will spontaneously query for; bound to a condition over booking actions, it surfaces exactly when a decision approaches. The paper reports that Hooks shows the flattest performance curve across task stages, consistent with constraints arriving steadily instead of in one retrieval burst.

Foresight: Prefetching the Memory You Will Need The second mode attacks latency with speculation. An independent memory agent reads the initial instruction and a directory of memory topics, predicts the queries the task is likely to issue, retrieves them in parallel with execution, and parks the results in a task-scoped cache. When the main agent does issue a request, matching and still-valid results serve from the cache instead of a fresh retrieval round trip. The design acknowledges its own risk: predicted queries can be wrong or go stale, so delivery requires a match and a validity check. The analogy to instruction prefetch is apt and the paper earns it: Foresight achieves the highest pass rate at every task stage, and its 109.7 seconds per task still undercuts the on-demand baseline's 147.3. As with the retrieval infrastructure this blog covered in the LEANN analysis, the gains come from doing storage work before the request exists.

What the Numbers Say On MCP-Persona, which scores checkpoint completion across stateful simulators for collaboration, content, social and email applications, the memory baselines cluster low: Mem0 at 29.49% overall, A-Mem at 25.00%, LightMem at 32.18%. Agent harnesses with on-demand scheduling do better, with DSH at 36.53%. Hooks reaches 41.23% and Foresight 44.34%, while cutting store tokens roughly in half against Mem0 and cutting retrieve tokens from 3.69K to 1.72K and 2.29K respectively. Ablations show both memory layers contribute: retaining only Workspace memory yields 38.67%. All figures are the authors' reported results.

Assumptions and limitations

All scores, token counts and runtimes are the authors' reported MCP-Persona results; this analysis did not independently re-run the benchmark. The benchmark's stateful simulators approximate, but are not, production personal applications. Hooks depends on LLM-generated condition functions, whose failure modes (over-triggering, under-triggering) the paper measures only in aggregate. Foresight's cache validity policy is described but its staleness bounds are not formally characterized. The worked example is a simplified latency model, not the paper's evaluation.

Worked Example: The Prefetch Wager

This toy simulates the latency wager behind Foresight: a 12-step task needs memory at three points, retrieval costs 2 seconds, and a prefetcher predicts needs with a given hit rate. Expected waiting time, averaged over 200 tasks, shows how imperfect prediction still beats serial fetching.

import random
random.seed(5)
r = random.random
RETR = 2.0
def run(hit):
    tot = 0.0
    for _ in range(200):
        w = 0.0
        for s in (2, 5, 9):
            if r() > hit:
                w += RETR
        tot += w
    return tot / 200
w0 = run(0.0)
w7 = run(0.7)
w9 = run(0.9)
print("on-demand:", w0)
print("prefetch@70:", round(w7, 2))
print("prefetch@90:", round(w9, 2))

Sources & Provenance

• MemSidecar paper (arXiv, October 31, 2026) - architecture, modes, MCP-Persona results
• MemSidecar full text (HTML) - tables, ablations, stage-wise analysis

Analysis is based on the primary sources listed above; benchmark claims are attributed to their authors and not independently verified.