Skip to main content
Long-term memory is an agent’s ability to retain information across sessions, including user preferences, past decisions, and knowledge or rules summarized from conversations. AgentScope implements different long-term memory capabilities as agent middleware. Each long-term memory implementation is a MiddlewareBase subclass that non-invasively handles memory injection, retrieval, and write-back. AgentScope currently supports the following long-term memory implementations, with more under development:

Agentic Memory

Agentic Memory is AgentScope’s native long-term memory implementation. It provides long-term memory through Markdown file reads, writes, and retrieval. At runtime, the agent autonomously creates Markdown memory files, maintains an index of all memory files in a fixed MEMORY.md file, and automatically injects that index into the system prompt. This follows a “progressive disclosure” pattern.
Agentic Memory supports different runtime environments through the backend parameter, such as local, Docker, E2B, and cloud sandboxes. It uses LocalBackend by default.
At runtime, the agent uses the built-in Read, Write, and Edit tools to create, access, and modify long-term memory. A typical file structure looks like this:
Each Markdown file follows the frontmatter convention and includes name, description, and type fields for later retrieval and injection:
MEMORY.md stays short. It serves only as an index and is automatically injected into the system prompt. For example:
Agentic Memory has two retrieval paths. First, the agent can autonomously retrieve relevant files based on the prompt and the MEMORY.md index. Second, when reply / reply_stream is called, the middleware starts an async task that asks an LLM to select relevant Markdown files, then checks before later reasoning steps whether that task has finished and injects the retrieved results as a HintBlock. Note that retrieval is asynchronous: injection happens at checkpoints before reasoning starts inside the reasoning-acting loop, and the exact timing depends on retrieval latency. If the current reply does not enter a later reasoning round, such as when the model produces no tool calls, the retrieved long-term memory may not be injected into that reply. The workflow is: Use Agentic Memory in different environments as follows:

Mem0

Mem0Middleware is a drop-in long-term memory backend powered by mem0. It works with both mem0.AsyncMemory (open-source) and mem0.AsyncMemoryClient (hosted Platform). With mem0.AsyncMemory (open-source), it can route mem0’s own memory extraction and embedding through your existing AgentScope models — so mem0 needs no separate provider key.

Installation

Mem0Middleware’s dependencies are available as an optional extra in AgentScope:

Quick start

The fastest path is to pass a dedicated AgentScope chat model and an embedding model to the middleware; it builds an open-source mem0 store internally and wires both extraction and embedding through them.
Mem0Middleware contributes its search_memory / add_memory tools through list_tools(), which the agent does not call automatically. To make the tools available to the agent, collect them yourself and pass them into the toolkit — Toolkit(tools=await mw.list_tools()). In static_control mode list_tools() returns an empty list.

Control modes

The mode parameter decides how the agent interacts with mem0. It defaults to "both", matching AgentScope 1.x’s ReActAgent.long_term_memory_mode.

Construction paths

Mem0Middleware supports three ways to wire up the mem0 backend:
When you use an AgentScope chat model to construct the mem0 backend, Agent and Mem0Middleware must use separate model instances. This requirement applies to both model-backed paths below: passing AgentScope models directly, and providing chat_model with a custom mem0 config. It does not apply to the pre-built client path, where Mem0Middleware uses the supplied mem0 client directly.The instances must be separate because AgentScope chat models use an asynchronous interface, while mem0 invokes a synchronous LLM interface during memory extraction. To bridge these interfaces, Mem0Middleware wraps the AgentScope model in an adapter: Agent invokes its model on the application’s event loop, whereas the adapter runs the memory-extraction model coroutine on a dedicated bridge event loop.If the two paths share one model instance, they also share its async HTTP client and connection pool across two event loops. The pool’s underlying resources may become bound to the loop where they are first used; accessing them from the other loop can then cause intermittent Connection error failures or RuntimeError: ... is bound to a different event loop. Because the failure can occur only during memory extraction, the Agent may still return a normal response even though the memory write fails or produces no new facts.The two instances may still use the same provider, model name, endpoint, and API key—the requirement is only that they are separate model/client objects. In multi-agent applications, do not share one mem0 chat-model instance across independently constructed model-backed Mem0Middleware instances, because each adapter may own a different bridge event loop.
Pass AgentScope models and let the middleware build an open-source AsyncMemory internally (mem0’s default Qdrant store). The embedding model’s dimensions must match the vector store (the default Qdrant expects 1536).
Mem0Middleware requires an async mem0 client (mem0.AsyncMemory or mem0.AsyncMemoryClient). The synchronous Memory / MemoryClient are not supported.

Key parameters

Agent-callable tools

In agent_control and both modes, the middleware contributes two tools the model can invoke on demand:
  • search_memory(keywords, limit=5) — retrieves memories using a list of short, targeted keywords. Each keyword is issued as an independent query; results are merged and deduplicated.
  • add_memory(thinking, content) — records durable facts. Only content (a list of standalone sentences) is persisted to mem0; thinking stays in the transcript for auditability.
Both tools auto-allow themselves and read user_id / agent_id directly from the middleware instance, so they require no extra wiring beyond adding them to the toolkit.