MemSidecar puts AI memory retrieval on a separate track

Remembering is also a scheduling problem

An AI agent handling a multi-step assignment needs more than a record of previous conversations. It must recover the right information before making a decision: an earlier budget before booking travel, or a message identifier before reacting to a newly posted notice.

In the research preprint Who Schedules Agent Memory? A Sidecar Approach to Long-Horizon Tasks, Qijia Zhuang, Rui Liu and Yuxiang Ren propose MemSidecar. Their central argument is that memory performance depends not only on what gets stored, but also on who decides when to retrieve it. The reported findings are preprint results, not established evidence of general reliability.

In a conventional on-demand workflow, the main agent identifies a memory need, constructs a query and waits for retrieval. That adds work to the same execution path responsible for completing the task. It also creates an opportunity to miss historical constraints that the current instruction does not explicitly repeat.

Two ways to prepare context

MemSidecar separates memory scheduling from task execution through two independently selectable modes.

Hooks attaches executable conditions to particular memory entries. These conditions are generated by a language model and checked against visible context or a proposed action. When one matches, the associated memory is delivered directly, without the main agent first requesting it. A project convention to run tests before deployment, for example, could be supplied when a deployment action is proposed. The agent can then revise that action. Each Hook delivers at most once per task in the evaluated configuration.

Foresight uses a separate agent to predict likely memory queries from the task instruction and a directory of available memory topics. It retrieves results in the background while the main agent works, then keeps them in a task-level cache.

Foresight does not eliminate the main agent’s memory requests. When an actual query arrives, a language model checks whether it matches a predicted need. A ready, valid result can be returned from cache; an unfinished matching retrieval still requires waiting. Requests without a usable match follow normal retrieval. The intended benefit is overlapping preparation with useful work, not guaranteeing instant access.

Both modes share two memory layers. Global Memory contains reusable knowledge and user preferences. Workspace Memory holds project procedures, experience, current progress and artifacts. This distinguishes a standing constraint from the changing state of a particular assignment.

What the benchmarks showed

The authors evaluated the standalone modes on MemoryArena and MCP-Persona, using GPT-5.4-mini for task execution and Qwen3-8B for memory management, retrieval and prediction. Compared methods received the same task inputs, tools and execution budgets within each dataset.

MCP-Persona contains 173 tasks with 724 checkpoints in simulated personal applications. Hooks achieved an overall checkpoint score of 41.23%, and Foresight reached 44.34%. The strongest external baseline overall, DSH, scored 36.53%. These percentages measure checkpoint performance, not the proportion of complete assignments successfully finished.

Reported runtime per task was 82.5 seconds for Hooks and 109.7 seconds for Foresight, compared with 147.3 seconds for DSH. Hooks also used fewer tokens in the paper’s memory-maintenance and retrieval accounting. Here, Foresight produced the higher score, while Hooks finished faster.

MemoryArena covers dependent, multi-session tasks in shopping, travel, web search and reasoning. Foresight’s complete-task success rate reached 48.33% in reasoning, but only 4.81% in travel planning. Hooks reached 43.33% and 3.70%, respectively. Improvements therefore did not translate into consistently reliable completion across task types.

Evidence for scheduling—and its limits

Removing either memory layer reduced scores in both modes. A separate comparison held the dual-layer backend fixed while changing access and scheduling policies. Hooks and Foresight still achieved higher scores with fewer retrieval tokens and shorter runtimes than the compared Mem0 and DSH policies. This supports the authors’ scheduling argument beyond differences in storage alone.

Additional retrieval also improved baseline scores, but substantially increased their retrieval tokens and runtime. Simply asking memory more often was not equivalent to the reported sidecar tradeoff.

Important limits remain. The experiments use a specific executor, memory model, retrieval configuration and benchmark environments; they do not establish performance across arbitrary models or live applications. The reported tables provide no uncertainty intervals. Token accounting covers specified memory operations rather than a complete monetary cost calculation.

The practical takeaway is narrower than solving agent memory: preparing and delivering stored information at useful moments can improve these evaluated workflows. Predicting the right need, matching it correctly and completing difficult tasks remain unresolved challenges.