Skip to main content
Memory manages the conversation context that gets sent to the LLM on each call. Without memory management, context grows unbounded until it exceeds the model’s context window and causes an API error. Motus handles this automatically with two built-in strategies.

Memory types

Both extend BaseMemory and share an async interface: add_message(), compact(), get_context(), and get_memory_trace().

Architecture

CompactionBase provides the core compaction logic shared by all compacting memory types: turn boundary detection, token threshold management, and LLM-based summarization. CompactionMemory adds conversation log persistence and session restore on top.

BasicMemory

BasicMemory is the default. Messages accumulate until the conversation ends. If the context window overflows, the model provider returns an API error.
You get this when you pass no memory_type or memory argument.

CompactionMemory

CompactionMemory monitors token count after every message. When the estimated token count exceeds a threshold and the conversation is at a turn boundary, it summarizes older turns into a continuation message. The agent loop continues without interruption.
Use memory_type="compact" for any agent that will handle long conversations or run in production. It prevents context window overflows without any changes to your agent logic.

Configuring CompactionMemory

For full control, instantiate CompactionMemory directly and pass it via the memory parameter:

CompactionMemoryConfig fields

Compaction only triggers at clean turn boundaries to avoid corrupting in-progress tool call sequences. A ReAct agent loop produces three types of turn units:
  • Unit A: [user message]
  • Unit B: [assistant + tool_calls] followed by [tool_result x N]
  • Unit C: [assistant, no tool calls] (final response)
Compaction defers until all tool results from a parallel tool call batch have arrived. This is tracked via _pending_tool_calls, a counter incremented when the assistant issues tool calls and decremented as each result arrives. Compaction fires only when the counter reaches zero.

Session save and restore

When you set log_base_path, CompactionMemory writes every message and compaction event to a JSONL file. You can restore a previous session from this log:
restore_from_log replays all log entries (messages and compaction events) to rebuild the in-memory state. The restored instance appends to the same session log. For programmatic session persistence without log files, use CompactionSessionState:
CompactionSessionState captures the current context window (messages + system prompt) along with session identity and log store location for cross-session continuity.

Custom compaction function

Replace the default LLM-based compaction with your own summarization logic:
The function receives the message list and system prompt, and returns a summary string.

Custom memory

Subclass BaseMemory and implement compact() and reset() to build your own strategy:
The base class provides working memory management, token estimation, tool result truncation, and trace logging. For compacting memory types, extend CompactionBase instead. It provides boundary-aware auto-compaction, set_model(), and the default LLM summarization logic.

BackgroundMemory (coming soon)

A long-term memory solution that works both locally and on the cloud is under active development. BackgroundMemory will extend CompactionBase with agent-managed cross-session memory, allowing the main agent to remember facts, preferences, and context across conversations without distraction.