Seven AI Agent Memory Failures—and How to Recover

Long-running agents rarely fail because they have no memory. They fail because current truth, historical events, summaries, retrieved candidates, and authority are mixed together without provenance or correction rules.

1. Stale facts look current

Symptom: the agent quotes an old price, customer count, policy, or product state after a correction.

Cause: records lack observation time and supersession links, or the retrieval index was not refreshed.

Recovery: create an explicit correction record, mark the prior value as superseded, update the canonical owner, rebuild affected retrieval entries, and add a temporal test to the evaluation set.

2. Summaries lose the source

Symptom: the agent gives a plausible statement but nobody can trace it to a record.

Cause: a compressed summary replaced evidence rather than pointing to it.

Recovery: require every derived claim to retain source IDs and observed-at times. Treat a source-free summary as a hypothesis, not verified memory.

3. Semantic retrieval misses exact constraints

Symptom: the agent retrieves conceptually related material but misses the exact customer, status, date, or identifier.

Cause: embeddings were used for a job that needs deterministic filtering.

Recovery: retrieve exact structured records first, use semantic search only to discover supporting material, and require both layers to preserve canonical IDs.

4. Duplicate records compete

Symptom: two copies of the same decision or customer state appear with slightly different wording.

Cause: ingestion created new records without stable IDs or idempotency keys.

Recovery: define the identity key, merge duplicate current-state records, keep event history append-only, and test the ingest step twice to prove it is idempotent.

5. Prompt bloat becomes memory

Symptom: every run loads an ever-growing transcript, latency rises, and earlier instructions unpredictably dominate.

Cause: raw history was treated as a memory architecture.

Recovery: separate policy, current state, recent events, and retrieved context. Give each a size limit, selection rule, and freshness owner. Archive raw history outside the active prompt.

6. Private memory leaks across tasks

Symptom: a public response contains internal notes, customer data, credentials, or another tenant’s context.

Cause: retrieval ran before authorization or the index lacked sensitivity and tenant boundaries.

Recovery: filter by identity and permission before retrieval, keep secrets out of embeddings, add negative privacy fixtures, and rotate any exposed credential immediately.

7. Remembered context is mistaken for permission

Symptom: the agent performs an external or high-stakes action because a historical note says the founder once approved something similar.

Cause: memory and authorization share the same decision layer.

Recovery: require the current permission manifest and action-specific approval at execution time. Historical precedent may inform a recommendation, but it cannot grant authority.

Incident response sequence

1. Pause the affected action path.
2. Preserve the input, retrieved record IDs, output, model/version, and timestamps without copying secrets into a public issue.
3. Classify whether the fault came from ingestion, storage, retrieval, synthesis, permission, or presentation.
4. Correct the canonical record and record what it supersedes.
5. Rebuild or invalidate derived summaries and indexes.
6. Add the exact failure as a regression fixture.
7. Rerun the fixture plus neighboring tasks before resuming the action path.

What recovery is not

Deleting an embarrassing output, rewriting a prompt, or increasing the context window is not enough. A durable recovery identifies the faulty layer, preserves a correction trail, proves the same case now passes, and demonstrates that the fix did not weaken privacy or permission boundaries.