Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A context-aware support assistant works when it keeps three kinds of information separate: what is happening in the current conversation, what should persist about a specific customer or support case, and what the company already publishes in its knowledge base. Blurring those layers makes both the assistant’s behavior and its privacy posture hard to control. The build decisions that follow are what gets saved, how it is matched to the right identity, how it is retrieved and corrected, how it is deleted, and whether your team or a managed service owns the store.
Start with three layers that do different jobs
Most memory bugs in support products come from treating everything as “context.” Keep the layers distinct from the start:
| Layer | What it holds | How long it lasts | Example in a support product |
|---|---|---|---|
| Session state | Message history, tool results, and working variables for the current interaction | Ends with the interaction unless you externalize it | The order number a customer pasted into this chat |
| Durable memory | Selected facts scoped to a user or a case: stated preferences, confirmed account details, support-case decisions | Across sessions, governed by your expiry and deletion policy | “Prefers email contact; refund approved on case 4812 for a damaged item” |
| Knowledge base | Company-authored articles, policies, and product documentation shared by all users | Maintained by content owners, not by individual conversations | The current returns policy article |
Google Cloud’s agentic AI architecture guidance describes short-term memory as the ongoing conversation’s session and state, including message history, tool results, and other variables. It describes long-term memory as persistent knowledge available across conversations for an individual user. The guidance states: “To create stateful, context-aware agents, you must implement mechanisms for short-term memory and long-term memory.” Its long-term definition is user-scoped. A case-level memory, such as an open refund dispute that several agents touch, is an extension your team must define and scope itself.
Where session state lives is an architecture decision too. The same guidance says a process-local, in-memory approach is simpler for development but loses state on restart, and it recommends external state management for production systems that need scalability and reliability.
The OpenAI Agents SDK draws a similar line between Session history and memory distilled from prior runs. Its documented memory process extracts summaries and raw notes from accumulated conversation files and then consolidates them for later runs, as described in the Agent memory guide.
How the memory lifecycle works
Durable memory is a pipeline with a review path, not a single write to a database. The loop below covers capture through deletion. Each stage needs an owner and a test.
1. Capture only what has future value
Decide which sources are eligible before writing anything. Typical eligible sources are a preference the customer states explicitly, an account detail confirmed through an authenticated flow, and a decision recorded on a support case by a human or an approved workflow. Casual remarks, guesses inferred by the model, and content from unverified channels should usually stay out. Sensitive categories need an explicit policy: exclude them, or store them with stronger protection and narrower access. Writing this rule down is what makes later audits possible.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →2. Extract and consolidate
Turn raw interactions into short, reviewable facts rather than storing transcripts as memory. Each fact should carry a timestamp and a pointer to its source where possible. Consolidation is where contradictions get resolved. If a customer said in March that they moved to Leeds, and a June case confirms a shipping address in Manchester, the newer confirmed value should supersede the older one, and the older value should remain in revision history rather than silently disappearing. Google Cloud’s Memory Bank documentation describes extraction and consolidation, asynchronous generation, and continuous event ingestion as built-in behaviors of that managed service.
3. Scope every item to an identity or case
Each memory item must belong to a specific user, case, or both. Enforce that scope in the code that reads and writes memory, not in the prompt. A model told “only use this customer’s data” can still be handed another customer’s record by a retrieval call that lacked a filter. Authorization applies to writes as well: an agent working on case A should not be able to attach a fact to customer B. Google’s Memory Bank documents identity-scoped collections and restrictive permissions; your application still has to supply correct scope keys.
4. Retrieve just in time
Do not load the full memory store, or the full conversation history, into every prompt. Anthropic’s memory tool documentation emphasizes just-in-time retrieval over loading everything up front. In practice, filter first by identity and case, then by recency or status such as “superseded,” then rank by relevance, and cap the number of items that enter context. Memory Bank describes similarity search as a retrieval mechanism. Similarity alone is not a sufficient filter: a semantically close fact can be stale, out of scope, or superseded.
5. Respond with appropriate uncertainty, then update
When a remembered fact is old or conflicts with the current conversation, the assistant should say so instead of asserting it. For example, “Our records show a Manchester address from June. Is that still correct?” is safer than shipping to that address without checking. Update memory only when the new interaction establishes a durable change, not when a single sentence in a complaint happens to mention a name.
6. Review, correct, and delete
Every stored item needs a route to correction, expiry, or deletion. Deletion must account for the copies that exist: the source conversation, any derived summaries, and any backup or replica that your retention policy covers. If you cannot delete from one of those places, record that gap and define how it is handled rather than assuming the item is gone.
Two ways to own the memory store
Storage ownership is the first architecture decision, and it shapes everything else. The two patterns in current vendor documentation are different in kind.
Managed memory service
Google Cloud’s Memory Bank is a managed option. The documentation lists extraction and consolidation, asynchronous generation, continuous event ingestion, configurable topics, identity-scoped collections, similarity search, TTL, memory revisions, and restrictive permissions. The provider handles persistence and the generation pipeline. Your team configures what gets extracted, how collections are scoped, and what expires, and then integrates the service into your agent. The trade-off is that the store, its retention behavior, and its operational characteristics belong to the provider, so your deletion and audit story depends on how that service behaves under your configuration.
Application-executed memory
Anthropic’s memory tool follows a different model. The Claude API documentation states: “The memory tool operates client-side: Claude requests file operations, and your application executes them.” The model asks for an operation, and your code decides whether to run it, against storage your application controls. That makes your application the enforcement point for authorization, validation, retention, and logging. You gain full control over where data lives and how it is deleted, and you take on the work of indexing, backups, scaling, and observability. Read the Memory tool documentation for the operation set and the just-in-time retrieval pattern before designing your own mapping.
Decision axes to compare
| Decision axis | Managed memory service (Memory Bank as documented) | Application-executed memory (memory tool pattern) |
|---|---|---|
| Storage ownership | Provider stores and manages memory; you configure topics, collections, and policies | Your application controls the store and executes every read and write |
| Identity and authorization | Identity-scoped collections and restrictive permissions are documented; you still supply correct scope keys | Enforced by your code on each requested operation; the model only requests operations |
| Retrieval | Similarity search is documented; filter and ranking behavior should be confirmed against current docs | Whatever you implement; the documented pattern is just-in-time retrieval rather than loading everything upfront |
| Updating and contradictions | Memory revisions are documented; how conflicts are resolved is not stated in the cited material, so test it against your own cases | You design reconciliation, timestamps, and revision history |
| Retention and deletion | TTL is documented; whether deletion reaches source conversations and derived memory depends on configuration | You define expiry, purge jobs, and whether backups and derived summaries are covered |
| Operations | Provider handles persistence and scaling; you own integration, latency budget, and observability of what was retrieved | You own persistence, scaling, availability, latency, and observability |
| User experience | You build review, correction, and suppression on top of the service | You build review, correction, and suppression on top of your store |
This is not a choice between a vector database and a relational database. The cited sources support managed stores and application-controlled mappings to files or databases. They do not establish a single best storage technology for every support workload. Pick based on who must control deletion and access, and on how much operational work the team can carry.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Privacy and user control
User control is a core requirement, not an afterthought. OpenAI’s help article on memory in ChatGPT is a useful reference for the expectations users are coming to expect:
- Memory behavior and controls vary by plan, region, platform, and workspace.
- Users can review and correct what has been remembered.
- Turning memory off does not delete prior chats.
- Deleting a remembered item may require deleting the original chat and removing that information from other places where it appears.
Translate those expectations into explicit product decisions for your own support system:
- What may be saved, and from which channels.
- Whether sensitive data is excluded or stored under stricter protection.
- How user identity is established before any memory is read or written.
- Whether records are shared across teams or cases, and who can read or write each scope.
- Who can inspect and correct memory, and whether customers can see it.
- How long each category is retained, and what triggers expiry.
- How deletion propagates to source conversations, derived summaries, and backups.
- How the system avoids presenting a stale or uncertain fact as current.
This guide does not make legal compliance claims. Applicable privacy and retention duties depend on geography, industry, data type, and deployment, and they should be reviewed with counsel for your specific product.
Recommended Free Tools
Consumer memory as a reference point
OpenAI’s October 2026 announcement, Dreaming: Better memory for a more helpful ChatGPT, describes an updated memory architecture built on background “dreaming,” alongside a reviewable memory summary. According to that announcement, the feature had been available to Plus and Pro users, a version for Free users was beginning to roll out, and Plus and Pro received increased capacity. OpenAI also reports that serving the Free-user version required approximately 5x less compute after improvements. These are OpenAI’s own statements about its product at the time of the announcement. Plan availability changes, so check current plan terms before relying on any tier detail.
Reading published benchmark numbers
Memory research reports impressive percentages, but they describe the authors’ evaluation setup, not your production outcomes. Attribute each figure to its source and to the comparison it names.
- The Mem0 preprint, Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory (authors, 2025), reports a 26% relative improvement in the LLM-as-a-Judge metric over OpenAI in its own benchmark comparisons.
- The same preprint reports 91% lower p95 latency versus the full-context method, measured in its evaluation setup.
- The same preprint reports more than 90% token-cost savings versus the full-context method, again in its evaluation setup.
- The EMNLP 2025 paper MemoryOS: A Memory OS for AI System describes a three-tier short-, mid-, and long-term memory structure with storage, updating, retrieval, and generation modules, and reports experiments on benchmark datasets.
None of these figures is an independent comparison, and none forecasts a customer-support deployment. Use them to justify running your own evaluation on your own tickets, latency targets, and token budgets.
Quick Recap
Common failure modes and fixes
| Symptom | Usual cause | Fix |
|---|---|---|
| The assistant uses an old address or plan | No timestamps, no supersession, or no TTL on volatile facts | Store timestamps and source references, supersede rather than append, and expire volatile categories |
| Another customer’s details appear in a reply | Identity scope applied only in the prompt, or missing from a retrieval filter | Enforce scope in the retrieval and write code path, and test cross-identity reads explicitly |
| A deleted item reappears | A derived summary, source copy, or replica still holds it | Trace every location for the item, delete each one, and log the deletion |
| Responses slow down or drift as history grows | Full history or full memory loaded into every prompt | Retrieve just in time, filter before ranking, and cap items in context |
| Context disappears after a restart | Session state held only in process memory | Externalize session state to a store your production system can recover from |
Build order
- Externalize session state so that a restart does not end an active support conversation.
- Define identity and case scope keys, and enforce them on every read and write.
- Write capture rules that list eligible sources, excluded data, and sensitive categories.
- Choose the storage model, managed service or application-executed, using the decision axes above.
- Build extraction and consolidation with timestamps, source references, and revision history.
- Add just-in-time retrieval with filters and a cap on items entering context.
- Ship review, correction, suppression, and deletion paths, and test them end to end, including derived copies.
- Evaluate on your own support tickets before trusting any published benchmark result.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
