MIA: an agent memory framework built on Manager, Planner and Executor

Three roles instead of one memory

MIA stands for Memory Intelligence Agent, and it is described as a memory framework designed for deep research agents, developed by a joint team from the Shanghai Institute of Intelligence and East China Normal University.

The problem it sets out to attack is stated at length in the project description, and it is worth reading because it defines the design. The complaint is about agents that understand everything but remember nothing, about diluted attention in a sea of long-form text, about reasoning failures caused by noisy and irrelevant memories, about memory crippled by rising computational cost and ever-growing context histories, and above all about an agent that memorises what the result is while failing to learn how to get there. The summary of the diagnosis is a specific failure mode: an incompetent Planner retrieving memories from bloated memory and using non-comprehensive in-context prompts to guide an unprepared Executor in conducting deep research.

The response is to split the memory handling into three named roles. The Manager is an ultimate librarian that optimises memory storage to eliminate bloat. The Planner is a tactical brain that does not just recall, but evolves its strategy through Continual Test-Time Learning. The Executor is a precision instrument that interprets and follows complex research blueprints with zero friction.

The claim attached to that split is that it replaces the memory dump with a Manager-Planner-Executor architecture, turning agents from passive record-keepers into active strategists. Whether the naming is the achievement or the packaging is arguable, but the division of labour is a real design decision, and the three roles map onto three separable pieces of work: what to keep, what to do next, and how to do it.

Two kinds of memory and a loop between them

The first key highlight is described as a move from growth to evolution. MIA moves beyond ever-growing contexts to strategy-oriented wisdom, and it does so by establishing a collaborative loop between parametric and non-parametric memories, so that agents autonomously evolve in complex, open-world scenarios.

The distinction between the two memory kinds is doing real work in the design. Non-parametric memory is the store you can read and write, the notes, the documents, the retrieved snippets. Parametric memory is what the model itself has absorbed. A loop between them means the agent can write a distilled lesson back into its weights as well as into a store, and can read a retrieved memory to change how it acts, rather than only adding to the context window.

The second highlight is that the framework breaks the stagnation of static memory through an Alternative Reinforcement Learning paradigm, so that the Manager, Planner and Executor act as one cohesive mind and achieve fluid multi-agent cooperation that prior works lack.

The third is the one that changes the runtime story. Unlike static models, MIA features Continual Test-Time Learning, which allows the Planner to adapt and optimise its research strategies on the fly during inference. That is the difference between a memory system that is consulted and a strategy that is revised, and it is why the project is about research agents specifically: an agent that spends many tool calls on a hard question is an agent that can learn something about how to spend them.

A research stack, not a package

The repository layout makes clear what kind of artefact this is. The top level holds Executor-Train, Planner-Train, TTRL, TTRL-streaming, Inference, Memory-Serve, Serve, web_tools, and the English and Chinese readme directories.

Read the names as a pipeline. There is a training directory for the Planner and one for the Executor, a TTRL directory and a separate TTRL-streaming directory, an Inference directory, and two serving directories that appear to correspond to the memory component and the agent service itself. The project page confirms the shape of it, announcing on 2026-04-01 that the full stack is here, with the whole training and evaluation codebase, models and datasets published.

What is missing is as informative as what is there. There is no setup.py, no pyproject.toml, no install instructions, no package index entry and no release tags, so this is not something you pip install and call. The primary language recorded for the repository is Python, and the README badge states Python 3.10 or newer, but the actual entry point is the paper and the directories.

For an adopter, the practical consequence is that the code is read in the directories that match each role in the system. If the goal is only to run the thing, the OpenClaw skills are the shortest path. If you want to retrain the Planner, the Planner-Train directory is where the work is. If you want to serve it, Memory-Serve and Serve are the relevant pieces, and the Inference directory is where inference code lives.

Two search backends, one online and one offline

The tools section documents two text search backends, and the split between them is the interesting part.

The online text search tool has its core implementation mainly in web_tools/server, and it is configured through a script. You open web_tools/run.sh, set the Google Search Serper key in the environment using a value from a Serper account, and then start the service with:

cd web_tools
bash ./run.sh

The service exposes a base path for the server and a search method under it, both built from the service URL.

The offline text search tool has its core implementation mainly in local_search, and the setup instructions point at another project, search-r1, for the details. So the offline path is not self-contained in this repository, it is a pointer to work done elsewhere.

That distinction matters for a research agent. A deep research agent is a loop of search, read and reason, and the search backend determines both the quality of the evidence and the cost of the run. The online backend with a commercial search key gives fresh web results at a per-query price, and the offline one gives a local corpus with no per-query cost and no freshness, at the price of building the index.

The tool directories are therefore where a reader should look before deciding which backend to run.

The reported results and what they rest on

The performance section is written in the project's own voice, and it is worth separating the structure of the claim from its emphasis.

The evaluation spans multiple benchmarks, with two families of result. On LiveVQA, which is multimodal, and HotpotQA, which is text-only with a sandbox based wiki search, the project reports that MIA significantly boosts the performance of current state of the art large language models, naming GPT-5.4, Gemini-3-Flash and claude-sonnet-4.6, and the claim is that this works in both text and complex multimodal reasoning tasks.

The second family is the small to great result. Using a Qwen-2.5-VL-7B based Executor, the project reports that MIA enables this 7B model to improve across 7 diverse datasets, and that the MIA-enhanced 7B model outperforms closed-source general models, specifically GPT-5.4, GPT-4o and Gemini-2.5-Pro in non-tool-calling settings, reaching performance close to that of Gemini-3-Flash in non-tool-calling settings.

The third is the memory comparison. Benchmarked against contemporary state of the art agent memory frameworks using a unified Qwen-2.5-VL-7B Executor, MIA is reported to achieve top-tier results across all 7 datasets.

Two things follow. The repeated qualifier of non-tool-calling settings is doing important work in the small model comparison, since a tool-calling model is a different proposition from a model answering from a retrieved context. And the whole small-model story depends on the specific 7B Executor, so the numbers do not transfer to a different base model without re-running the evaluation. The paper is on arXiv at 2604.04503, and the code, models and datasets are published alongside it.

Checkpoints, datasets and a downloadable skill

For a project that is mostly research artefacts, the distribution channels matter more than usual, and the project publishes on several.

On Hugging Face there are the MIA models under LightningCreeper/MIA, the MIA datasets under LightningCreeper/MIA, and lightweight FP8 Executor checkpoints in a tree named Executor-FP8-BLOCK. The FP8 checkpoints are the interesting ones for deployment, because a 7B model in FP8 is a materially different thing to run than the same model in full precision, and shipping them is what makes the small model claim usable on a single machine.

The OpenClaw side has two skills, an original version and a trust-worthy version, both on Clawhub, and the trust-worthy one adds a judgement mechanism on top of the memory framework. There is also reference code for training the Planner model based on online-talking with the OpenClaw bot, published in a separate repository, which suggests the intended workflow is to fine-tune a Planner on conversations before deploying it.

The user-facing streaming TTRL code was released on 2026-04-14 with support for dynamic data loading and customizable rewards, and the OpenClaw skill MIA-v1 landed on Clawhub on 2026-04-03.

The last push to the repository was on 2026-05-26, and there are no GitHub releases. The licence is a small point of confusion worth flagging: the licence field in the repository metadata reads unknown, while the README badge says MIT and links to the MIT licence text. The position is worth confirming with the authors before building on it.

Editorial conclusion

MIA suits a research team studying agent memory, or an engineer building a deep research agent who wants the Manager, Planner and Executor split and the released checkpoints to start from rather than designing one. It is the wrong choice for an application that just needs a retrieval layer over a document set, because the framework is built around a trained Planner and a reinforcement learning loop rather than around a pluggable memory backend, and it is the wrong choice if you need a supported package, since the repository publishes no releases and no installation instructions. Verify three things before you build on it: that the Executor and Planner checkpoints match the model you plan to use, since the reported small-model results depend on a specific 7B model, that the search backend you need is one of the two the project ships, and that the licence position is settled, because the repository's own field is listed as unknown while the badge says MIT.

Frequently asked questions

Official sources

1. ECNU-SII/MIA on GitHub
2. Issues
3. README