TL;DR
An agent improves across sessions only if it has a memory system with write paths, read paths and housekeeping, not just a bigger context window. Virdi splits that system into five layers: working, episodic, semantic, procedural, and a meta-memory control plane. Her core claim: "Context engineering decides what the model sees in this turn. Memory decides whether your agent compounds or rots."
The post's real value is its list of failure modes. Teams log traces and never read them back when planning. They pile up facts without resolving entities or contradictions. They hard-code prompts and never learn from failures. Nothing garbage-collects any of it.
Source: LinkedIn post by Shivani Virdi, published 2026-11-02, with an infographic credited to blog.neosage.io. There are no outbound links. This summary is based on the full post text, the infographic and the top comments, all read on 2026-11-03.
How the layers connect
Only the episodic write sits on the request path. Semantic extraction and procedural reflection run asynchronously, so facts and procedures trail the episodes they're distilled from. Every turn also pays for three planning-time reads. The post frames this as "episodes become facts and procedures; meta-memory keeps all of them clean."
Layers and how each one fails
Every layer fails the same way: the store exists, but the operation that keeps it useful is missing.
| Layer | What it holds | Read at planning by | Missing op the post calls out | Symptom |
|---|---|---|---|---|
| Working | Turn buffer, tool calls, intermediate reasoning; capped by the context window; reset at session end | Already in context | A compaction policy (truncation, summarization, hierarchical pruning each lose different things) | Dropped critical state or a blown token budget |
| Episodic | Append-only, time-indexed traces of calls, results, errors, user state | Similarity, time window, user scope | Retrieval at planning time (traces are logged only for debugging) | Every session behaves like the first |
| Semantic | Entity store: users, accounts, documents with typed attributes | Entity ID or similarity | Deduplication, entity resolution, contradiction handling during extraction | Retrieval serves contradictory facts |
| Procedural | Versioned skill registry for recurring task patterns | Task type or input pattern | A reflection loop that rewrites procedures from failures, plus versioning | The same mistakes repeat across sessions |
| Meta | Retention, decay, compression and forgetting policies over the other four | Not read; runs offline, on a schedule or memory thresholds | Archive, dedupe, deprecate unused procedures | Unbounded growth, slower retrieval, stale entries win |
The infographic maps each layer to a brain region (prefrontal cortex, hippocampus, anterior temporal lobe, basal ganglia with cerebellum, anterior prefrontal cortex). The mapping is a mnemonic, not a design argument.
What the model leaves out
The stack has write paths and garbage collection, but nothing that judges whether a write was correct or allowed. The strongest comments all point at that gap.
No outcome signal. Meta-memory can archive and dedupe, but it can't tell which memories led to a good result. Ron Izraeli suggests logging which memories each turn used and whether the outcome was verified. That gives decay and deprecation a real signal instead of just age or access counts.
Unchecked self-modification. The reflection pass writes procedures asynchronously, so a bad lesson spreads to every later session. Anthony Muniz gates procedure writes on an eval set plus a human reviewer. On his team, an LLM judge scored their changes +62 while a human specialist scored the same cases 0.
Authority and provenance. Jonathan Lai notes that none of the layers says what the agent is permitted to do with what it recalls, so a recalled fact can quietly act as authorization. He also points out that an offline job rewriting the record with no independent check amounts to evidence tampering. Episodic memory needs to be immutable and auditable, and meta-memory needs an authorization model.
No memory evals. Akhil Meesala asks for measurements of stale facts, contradiction rate and retention quality. Without them, "the stack rots" can't be observed.
Negative examples. Ayush Sharma injects recent failed tool calls at planning time as "don't repeat this" context. That's a cheap version of procedural learning you can ship before building a reflection loop.
The post also doesn't cover cost and latency. It names three planning-time reads per turn and a synchronous trace append, but gives no budget for retrieval latency, extraction cost or storage growth.
Review checklist for an agent architecture
Is there an explicit compaction policy for working memory, and do we know what it drops?
Are traces queried at planning time, not just written for debugging?
Does fact extraction resolve entities and contradictions, or does it only append?
Are procedures versioned, and is each change gated by evals (and a human for high-risk ones)?
Do we log which memories a turn used and whether its outcome was verified?
Is the episodic log immutable, and are rewrites by the offline job authorized and audited?
Do retention and decay run on a schedule, with metrics for staleness, contradictions and storage growth?
Does recalled content stay separate from permissions, so remembering something never grants the right to act on it?
Related index entries
This is R002 in the research index, filed under Agent architecture › Memory and context.
R001 Scaling Git at OpenAI (Pando) is a weak link. Both pieces argue that agent capability depends on the system around the model. Both hinge on a consistency tradeoff: R001 relaxes repo-wide ref snapshots to causal consistency, and here the open question is how contradictory facts get resolved in semantic memory.