Agent Memory in 2026: Three Failure Modes to Fix

Most agent memory problems in 2026 are not retrieval-quality problems. They are housekeeping problems: stores that only accept writes, retrieval paths nobody measures, and context that was never actually scoped to the thing it describes. Two years of argument about embeddings, rerankers and chunk sizes have left a lot of production systems with a memory layer that degrades quietly with every session.

Memory that grows but never shrinks

An append-only store feels safe. You never lose information, you can always reconstruct why the agent said something, and writes are cheap. The problem is that reads are not: every query now competes against months of near-duplicates, half-superseded facts and notes from an architecture you abandoned.

The specific symptom is contradiction. The store holds a note saying the team uses MySQL from an old project, and a newer note saying the team uses Postgres. Both embed similarly. The reranker picks whichever is closer to the query wording, which is not the same as whichever is true. Nothing in the store establishes that one supersedes the other, so recency loses to lexical luck.

Fix this at write time, not retrieval time. Every auto-written memory class needs a conflict key, a cap, and a decay or TTL policy:

memory:
  core:                      # project-level, curated
    max_records: 200
    write: manual
    ttl: none
  episodic:                  # per-session notes, auto-extracted
    max_records: 500
    write: auto
    ttl: 30d
    conflict_key: [scope_id, subject, predicate]
    on_conflict: supersede   # replace, do not append
    decay: 0.9_per_week
  embedding_index:
    rebuild: nightly
    drop_orphans: true

With a conflict key, a new record about the same (scope, subject, predicate) replaces the old one instead of sitting beside it. Then a nightly job removes records whose scope no longer exists and rebuilds the index:

# nightly compaction, run before the index rebuild
psql "$MEMORY_DB" -c "delete from memories where superseded_by is not null;"
psql "$MEMORY_DB" -c "delete from memories where scope_id not in (select id from scopes);"

Without that job, the index is the real memory and the records table is an audit trail nobody reads. A budget matters more than any individual policy. If project-level memory is capped at a few hundred records, every write becomes a decision about what to remove, and that pressure is the feature.

Memory that is written but never retrieved

Writing memory is easy to instrument because it happens after a turn and produces a visible record. Retrieval is invisible unless you make it visible. The failure looks like this: extraction runs on every turn, the store fills up, and the agent’s answers are exactly what they would be with an empty store.

There are two causes. Retrieval never fires, because of a similarity threshold, a scope filter, or a tool the model declines to call. Or retrieval fires but the memory lands somewhere in a long context where it has no effect on the output. Neither shows up in a dashboard that only counts writes.

The cheapest diagnostic is to log what was injected, then test whether it mattered:

import logging

def answer(query, retriever, llm):
    hits = retriever.search(query, k=8)
    logging.info(
        'retrieval ids=%s scores=%s',
        [h.id for h in hits],
        [round(h.score, 3) for h in hits],
    )
    with_mem = llm(query, context=hits)
    without_mem = llm(query, context=[])
    return with_mem, without_mem

Ablation is the honest test. If the two answers converge, that memory is decoration, and it costs tokens and latency on every run. Run this against ten real queries from your logs rather than a synthetic eval set, because the failure is usually query-specific.

If retrieval fires correctly but the answer ignores it, the problem is placement, not relevance. Facts injected at the top of a long context compete with everything after them. Put retrieved memory immediately before the question, or restate the one or two facts that actually bind the answer inside the instruction. That is the same discipline covered in our guide to context engineering.

Memory that outlives the project it came from

Scope is the failure mode people notice last and fix most painfully. A store with one namespace and a user_id column is not scoped — it is scoped only if every retrieval path filters on that column, which is true until someone adds a background summariser or a shared tool that forgets.

The classic incident: preferences extracted while working with client A get retrieved in a session for client B, because both went through the same summariser with a default scope. Nothing crashes, so nobody notices for weeks.

The quieter version is temporal. A record saying the integration uses the v1 webhook endpoint stays ranked as relevant forever, because nothing in it knows the project shipped v2. When the codebase moves, memory has to move with it, which means the record schema needs a version and the store needs a drop-on-bump path.

Practical scoping rules:

• Every record carries a scope key built from stable identifiers (tenant, project, repository), never from a model’s guess.
• The retriever filters on scope inside the query, not through a prompt instruction.
• Scope lifecycle follows the artifact: archiving a project archives or deletes its memory.
• A schema version bump invalidates derived records, not just prompt templates. The same discipline applies to versioning templates so buyers keep their customisations.
• Deletion is a first-class operation with a route, an audit entry and a test.

If you cannot delete a memory without hand-editing a JSON file, you do not have a memory system. You have a log with a search box.

What enough memory actually looks like

Enough is not an agent that remembers everything. Enough is a memory layer where you can answer three questions without opening a notebook: what is in it, what was retrieved on the last run, and what happens if you delete all of it. A system that fails those questions is a liability that grows with uptime.

That implies distinct layers with different lifetimes, not one large store:

The retrieval budget is the other half. Pick a ceiling — a couple of thousand tokens is a reasonable starting point for most chat-shaped agents — and let relevance compete inside it. A retriever that always returns twenty records is not a retriever; it is context filler.

A useful test before adding any memory feature: write down the record you expect to be created, the query that should retrieve it, and the behaviour change you expect. If you cannot write the third one, the feature is speculative and should not ship. Treat memory as a cache with a public API rather than a database with a UI. Caches have caps, eviction policies and metrics; agent memory should have the same three things.

What to do next

1. Put a cap and a conflict key on every auto-written memory class. The shape above is a reasonable starting point; if you do not use a config file, write the equivalent constants somewhere the team can read them.
2. Log retrieved memory IDs and scores on every run for a week. Look specifically for runs where memory was enabled and retrieved nothing.
3. Ablation-test ten logged queries. Delete records whose presence never changes an answer.
4. Add scope keys to every record and move the scope filter into the retrieval query. Then archive one finished project and confirm its memory actually disappears.
5. Write the delete path before your next memory feature, and keep the deletion test in CI. It is the same habit as triaging automations that fail while nobody is watching.

If you would rather not assemble the pieces yourself, the AI Developer Stack Bundle is a $79 one-time download at https://slashmaster6.gumroad.com/l/nulyms: a prompt library, agent framework, deployment tooling and tutorials, pre-configured to work together.

Get AI Developer Stack Bundle

AI Developer Stack Bundle — $79, one-time payment, instant download. See the full breakdown on the review page.

Related reading

• The Ultimate Guide to AI Automation 2026
• How I Built a 10-Product Digital Business
• Building an AI Content Factory