Agent memory keeps useful information available beyond the reasoning step that produced it. Without it, an agent may lose track of events during a long task, require a user to repeat earlier conversation, or start a new session without access to relevant past experience. Memory has three distinct jobs: manage context within one run, maintain continuity across runs in a session, and retain knowledge across sessions. section 6.0 section 6.1.3
Choose the mechanism according to how long the information must remain useful:
- Within one run(), control growing context with a sliding window, compaction, or summarization. A sliding window retains recent messages; compaction removes tool calls and results or saves them to a file; summarization condenses older conversation. section 6.1.3
- Across run() calls in one session, persist conversation events and state. SessionManager loads events from a Session so the next call can continue the conversation; a different session_id does not provide that continuity. section 6.1.3 section 6.4.1
- Across sessions, extract information worth preserving, store it externally, then retrieve it when relevant to a new task. MemoryManager serves this role rather than preserving the entire conversation as session history. section 6.4 section 6.4.1
Table 6.2 Mapping each pattern to strategies
| Pattern |
Primary strategy |
Description |
|---|---|---|
| Patterns 1, 2 |
Reduce + write |
Managing extensive context via sliding window, compaction, and summarization |
| Pattern 3 |
Write + retrieval |
Extracting and storing memories (write) > Searching via tool in next session (retrieval) |
The pattern-to-strategy mapping distinguishes reducing and writing the context needed now from writing knowledge that can be retrieved in a later session. section 6.1.3
A long-term memory pipeline can extract structured information from execution history, check for duplicates, store it in a vector database, and retrieve relevant records for later tasks. Storing whole conversations is simpler but can bury useful facts in noise. Retrieval may be an explicit tool call or automatic context injection through process_llm_request() before an LLM call. section 6.4.1 section 6.5
A useful record across sessions
Suppose an agent solves a problem using one approach and records the result. In a later session, it can retrieve that problem-solving record instead of relying on the previous session’s conversation being available. A new approach or result can be added as a separate record, while an identical attempt can be skipped. This ADD-and-SKIP design retains past failures without implementing updates or deletion; changing user profile facts would require those additional operations. section 6.4.1 section 6.4
Keep stored history separate from the context presented to the model. ExecutionContext remains immutable while LlmRequest is optimized for each call. Measure tokens, compact tool results, and reserve summarization as a last resort when controlling context growth. section 6.5
