Ask your agent what Dana owns. If the answer comes back as three paragraphs of plausible prose instead of a list of fourteen accounts, you did not build memory. You built search, and you pointed it at the wrong kind of question.
If you only have a minute, here's what you need to know.
- "What does Dana own?" is a question about relationships. Fourteen CRM accounts, three production services, two contracts, one runbook. That is a graph. Vector search returns passages that sound relevant, and no amount of embedding quality turns a passage into a complete list.
- Four kinds of memory, four different stores. A graph for relationships, an append-only log for what happened, git for procedures, an expiring cache for the current turn. The storage follows the query shape, not the data type. All four end up in one vector store because all four look like text, and text-shaped data is not the same thing as text-shaped questions.
- Memory is what the agent knows. State is where the agent is. Both get called "memory" in architecture reviews, and they fail in completely different ways.
- Lose memory and the agent forgets a fact. Lose state and the agent restarts a task that has been running for three days.
- Revoking Dana's access twice is harmless. Issuing her final paycheck twice is not. Same missing component, wildly different blast radius. Whether repeating an action is safe is a property of the action, and your state layer is what knows which is which.
- The runbook only Dana has ever edited is procedural memory, and it is the most valuable thing in this entire offboarding. It is also the thing nobody thought to capture, because it does not look like data.
If you are just picking this up, here is the whole premise in a paragraph. An agentic system is not a model with some tools bolted on. It is eleven layers, grouped into seven organ systems, and the model is one of them, arguably the least interesting one. To keep it concrete, the series walks a single ordinary event through all eleven: a senior engineer, Dana Okafor, gives two weeks' notice. Offboarding one person happens to touch every layer, which is what makes it a good way to see the whole body at once. Part 0 drew the map, and the posts since have gone organ by organ.
In Part 1 the request got in the door and the agent got a name. In Part 2 the brain stem decided what to do. In Part 3 the bloodstream carried that plan out to real systems. All of that assumed something nobody said out loud: that the agent knows things, and that it remembers where it got to. Two layers supply that. Memory and Knowledge is what the agent knows. State and Persistence is where the agent is.
Teams collapse these into one word and build one of them. The half you skip is the half that decides whether a three-day job survives a bad night.
What does Dana own?
Start with the question the whole layer exists to answer, because it is the question that breaks the usual approach.
Dana is a senior engineer. Before the agent can plan a single subtask, it has to know everything she owns:
- 14 CRM accounts
- 3 production services, where she is on-call primary
- 2 contracts, where she is the technical approver
- 1 runbook, which she is the only person to have ever edited
Miss one contract and an approval chain silently breaks two months from now. Miss one service and a pager goes to a person who left.
Now consider how most teams would answer it. They would embed the company's documents, wikis, tickets, and CRM notes into a vector store, retrieve the chunks most similar to "what does Dana Okafor own," and hand those to the model. This is the RAG pipeline, and it is genuinely useful for a large class of questions.
It cannot answer this one.
Vector search retrieves passages that resemble your query. It does not enumerate a set. Ask it what Dana owns and you get the six chunks that mention Dana most similarly, which might be four of the fourteen accounts, a Slack thread about an outage, and an old performance review. The response will read fluently. It will be incomplete, and nothing in the output tells you which ten things are missing. Push the embedding quality higher and you get better-sounding chunks. You still do not get a list.
What answers the question is a knowledge graph. Dana is a node. Each account is a node. "Is the owner of" is an edge. Asking what Dana owns is a traversal, and a traversal returns all fourteen or it returns an error. That difference is the whole argument. A graph can be complete and can tell you when it isn't. A pile of embeddings can only be similar.
This is where the knowledge graph stops being an architecture-diagram box and starts earning its cost, which is real. Graphs need modeling, ingestion, and maintenance, and they go stale in ways a vector store does not. Plenty of agent use cases never need one. The ones that do are the ones where an incomplete answer is a wrong answer, and offboarding is squarely in that set. So is anything touching entitlements, ownership, org structure, lineage, or approval chains.
Vector search and graphs are answering different question shapes. "What do we know about X" is similarity. "What is connected to X, and did we get all of it" is traversal. Most enterprise agent work is full of the second kind, and most enterprise RAG stacks only implement the first. I made the broader version of this case in Agentic Memory: Why Bigger Context Windows Won't Save Your Enterprise.
Four kinds of memory, and four different places to put them
"Memory" gets used as a single word for at least four different things. Dana's offboarding needs all four, and they are not interchangeable. The part that decides your architecture: they do not belong in the same database.
Semantic memory: the facts, and what connects them
Dana is a senior engineer, US-based, hired on a certain date, four months short of a vesting cliff. She also owns fourteen accounts, three services, and two contracts. Both of those are semantic memory, and they are two different query shapes wearing the same coat.
Where it lives: a knowledge graph for the relationships, a vector store for open-ended recall over documents. Neo4j or Cosmos DB with a graph API on one side; pgvector, Azure AI Search, or any of the managed vector stores on the other.
Why both: "What is connected to Dana, and is that all of it" is a traversal, and only a graph answers it completely. "What does our policy say about non-competes" is a similarity question, and a graph is the wrong tool for it. Most teams build the vector half, then start asking traversal questions of it, and get fluent partial answers back with nothing marking them as partial.
Episodic memory: what actually happened
This run recorded what it did, in order:
- Classified Dana as voluntary and regretted
- Planned twelve subtasks with ordering constraints
- Hit a rate limit at 3:40 am on day two
- Failed over to a backup provider
- Resumed from a checkpoint written two minutes earlier
Nine months later somebody asks why her production access was cut on day fourteen instead of day one. Episodic memory is the only thing that can answer.
Where it lives: an append-only, time-ordered event log. A Postgres table you only ever insert into, Azure Data Explorer, or a purpose-built event store. The defining property is that nothing in it is ever updated.
Why append-only: you query episodes by time and entity, in order, which is exactly what a log is built for and exactly what a vector index is not. The immutability is the point. An episodic record that can be edited is a record nobody can rely on later, and later is the entire reason you kept it. This is close cousin to the audit log that shows up in Part 5, with one difference worth keeping straight: the audit log exists for humans and compliance, while episodic memory feeds the agent's own reasoning. Same events, different consumer, usually different retention.
Procedural memory: how it is done here
The runbook only Dana has ever edited is procedural memory, and it is the most valuable artifact in the entire offboarding. It encodes which service has to be drained before failover, which alert is safe to ignore, and which downstream team to warn first. None of that is written anywhere else. When Dana leaves, it leaves, unless something captures it.
Where it lives: version-controlled text under review. Markdown in git.
Why not a database: a procedure has to be diffed, reviewed, blamed, and rolled back. When the failover order changes you need to see what changed, who approved it, and how to put it back if it was wrong. Git gives you all four for free. A vector store gives you none of them, and what it hands back is a fuzzy paraphrase of a procedure that had to be exact. I made the longer case for durable text in Why Your MD Files Will Never Go Out of Style.
That is also the real knowledge-transfer problem, and it belongs to the memory layer. The agent offboarding Dana should be reading her runbook into procedural memory, not filing it in a wiki nobody opens. The wiki is where knowledge goes to become inaccessible.
Working memory: the current turn
The conversation so far, the subtask in flight, the record the agent just read. It is the smallest of the four and the most temporary, and it is the one everyone conflates with the other three because it is the one visible in a chat window.
Where it lives: process memory, backed by a fast key-value store with a TTL. Redis is the usual answer.
Why so disposable: working memory is hot, small, and cheap to rebuild. You want it fast and you want it to expire on its own, because stale working memory is worse than none. The moment you need it to survive a restart, it has stopped being working memory and become state, which is the next section and a different guarantee entirely.
The storage follows the query shape, not the data type. All four of these look like text, which is exactly why they end up in one vector store. Text-shaped data is not the same thing as text-shaped questions. Ask a traversal question of an embedding index and you get a confident partial list. Ask it for the diff of a procedure and you get a paraphrase. Build only the vector store and you have covered one of the four, which is why so many agent programs feel like they have memory and behave like they have amnesia. I wrote about that gap directly in Your Agent Isn't Learning. It's Taking Notes.
State is where the agent is
Everything so far is what the agent knows. The second layer is a different question entirely: where is the agent right now?
Dana's offboarding runs for fourteen days. It has roughly twelve subtasks with ordering constraints. It gets interrupted at 3:40 am on day two when the model provider rate-limits, and it waits on a human approval before the final paycheck goes out. A process shaped like that has to be able to stop and resume without losing its place. That is State and Persistence, and it carries four things:
- Conversation history. What was said across every session, not just this one.
- Agent state. Where the run got to, and what it has already finished.
- Agent registry. Which agents, and which versions of them, are in play.
- Eval store. How the thing has performed over time.
In Part 3 the gateway failed over to a backup provider and the job resumed from a checkpoint written two minutes earlier. That checkpoint is this layer. The fallback chain gets the credit, but a fallback with nothing to resume from just restarts the job. Failover without state is a retry from scratch, and on day two of a fourteen-day process, a retry from scratch is not a recovery.
Now the distinction that almost nobody draws. Losing memory and losing state are different failures.
Lose memory and the agent forgets a fact. It re-reads Workday, re-queries the graph, and asks a question it already asked. The cost is tokens and time, and it is annoying.
Lose state and the agent forgets what it already did. That is a different animal, because the agent's next move is to do it again.
Watch what that means against Dana's actual task list. The agent revokes her Okta, Slack, GitHub, AWS, VPN, and badge access. If state is lost and it revokes all six a second time, nothing happens. The access is already gone. The operation is idempotent, and running it twice costs you an extra line in a log.
Then the agent computes Dana's final paycheck: prorated salary, plus unused PTO, plus forfeited equity, minus the unreturned laptop. A human approves it. Payroll executes it. If state is lost after that approval, the agent's next move is to compute and submit the final paycheck again. Now you have paid a departing employee twice, and you are recovering the money from someone who no longer works there.
Both failures are the same missing component. One produces a redundant log line. The other produces a call from your CFO. The difference is not how sensitive the system is. It is whether the action can be taken twice safely.
That property has a name, idempotency, and it is the thing your state layer exists to respect. Revoking access is idempotent. Issuing money is not. Sending a notification is not, in the sense that your departing engineer does not need four copies of the same email. Closing a ticket is. Every action in your agent's repertoire sits on one side of that line. The state layer is what lets the agent know which side it is on before it acts a second time.
This is also why "we'll just add retries" is not an answer. A retry is a bet that repeating the action is free. For most of Dana's task list that bet pays. For the part involving money it does not, and retries alone cannot tell the difference.
Where state lives: a durable transactional store, with an idempotency key on every action that changes something. Postgres or Cosmos DB will do, with a unique constraint on the key. Before the agent submits payroll it records the intent under a key derived from that specific action, and the store rejects the second write. The checkpoint tells the agent where it stopped. The idempotency key is what keeps it from paying Dana again while it works that out. Neither of those belongs in the same store as your embeddings, and neither is optional once a process runs longer than a session.
Why the demo never shows you this layer
Every organ system in this series has a version of the same problem, and memory has the cleanest one.
A demo is short. It runs for forty seconds, in one session, with no interruption. In forty seconds, the conversation context is the memory, and there is nothing to persist because nothing was interrupted. The vector store looks like it is working, because the demo asks a similarity question. State never gets exercised, because state exists for the gap between Tuesday and Thursday.
So the demo shows an agent that appears to remember, and it is really just holding a conversation. You cannot tell the difference between real memory and a long context window until the session ends. That is the trap in this layer, and it is why memory problems surface in week three of production and never in the pilot.
Dana's offboarding fails the demo shape deliberately. It spans fourteen days, it gets interrupted, it waits on a human, and it asks a question that similarity cannot answer. Those are the conditions under which this layer is load-bearing, and they are precisely the conditions a demo removes.
Three questions for your own memory
You are running an agent program, or funding one. Three questions tell you whether its memory holds.
Ask your system a question with a complete answer, and check whether you got all of it. Pick something with a known count, such as which accounts a person owns or which services a team runs. Then verify against the source. If the agent returned a fluent partial list and nothing flagged it as partial, you have similarity where you needed traversal. That failure is silent, which is what makes it dangerous.
Kill your agent mid-task and restart it. Not in a test harness. In a staging run of something real that takes longer than one session. Does it pick up where it stopped, or does it start over? If it starts over, walk the task list and find the actions that are not safe to repeat. Those are your incidents, and you have not had one yet only because nothing has crashed at the wrong moment.
Ask where the runbooks live. If the answer is a wiki, or a person's head, your procedural memory is a document you hope someone reads. The knowledge Dana carries is the whole reason offboarding is hard, and it is the part no amount of access revocation addresses.
Most teams can answer none of the three cleanly. That is not a failure of skill. It is the result of one word, "memory," doing the work of two layers, four memory types, and a durability guarantee that nobody wrote down.
What the memory decides
The front door gave the agent a name. The brain stem gave it a plan. The bloodstream carried that plan out to real systems. Memory is what makes the plan correct, and state is what makes it survivable.
Correct, because a plan built on an incomplete picture of what Dana owns is a plan that misses a contract. Survivable, because a fourteen-day process that cannot remember what it already did will either stall or repeat itself, and one of those repeats is a paycheck.
The model will keep getting better at reasoning over what you give it. It will not tell you that the list it received was missing ten accounts. It will not know that it already submitted payroll. Knowing what you know, and knowing where you are, are not model capabilities. They are things you build, and they are the two most commonly skipped layers in the entire anatomy.
Next: The Immune System. Autonomy is a dial rather than a switch, and reversibility is what sets it. Revoking production access runs unattended. A paycheck stops and waits for a human.
Matthew Kruczek is Managing Director at EY, leading Microsoft domain initiatives within Digital Engineering. Connect with Matthew on LinkedIn to discuss the memory and state layers underneath your agent program.
References
- Anthropic. "Building Effective Agents." December 2024.
- Gartner. "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027." June 25, 2025.
- Matthew Kruczek. "Agentic Memory: Why Bigger Context Windows Won't Save Your Enterprise." matthewkruczek.ai, 2026.
- Matthew Kruczek. "Your Agent Isn't Learning. It's Taking Notes." matthewkruczek.ai, 2026.
- Matthew Kruczek. "What Is an AI Second Brain, And Why Do I Care?" matthewkruczek.ai, 2026.
