MemTools: Giving AI Memory Systems a 'USB-C Port'
The Scenario: An Awkward Reality in the Lab
Imagine you're doing memory system research. You read a new paper proposing a cool memory formation module — one that extracts key information from conversations and stores it as structured "experience entries." You want to plug this module into your own memory retrieval system and see how the combination performs.
Then you open the code and discover: the module's input format is {"user_msg": ..., "response": ..., "timestamp": ...}, while your retrieval system expects {"query": ..., "context": ..., "session_id": ...}. Different field names, different data structures, different calling conventions. You spend two days writing adapters, then realize rewriting from scratch would have been faster.
This is not an isolated case. This is daily life in agent memory research from 2024 to 2026. A team led by Chengfeng Zhao at the Institute of Automation, Chinese Academy of Sciences decided to stop tolerating the situation. They built a framework called MemTools, described in a paper published on arXiv on July 23, 2026 (2607.21404). Its purpose in one sentence: give AI memory systems a standard interface so components from different systems can be interchanged.
The Problem: A Warring-States Era for Memory Systems
To understand why MemTools matters, you first need to see the problem it tackles.
Current agent memory research is bustling. From Packer et al.'s 2024 work to systems like A-Mem, AWM, and MemGPT, each has its own innovations in memory formation, storage, retrieval, or evolution. The problem: these systems are completely incompatible with each other.
The paper summarizes three layers of "architectural entanglement":
1. Lifecycle-stage coupling: Memory formation, storage, retrieval, evolution, and utilization are typically packaged inside one closed codebase. Want to lift a system's retrieval module and reuse it elsewhere? Sorry — it's deeply bound to that system's storage backend and can't be extracted.
2. Evaluation-protocol entanglement: Evaluation pipelines are usually hardwired to specific datasets. Want to use AWM's evaluation protocol on A-Mem's memory module? You first have to strip the protocol out of AWM's dataset — but the protocol code is riddled with dataset-specific hardcoding.
3. Heterogeneous memories cannot be coordinated: Some memories are symbolic (vector databases, relational graphs), some are neural (encoded directly into model weights or hidden states), some are multimodal (images, audio). Existing frameworks typically support only one representation; coordinating symbolic and neural memories means starting from zero.
Sound familiar? It's like the computer peripherals market before USB — every mouse, keyboard, and printer had its own connector, and adapters outnumbered devices.
MemTools' Solution: Declarative Data Contracts
MemTools' core design idea boils down to one phrase: declarative data contracts.
The concept is simple. Think of a USB-C port — it doesn't care whether you plug in a hard drive, a monitor, or a charger; it only defines a standard set of pins and data protocols. If your device declares "I need 5V power and USB 3.0 signaling" and the port can supply them, they pair successfully.
MemTools does exactly the same. Every memory component explicitly declares two things:
- requires_keys: which data fields it needs to operate
- provides_keys: which data fields it will output after execution
- Batch protocol: all trajectories processed collectively, memory formed in one go. Success rate: 40.30%
- Stream protocol: memory formation interleaved with task execution. Success rate: 33.58%
The framework validates automatically at initialization: does the upstream component's provides_keys cover the downstream component's requires_keys? If yes, they pair; if not, it blocks with an error.
For example, a retrieval module that requires text_embedding_index will only pair with a storage backend capable of producing dense embeddings. A memory formation module requiring raw text won't accidentally be connected to a backend that only outputs image embeddings.
This design makes "mix-and-match" possible. You can combine AWM's memory formation module, A-Mem's retrieval and backend modules, and a custom utilization module into a brand-new memory pipeline — as long as the data contracts match.
Three Experiments: Mixing, Decoupling, Coordinating
The paper demonstrates the framework's utility with three experiments.
Experiment 1: Cross-System Component Integration
The researchers combined AWM's memory formation module with A-Mem's backend + retrieval modules and tested on ALFWorld, a text-based world task environment. Result: the mixed pipeline achieved a 43.28% success rate, beating the native AWM pipeline.
This result speaks for itself — the best components from different systems, combined, outperform either complete system. But before this, nobody could run such an experiment, because the components couldn't be extracted at all.
They also analyzed the causes of pairing failures: dataset-to-formation alignment failures 37.0%, memory retrieval 23.9%, backend storage initialization 20.1%, utilization stage 19.0%. Data structure mismatch is the primary obstacle to cross-system integration — exactly what MemTools' data contracts solve.
Experiment 2: Decoupling Evaluation Protocols from Datasets
This experiment's design is elegant. Using the exact same AWM memory pipeline and ALFWorld dataset, the researchers changed only the timing of memory operations in the evaluation protocol:
Experiment 3: Heterogeneous Memory Coordination
Symbolic memories (vector databases), neural memories (model weights / hidden states), multimodal memories (images, etc.) — these three representations previously fought separate wars. MemTools wraps each representation as an independent pipeline sharing the same lifecycle interface, coordinated by a unified MultiSystem layer.
On query, the coordinator concurrently dispatches requests to all active memory subsystems, aggregating textual records, visual context, and neural activation patterns. During utilization, chained adapters apply retrieved content to the language model.
Experiments show heterogeneous memory coordination yields complementary performance gains — different representations genuinely capture different dimensions of information.
An Honest Statement of Limitations
The paper doesn't shy away from the framework's limitations. Two main issues:
1. Structural compatibility is verified, but not behavioral compatibility. Data contracts confirm that field names and types match, but two components can still be semantically incompatible — e.g., a retrieval module expecting short queries versus one optimized for long contexts. Contracts cannot detect such "behavioral misalignment."
2. The abstraction layer adds computational overhead. To achieve modularity, MemTools introduces extra interface layers and validation logic, incurring performance costs in evaluation loops. The paper candidly states the current implementation is "optimized for controlled research environments" and may hit bottlenecks on large-scale heterogeneous databases and very long task trajectories.
This is honest engineering assessment. MemTools is not a production tool — it's a research tool. Its goal isn't to be fastest, but to make "comparing different memory components" possible at all.
Why This Matters
Beyond the paper itself, MemTools addresses a more general problem: when a field develops rapidly and system architectures are highly fragmented, how is comparative research even possible?
The memory systems field today resembles the BERT-variant era of 2017–2019 — every paper had its own architecture, its own evaluation, its own dataset, and cross-paper comparison was nearly impossible. Later, the GLUE and SuperGLUE benchmarks at least provided comparability at the evaluation level. But memory systems are far more complex than text classification, because they involve a complete pipeline (formation → storage → retrieval → evolution → utilization), not just a single model.
MemTools' contribution is pipeline-level decomposability. You can compare not only "System A vs System B," but "System A's retrieval module vs System B's retrieval module," "Batch protocol vs Stream protocol," "symbolic memory vs neural memory." This granularity of comparison is the precondition for moving the field from "everyone builds their own wheel" toward "accumulating consensus."
A Closing Analogy
MemTools can be summarized with a simple analogy:
Memory systems used to be like restaurant kitchens — each with its own workflow, containers, and recipes. Want to combine Restaurant A's broth, Restaurant B's seasonings, and Restaurant C's plating into a new dish? You'd first have to convince three kitchens to adopt the same pots and pans.
MemTools is that unified standard of pots and pans. It doesn't tell you how to cook; it only specifies the pot diameter and the rim shape of the bowl. Once everyone adopts the standard, mix-and-match becomes a matter of turning a few screws.
This is not a revolutionary algorithmic breakthrough, but it is a sign of a maturing field. When a field starts caring about "interface standardization" rather than "yet another new system," it is moving from a period of wild growth into an accumulation phase.
For people doing agent memory research, MemTools may be more useful than any new algorithm — because it finally lets you run experiments that were previously impossible.
---
Paper link: https://arxiv.org/abs/2607.21404 HTML version: https://arxiv.org/html/2607.21404v1 Authors: Chengfeng Zhao, Jinhui Chen, Sirui Liang, Shizhu He, Yequan Wang, Jun Zhao, Kang Liu Institutions: Institute of Automation, Chinese Academy of Sciences; Beijing Academy of Artificial Intelligence; Zhongguancun Academy of Artificial Intelligence