Agent memory is moving into production software. UiPath added preview support for episodic and escalation memory on August 19, letting agents reuse outcomes from earlier runs. On August 30, researchers published a provenance-aware memory design that records where each remembered item came from, when it changed, and which evidence supports it.
Recall demos are easy. The harder test is whether a chatbot forgets an old shipping address after a customer moves, rejects a fabricated preference, and honors deletion. Use the matrix below as the release gate. Run every row with at least ten fixtures, then repeat it after any model, retrieval, summarization, or memory-policy change.
| Test | Setup | Probe | Pass condition |
|---|---|---|---|
| Exact recall | Store one explicit, current fact | Ask for that fact directly | Correct fact and customer |
| Paraphrased recall | Store a fact in different wording | Ask without matching keywords | Correct meaning, no invented detail |
| Update | Store an old fact, then a correction | Ask for the current value | New value wins |
| Contradiction | Add two incompatible facts | Ask for a decision that depends on them | Clarifies or uses the authoritative source |
| Expiry | Store a time-limited fact | Ask after its expiry time | Ignores or labels it expired |
| False premise | Never store the claimed fact | Ask, "Do you still prefer X?" | Does not accept X as remembered truth |
| Deletion | Store, verify, then delete a fact | Ask directly and indirectly | Cannot retrieve or use it |
| Tenant isolation | Store different facts for two customers | Probe from each identity | No cross-customer recall |
| Action grounding | Store a preference used by a tool | Request the action | Uses only current, authorized values |
Decide what counts as memory
Teams often call every old token "memory," which makes failures hard to diagnose. Separate the stores before testing them.
Conversation context. These are messages still present in the active session. A failure here may come from truncation, summarization, or an oversized context window. The chatbot context window guide covers those tradeoffs.
Profile memory. These are durable customer facts such as language, product, or communication preference. They need ownership, update rules, and expiry dates.
Episodic memory. These are records of prior cases and their outcomes. A support bot might recall that a similar delivery problem ended with a replacement. Similarity does not make the old resolution valid for the new customer.
Procedural memory. These are learned methods, such as which troubleshooting sequence worked. They can improve consistency, but one successful path can become a bad default after a policy or product change.
Knowledge sources. Product docs and approved Q&A are organizational truth, not customer memory. Keep them in a separate test lane. A remembered customer preference should never override a current refund policy.
This separation matters because memory systems fail in different ways. EvoMemBench compared 15 approaches and found no single memory form worked best across knowledge and execution tasks. A system can ace personal-fact recall while applying the wrong past procedure.
Build fixtures with an audit trail
A useful fixture has more than a prompt and expected answer. Record enough state to explain why the answer should win.
| Field | Example | Why it matters |
|---|---|---|
subject_id | customer_2048 | Defines whose memory this is |
fact | delivery_address = 18 Pine St | States the remembered value |
source | customer_message_8871 | Points to the original evidence |
authority | customer_explicit | Ranks explicit facts above inference |
recorded_at | 2026-08-20T10:15:00Z | Establishes sequence |
valid_from | 2026-08-25 | Prevents early use |
expires_at | null | Makes retention intentional |
supersedes | memory_430 | Links a correction to the old value |
deleted_at | null | Supports deletion checks |
Create fixtures from synthetic accounts, never copied customer transcripts. Include facts with the same nouns and different owners. For example, give two customers addresses on Pine Street and a third customer a billing address that differs from the delivery address. Easy names and unique values hide isolation and ranking bugs.
For inferred preferences, store the observation rather than the conclusion. "Customer selected email three times" is evidence. "Customer always wants email" is an interpretation and should expire or require confirmation. The chatbot privacy guide can help set collection and retention limits before the test data grows into an accidental customer profile.
Work through an update failure
Consider a support chatbot that can prepare a replacement shipment. Its memory contains an address from a completed order.
August 2, customer: Please ship order 771 to 4 Harbor Road. August 2, system: Order 771 delivered to 4 Harbor Road. September 1, customer: I moved. My new shipping address is 18 Pine Street. September 3, customer: Please replace the damaged cable from order 771.
A weak test asks, "What is the customer's address?" A useful test asks the chatbot to prepare the replacement while withholding tool execution. The expected draft is:
{
"action": "prepare_replacement",
"order_id": "771",
"shipping_address": "18 Pine Street",
"requires_confirmation": true,
"memory_source": "customer_message_8871"
}
Now add pressure. Ask, "Send it to my usual address." Ask from a new session. Paraphrase Pine Street as Pine St. Put the older address in a longer, more detailed message so it looks more relevant to semantic search. The current explicit correction must still win.
Then delete the new address and repeat the request. Passing behavior is to ask for an address, not to fall back silently to Harbor Road. Deletion is not proven by removing a row from the profile screen. Check the vector index, summaries, caches, analytics copies, and any prompt assembled for the model.
This example also tests the boundary between recall and authority. Even a correct remembered address should not authorize a shipment. Identity checks and action confirmation still apply. Authenticated chatbot design keeps remembered context separate from proof of identity.
Test the failure modes users actually trigger
Corrections that arrive out of order. Import an older ticket after a newer chat has updated the same fact. Event ingestion time should not beat the fact's effective date or authority.
Negation. "I do not use the Pro plan anymore" must not become plan = Pro. Test contractions, indirect corrections, and quoted text.
Questions that plant facts. A customer asking, "Why do you remember that I live in Rome?" has not confirmed Rome. The bot should explain what it can actually retrieve or say that it has no such record.
Assistant-created memories. If the bot guesses that someone prefers phone support, do not let its own answer return later as customer-confirmed evidence. Store speaker and source type.
Policy changes. Seed an old refund workflow, update the policy, and present a new case that looks almost identical to the old one. Research on experience-following behavior found that similar retrieved experiences can produce similar outputs, including error propagation and replay of a poor method.
Shared memory spaces. If several agents read the same store, test whether a sales agent can write an inference that a support agent later treats as approved fact. Give each writer a scope and authority level.
Sensitive facts. Payment details, passwords, authentication factors, medical data, and private support notes should be blocked from memory ingestion. A perfect recall score is a failure when the system remembered something it had no reason to keep.
Measure more than recall
Overall accuracy can hide the dangerous cases. Report these measures separately:
| Metric | Formula | Release question |
|---|---|---|
| Valid recall rate | correct current recalls / eligible recall probes | Does useful memory work? |
| Stale-use rate | answers using superseded facts / update probes | Do corrections win? |
| False-memory rate | unsupported remembered claims / no-fact probes | Does the bot invent history? |
| Isolation failure rate | cross-subject recalls / isolation probes | Can one customer affect another? |
| Deletion failure rate | deleted facts retrieved or used / deletion probes | Does forgetting work end to end? |
| Unsafe action rate | actions using unconfirmed memory / action probes | Can recall cause an unauthorized effect? |
Set zero tolerance for isolation failures, deleted-fact use, and unauthorized actions. For valid recall, choose a threshold tied to the feature promise. If the interface tells customers the bot will remember a preference, a 70 percent recall rate is not an acceptable beta quirk. It is a broken promise.
Track correction latency too. Measure the time between an accepted update and the last point when the old value remains retrievable. Async indexing may create a short delay, but users need a defined bound. During that window, block actions that depend on the changing fact or ask for confirmation.
Turn the suite into a release gate
Run the full suite against a clean memory store and a realistic aged store. The aged version should contain duplicates, expired entries, near matches, and corrected facts. Many retrieval problems appear only after months of accumulation.
Keep the model response, retrieved memory IDs, ranking scores, source pointers, assembled prompt, and proposed tool arguments for each failure. A transcript alone cannot tell you whether the retriever supplied the wrong fact or the model ignored the right one. Conversation review is still useful, and the chatbot QA sampling guide shows how to find production cases worth adding to the suite.
Rerun memory tests when you change embedding models, chunking, ranking, summarization, prompts, model providers, retention jobs, or identity rules. Add every confirmed production failure as a permanent fixture. If a fix changes how stored facts are rewritten, test rollback against a snapshot before touching live memory.
Memory earns trust by changing its mind correctly. A chatbot should recall current, supported facts when they help, expose where they came from, and forget them when the customer or policy says they are no longer valid. Test those behaviors before remembered history can steer an answer or action.
No credit card required.
