The mechanism
Session persistence lets an agent resume after a process restart or a later request. It stores conversation and related state through a backend. In current Python documentation, SnapshotSessionManager with an explicit storage backend is the recommended path for new single-agent sessions. Older file and S3 managers remain compatibility options. Verify the path used by your pinned version and orchestration mode.
A snapshot records what the application knew at a point in time. It is not an atomic transaction with every external tool. If a note was appended to another service and the process crashed before saving the conversation, restoring the snapshot may not reveal that write. Chapter 8’s idempotency and reconciliation design still applies.
A worked local session configuration
Optional local SDK configuration. This uses a disposable project subdirectory and synthetic records. The agent call is omitted; adding one can invoke your configured model and write session data.
from strands import Agent
from strands.session import SnapshotSessionManager
from strands.storage import LocalFileStorage
session_manager = SnapshotSessionManager(
session_id="parcelops-training-a",
storage=LocalFileStorage("./lab-sessions/"),
)
agent = Agent(
model=model,
tools=[lookup_incident],
session_manager=session_manager,
callback_handler=None,
)Use an application-generated, authorized session ID in a real service. Do not build a storage path by concatenating arbitrary user input. Restrict access to session files because conversation history and tool results can contain sensitive material. A private directory on a laptop is a lab choice, not a distributed persistence architecture.
Current documentation contains evolving guidance around multi-agent compatibility paths. For Graph or Swarm, place session ownership at the orchestrator and verify the exact supported manager for your release. Do not attach an independent manager to every child agent and assume the resulting snapshots form one consistent workflow.
Practice: restart with evidence
Offline planning, optional model integration. Define a two-turn conversation: first ask about INC-104, then ask “what evidence supports that?” Record the intended session ID and expected ownership. In the optional live exercise, complete the first turn, stop the process, recreate it with the same session configuration and ask the follow-up.
Expected observation: restored context should support continuity, but the answer still needs current evidence if the incident may have changed. Repeat with a new session ID to confirm that unrelated conversations start separately. Do not inspect real private session stores; use only the disposable training directory you created.
Now simulate an external write that succeeds just before a crash. Record its idempotency key outside the conversational narrative. On recovery, reconcile the authoritative destination before issuing another write. This exercise reveals the difference between conversation recovery and business recovery.
Troubleshooting and trade-offs
If a session appears empty, check the ID, backend path, permissions and version compatibility before adding manual history. If two workers overwrite each other, inspect backend concurrency semantics and ownership. A local filesystem can be ephemeral in hosted runtimes; successful local persistence does not prove durability after redeployment.
Define retention, deletion and migration policies. Backups can preserve data after a session is deleted from the primary store, and restored snapshots may use an older schema. Document the behavior rather than assuming “delete session” means immediate removal from every storage layer.
Interview practice
Why does a session snapshot not guarantee exactly-once business effects?
The snapshot and external service may commit independently. A crash can occur between them. Stable idempotency keys, destination reconciliation and appropriate transaction design handle that gap.
What should you test before using a session backend in production?
Ownership checks, concurrent access, restart recovery, failure behavior, retention, deletion, encryption and migration compatibility. Test the actual hosted storage semantics, not only a local directory.
Completion check
Explain same-session and new-session behavior. Identify the authoritative record for an external effect after a crash. Keep the optional integration result separate from the offline recovery design.
Sources and version notes
Checked 6 October 2026. Python examples target strands-agents==1.58.0 unless labelled otherwise. Live documentation can change; compare your installed version before adapting an example.
Make the understanding yours.
Use the completion check above. Mark this chapter when you can explain the mechanism and its limits.
Self-assessed reading progress. This does not certify that a lab ran or a system is secure.