Sessions vs memory
They solve different problems. Use both.| Session history | Memory | |
|---|---|---|
| Stores | The messages in this conversation thread | Learned facts about the user |
| Scope | One session_id | One user_id, across all their sessions |
| Enable with | add_history_to_context=True | enable_agentic_memory=True or update_memory_on_run=True |
| Answers | ”What did we just discuss?" | "What do I know about this person?” |
Identifiers
| Identifier | Distinguishes | Maps to in your product |
|---|---|---|
user_id | The person | Your auth subject (user ID, email) |
session_id | A conversation thread for that person | A chat tab, a Slack thread, a support case |
session_id. Memory is scoped by user_id.
Memory: automatic or agentic
| Mode | Set | Use when |
|---|---|---|
| Automatic | update_memory_on_run=True | Compute memory after every run. |
| Agentic | enable_agentic_memory=True | The agent decides using tool calls. |
Reading memory back
For a profile screen or a debug view, pull a user’s memories directly.Long conversations
History grows. Two ways to keep token cost bounded without losing continuity:| Technique | Effect |
|---|---|
num_history_runs=N | Only the last N turns flow into context |
Session summaries (enable_session_summaries=True) | Older turns are condensed into a running summary |
Next steps
| Task | Guide |
|---|---|
| Put this behind an HTTP API | Serve as an API |
| Carry memory across Slack and web | Interfaces |
| Give the agent live data | Connecting your data |