Does Strands Agents Remember Between Runs? Sessions vs Real Memory

Does Strands Agents Remember Between Runs?

Short answer: it can replay a conversation, but it does not remember the way you probably mean. Pass the same session id and a Strands agent reloads that conversation's message history from disk or S3, so the task continues where it stopped. Skip the session id and every run starts blank. And even with sessions on, the agent carries no durable knowledge across unrelated runs: it replays what was said in one conversation, it does not know your user's preferences the next time they show up.

What a Strands session actually saves

Session persistence in the Strands Agents SDK is a checkpoint of the conversation. You hand the Agent a session manager, and lifecycle hooks persist every message as it happens: model responses, tool results, and agent state get written out on each turn. Create a new agent instance with the same session id and it rehydrates the full history from storage, so "continue where we left off" works across processes and restarts.

The storage backends are straightforward. FileSessionManager writes to local disk (defaulting to /tmp/strands/sessions) and suits local development. S3SessionManager moves the same data to S3 for production, and a pluggable repository interface covers anything else. The newer Strands harness keeps sessions on by default: state lands under ./.agent/sessions, you opt in per task with session={"id": "refactor-parser"}, and without an id the harness assigns a fresh random one, so the agent starts with no past at all.

Why a replayed conversation is not memory

Strands' own documentation draws the line explicitly: a session (checkpoint) persists one conversation so you can resume that exact task after a restart, while long-term memory distills durable facts and recalls them across every conversation, whether or not a session is involved. They are orthogonal. You can run with neither, either, or both.

The distinction matters because replay has costs that compound. Every resumed session reloads the transcript, and transcripts only grow: long sessions get slower to load and more expensive to feed the model. Restoring context is also not the same as resuming execution. When a crashed agent restarts with the same session id, it sees what was said but the event loop starts over, and it may repeat completed work or take a different path. Knowing what the agent said is not a guarantee of what it did.

So the honest picture is two separate mechanisms. Sessions answer "where did this task stop?" Long-term memory answers "what do we know about this user, across every task?" The SDK gives you the first one out of the box. The second one is yours to build.

How to give a Strands agent memory that actually persists

If you are shipping a Strands agent, here is the shape that works:

1. Give every conversation a stable session id. Reuse one id per user or per task (session={"id": "user-abc-123"}); generate a new one when you want a clean start. The id is the entire resume mechanism.
2. Pick the storage backend for your environment. FileSessionManager for local development, S3SessionManager in production. Local files do not survive a redeploy, so do not learn that in production.
3. Separate durable facts from conversation history. For knowledge that must survive across unrelated sessions, add a memory store: the harness ships a built-in memory layer (a test store for prototyping, a Bedrock Knowledge Base store for production), or wire a memory tool like Mem0 into the agent so it can store, retrieve, and list memories on its own.
4. Write back decisions, not just dialogue. At the end of a run, save what was decided and what was completed, in your own words, not the raw transcript. Future runs retrieve a distilled record instead of re-reading hundreds of messages.

Step 4 is the one most builders skip. A session replay tells the agent what happened; a memory record tells it what mattered.

When the memory should live outside the agent

There comes a point where operating your own memory store stops being the job. Running Mem0 or a Bedrock knowledge base means provisioning, monitoring, backups, and retrieval tuning, all for infrastructure that is not your product. And a store wired into one agent is still fenced in: your Strands agent, your scheduled workflows, and your chat assistant each keep a private record unless you build the sharing yourself.

This is the shape Vilix AI takes: a cloud-hosted memory layer your agent reaches over MCP. A built agent connects with an API key as a Bearer header to https://api.vilix.ai/mcp and gets full memory with zero memory infrastructure to run. get_context loads the relevant saved context into the run, save_turn writes the exchange back, and retrieval is semantic plus keyword search, so it finds what the agent meant, not just what it typed. The difference is who operates the memory: your agent keeps its tools and sessions, and the durable knowledge lives in one hosted layer every tool can read.

FAQ

Does the Strands harness remember between runs by default? Sessions stay on by default, so a task can be resumed, but each agent still starts fresh under a new random id unless you pass an explicit session id. Durable knowledge across unrelated runs needs the memory layer, not just sessions.

What is the difference between a Strands session and Strands memory? A session persists one conversation so you can resume that exact task after a restart. Memory distills durable facts and recalls them across every conversation, whether or not a session is involved. Strands documents them as orthogonal: you can run with neither, either, or both.

Where is Strands session state stored? With the raw SDK, FileSessionManager writes to local disk (default /tmp/strands/sessions) and S3SessionManager writes to S3. The Strands harness writes session state under ./.agent/sessions by default, configurable per agent.

Can a Strands agent remember user preferences across sessions? Not from sessions alone. Preferences are durable facts across unrelated conversations, which is the memory mechanism, not the session mechanism. Add a memory store or memory tool for that.

Do I still need a memory layer if I use session persistence? If your agent only ever resumes one long task, sessions may be enough. If it serves users across many conversations, runs on a schedule, or shares context with other tools, you need durable memory underneath the sessions.

If your Strands agent replays conversations but still forgets your users, give it one memory. Vilix AI is the shared memory layer for AI agents: cloud-hosted, zero infrastructure, same context everywhere over MCP, full conversation history. Free forever, no credit card.