The mechanism
A session preserves a conversation. Long-term memory carries selected knowledge across conversations. Retrieval supplies relevant material for a current question. These can use related storage systems, but they have different purposes and retention rules. Persisting every transcript indefinitely is not the same as designing useful memory.
Current Strands documentation describes a MemoryManager connected to memory stores, with recall, injection and optional extraction. The built-in test store is intended for prototyping; managed stores add separate service prerequisites and potential charges. This chapter focuses on the contract you should design before enabling automatic writes.
A worked memory record
This is a proposed application schema. It is not a claim that every Strands memory backend stores these fields automatically.
{
"memory_id": "memory-demo-001",
"tenant_id": "tenant-demo",
"kind": "operator_preference",
"value": "Show incident timestamps in UTC",
"source_ref": "approved-preference-form:demo",
"created_at": "2026-10-06T10:00:00Z",
"expires_at": null,
"write_basis": "explicit_user_setting"
}A user preference is a reasonable durable fact. “INC-104 is delayed” is operational evidence that may become stale quickly. Saving both as undifferentiated memory makes it easy for the assistant to repeat an outdated status. Store durable preferences separately from time-sensitive source records and require a fresh lookup for current incident status.
The model may suggest a memory, but the application should decide whether that category is permitted to persist. Sensitive information inferred from a conversation should not become durable merely because extraction is convenient. Define allowed categories, retention and deletion behavior before connecting a live store.
Practice: classify what deserves memory
Offline. Classify six synthetic items: preferred timezone, a resolved incident, a one-time access token, a team runbook URL, an unverified rumor and a revoked preference. For each, choose “persist,” “retrieve from source,” “discard” or “delete,” and explain the basis.
Expected observation: some useful facts belong in authoritative source systems rather than an agent memory. A runbook can be retrieved with a version and access check; a token should never become remembered conversational knowledge. A revoked preference requires a deletion or supersession path, not another conflicting note.
Design a retrieval test where tenant A and tenant B have similar records. The correct result must satisfy both semantic relevance and authorization. Add a stale record with a higher similarity score than the fresh one. Ranking alone should not decide truth or access.
Troubleshooting and trade-offs
If the assistant recalls the wrong fact, inspect the stored source, scope, timestamp and retrieval query. Improving the embedding model cannot repair missing ownership metadata. If memory grows without bound, add category and retention policies rather than relying only on a larger context window.
Deletion is an end-to-end behavior. Consider indexes, caches, backups and derived summaries. Document which stores are immediately updated and which follow a retention schedule. Avoid claiming instant deletion from all layers unless the system actually provides and verifies it.
Memory can improve continuity while increasing privacy and operational obligations. Start with a small explicit preference store and a clear user-visible purpose. Measure whether memory helps representative tasks before enabling broad extraction from every interaction.
Interview practice
How is long-term memory different from a saved session?
A session restores conversation continuity; memory carries selected knowledge across sessions. They differ in scope, retrieval, retention and deletion requirements, even if both persist data.
Why is semantic similarity insufficient for retrieval?
A relevant-looking record may belong to another tenant, be stale or lack reliable provenance. Authorization and freshness checks must constrain what retrieval can return and how it is used.
Completion check
Define one permitted memory category and one forbidden category. Trace a fact from creation through recall, update and deletion. Explain how current incident status remains tied to the source of record.
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.