Agent Memory Explained: Working, Episodic, Semantic and Procedural

A coding agent once fixed the same bug two sessions in a row. Nobody had told it to, and nothing was wrong with the model.

In session one the agent picked up ticket BUG-142, traced the failure to the order in which migrations ran, changed the code, ran the integration tests and watched them pass. Then the session ended.

Before the next session, the harness wiped the conversation history to keep token costs down. That was a sensible choice, because replaying an ever-growing transcript costs money, adds latency and clutters the prompt. But the transcript wasn't the only thing that vanished. The passing test run lived only in the old context window. No record said the bug had been resolved, and the task tracker still listed BUG-142 as open.

So the second session started, saw an open ticket and did what an open ticket asks for. It investigated, reached the same conclusion and applied the same fix.

The model hadn't forgotten how to solve the problem. The system had failed to keep the fact that the problem was solved.

That failure reframes the usual question. Instead of asking how to give an agent memory, ask what kind of information should have outlived the session. Answering it leads to four separate jobs:

• Working memory: the task currently under way.
• Episodic memory: what happened, and when.
• Semantic memory: what is known to be true.
• Procedural memory: how things should be done.

Memory isn't a single thing. It's at least four jobs, and most memory bugs come from confusing one for another. The split borrows from cognitive science and shows up in research such as CoALA (Cognitive Architectures for Language Agents), which describes language agents in terms of modular memory, structured actions and a decision process.

Before taking the four in turn, two other ideas need separating from memory itself: the context window, and the application's authoritative state.

The context window is a workbench

Context is everything the model can see during a single inference call. Typically that includes system instructions, tool definitions, recent messages, retrieved documents, files being edited, tool outputs and the current plan. It's the agent's active workspace.

It is also temporary. When a session ends, a conversation gets compacted or old messages are trimmed to fit a token budget, the content is gone unless the application deliberately saved it elsewhere. A model has no private recollection of earlier calls. Either the application feeds the information back in, or it connects the model to an external store.

That's why a large window doesn't amount to long-term memory. A bigger context window is a larger workbench, not a filing cabinet. More material stays in view while the agent works, but when the bench is cleared, everything on it goes, unless something files the important pieces first.

In the incident, the successful fix sat on the workbench and nothing promoted it. Even so, keeping the whole transcript would not have been the cure, because a second distinction had been missed.

Memory is not the system's current truth

Compare two statements. One is a memory: "BUG-142 was fixed during yesterday's session." The other is application state: the ticket's status field reads COMPLETED.

They're related, but they're different kinds of thing. The first is a historical record that says an event occurred. The second is the tracker's current source of truth. Memory records what took place, while state records what holds at this moment.

The gap matters because memories go stale, stay incomplete or turn out wrong. Imagine the agent retrieves a note saying BUG-142 is open. That note may have been right when written, yet it proves nothing about today. Before acting on it, the agent should query the tracker, look at the repository, run the relevant tests or try to reproduce the issue. A retrieved memory is a claim about the past, not evidence about the present.

The original incident failed twice over. No useful record of the completed fix was kept, and the authoritative task state was never updated. With that settled, we can sort out what the agent actually needed to retain.

Working memory: the task at hand

Working memory holds what the agent needs to carry on with the current task, and little else. For BUG-142 it might include the task itself, the current hypothesis (the dependency table is initialized too late), the current step (run the integration suite), the latest observation (three migration tests failing) and the files being edited.

It answers practical questions. What's the goal? Which step is underway? What did the last tool call return? Which files changed? What's still unfinished?

In practice it sits in the prompt, in an agent-state object, in a workflow checkpoint or in a session store with a short lifetime. It's temporary and tied to one task, and it isn't meant to be a durable log of everything the system has learned. IBM's description of short-term memory is similar: recent information used for immediate decisions and conversational continuity.

Working memory also differs from the other three types. Episodic, semantic and procedural memories can persist across sessions, while working memory describes whatever is active right now, whether held in the window or checkpointed nearby.

Its short life isn't a defect. Once the task is done, there's rarely a reason to keep every intermediate hypothesis, half-written snippet, failed command or abandoned line of thought. The trouble starts when an important outcome exists only here. In the incident, two things disappeared: the passing test result and the fact that BUG-142 was fixed. The harness treated a significant result as disposable scratch space.

Working memory supports execution. It should never be the only record of finished work.

Episodic memory: the record of events

Episodic memory stores specific experiences. An episode is more than a fact. It happened in a particular situation, usually with a time, an action and an outcome.

For BUG-142, a useful episode could be written as a short structured record:

• Event: BUG-142 reproduced during migration initialization.
• Context: the dependency table wasn't available when the service started.
• Action: changed the order in which migrations execute.
• Outcome: integration tests passed.
• Evidence: commit a7f43d2.
• Time: 8 September 2026, 14:20.

A record like that tells a future agent that this situation has come up before. It helps avoid repeated work, supplies examples and shows which earlier attempts worked or didn't. CoALA separates episodic from semantic memory because a record of an experience serves a different purpose from generalized knowledge.

An episode also isn't the same as chat history. A transcript may hold hundreds of messages, tool outputs, speculation, corrections and repetition. Set a loose line from the raw log, such as "we should probably inspect the initialization order," beside a distilled episode: reordering dependency initialization resolved BUG-142, and the tests went green at commit a7f43d2. The second is far easier to retrieve and far more useful on a later task.

Episodic memory can still go wrong in two ways. The system may keep the action but lose the outcome. A bare "attempted: changed migration order" leaves a future agent unsure whether to try it again. Or the agent may retrieve a success from six months ago after the architecture has changed. Episodic memory preserves the past and doesn't describe the present, which is why each episode should carry its time, context, evidence and outcome.

Semantic memory: what the agent knows

An episode records what happened. Semantic memory records what was learned from it.

The BUG-142 episode can yield a reusable fact: the migration service needs the dependency table to exist before initialization starts. That's no longer about one debugging session. It's a general statement about the system.

Typical entries include which database the service uses, an API rate limit, a rule that customer identifiers must stay out of logs, the repository's architectural pattern, a user's preference for terse technical answers and a requirement that migration scripts stay backward compatible. Semantic memory covers facts, concepts, constraints, relationships and preferences. It tends to be long-lived but has to stay revisable, since facts and preferences change.

The difference from episodic memory is subtle and worth holding on to. The episodic version says BUG-142 happened yesterday because the dependency table was missing at startup. The semantic version says initialization requires the table to exist first. One remembers the experience, the other remembers its lesson.

Its signature failure is staleness. Suppose the team later adopts a new initialization mechanism that no longer depends on the table. If the memory system just appends the new fact, the agent may retrieve both, one saying the table must exist first and the other saying it no longer matters. Now there's memory without clarity. An outdated fact can be worse than no fact, because the agent will act on it with confidence.

So semantic memory needs a correction path, with answers to a few questions. Someone must own updates to a fact. It needs a named source and a last-verified date. When a newer version appears, the old one should be marked as replaced, then either removed or kept as history. Those belong to memory engineering proper. For now, the point is that semantic memory keeps reusable knowledge, not merely a record of an event.

Procedural memory: how work gets done

Procedural memory tells the agent how to carry out a task. It holds skills, workflows, operating rules and repeatable methods.

From the bug, a team might derive a procedure: before running migration initialization, verify the dependency table is available; run the migration integration tests; record the result; update the task tracker; attach the commit reference; confirm the issue no longer reproduces.

That isn't a fact, though it grows out of one. The semantic fact is that the table must exist before initialization. The procedural rule is to verify its availability before initializing. Semantic memory says what's true, procedural memory says what to do. Other examples: rolling back a failed deployment, investigating a payment failure, which tests must pass before a bug is closed, how to review a pull request, when to ask for human approval and which tool has to be called before touching production data.

Implementations range from prompt instructions and versioned runbooks to packaged skills, workflow definitions, plain code or patterns learned from practice. CoALA gives procedures a place of their own in agent memory, tied both to the model's capabilities and to the agent's explicit code.

Because of that, procedures should be versioned like software and not piled up like conversation history. If an organization changes its deployment process, the agent shouldn't retrieve five old procedures and guess which one is current. Anything that runs in production should say who owns it, which version it is, from when it applies, what it covers, what supersedes it and how you know it still works.

In the incident, a missing procedure contributed directly. The agent fixed the code, but no rule required it to turn that success into updated application state. What was absent wasn't a replay of the whole conversation. It was a standing instruction along the lines of: once the tests pass, write down the result and close the ticket. That's a procedural gap.

One bug, five representations

The taxonomy is easiest to see by writing the same bug down five ways.

• Working memory: "Currently fixing BUG-142; the next step is the integration tests." It keeps the current run going.
• Episodic memory: "In session one, BUG-142 was fixed by changing the dependency order, and the tests passed." It preserves an experience.
• Semantic memory: "The migration service needs its dependency table before initialization." It preserves reusable knowledge.
• Procedural memory: "Before initializing migrations, verify the table and run the integration tests." It preserves a repeatable method.
• Authoritative state: status COMPLETED, commit a7f43d2, tests PASSED. It records what the application treats as true.

They're related and not interchangeable. The episode doesn't replace the task record, and the task record doesn't hold everything learned during the incident. The fact doesn't define the full debugging routine, and the routine doesn't prove that a given bug was fixed. Working memory can't be expected to outlive the session.

The system didn't just fail to remember one thing. It failed to turn finished work into the right durable forms.

Each type breaks in its own way

Put everything in one undifferentiated store and diagnosis gets hard. It's better to ask which information job failed.

• Working memory fails when the agent loses its current plan after a reset, usually because task progress lived only in the window or a local process.
• Episodic memory fails when the agent repeats an experiment or redoes finished work, because the earlier event, action or outcome wasn't saved or wasn't retrieved.
• Semantic memory fails when the agent confidently applies an outdated fact, because the fact changed and the old version was never superseded.
• Procedural memory fails when the agent finishes the technical work but skips an operational step, because the workflow was missing, stale, ambiguous or unavailable.
• Authoritative state fails when the agent acts on a wrong task status, because the source-of-truth record wasn't updated or wasn't checked.

Every job deserves its own rules for who may write, how items are fetched, how long they're kept, how errors get fixed and how quality is judged. A vector index can help retrieve several kinds of memory, but the index doesn't decide what type the content is. A workable rule: classify the information before choosing the storage technology.

A short classification checklist

When an agent meets a piece of information, ask these in order.

1. Is it needed only for the current run? Working memory. Think of the current plan, the latest tool result or a temporary hypothesis.
2. Is it a specific event that occurred? Episodic memory. A deployment that failed yesterday, a repair attempt that didn't work, a design the user rejected.
3. Is it reusable knowledge? Semantic memory. Architecture, preferences, domain constraints, business definitions.
4. Is it a workflow, rule or skill? Procedural memory. A deployment procedure, test checklist, tool-use policy or escalation path.
5. Is it the current source of truth? Authoritative application state. Ticket status, account balance, deployment state, inventory, approval status.

One experience often deserves several representations. A failed deployment might produce an episode (it failed at 14:20), a fact (service X needs schema version 17), a procedure (check schema compatibility before deploying) and a state change (deployment rolled back). That isn't wasteful duplication, since each form answers a different question.

What the harness should have done

The context never needed to live forever. What the harness needed to do was promote important outcomes before it cleared the session: write the episode, extract the fact if there was one, add or update the procedure and set the ticket's status with its commit and test evidence.

With that in place, clearing the old conversation is safe. The raw transcript can go because everything worth keeping has been converted into the forms that must survive. Context can disappear. Important outcomes shouldn't go with it.

Where this leads

Classification is the start, and the harder engineering questions come after it. What deserves to be stored? Where should each type live, and who may write it? When is it retrieved, and how does it enter the window? When is it updated, and when does it expire? What happens when two memories disagree, and how do you measure whether memory improved the agent at all?

Those questions make up memory engineering, and none of them can be answered well before the information has been classified. So before picking a vector database, a memory framework or a retrieval strategy, ask what kind of information the agent is trying to preserve.

The goal isn't to make an agent remember everything. It's making sure the useful pieces survive, stored in a shape that fits how they'll be used. Next comes the lifecycle that memory follows: experience, extraction, a decision about what to keep, storage, retrieval, injection into context, verification, action and finally updating or forgetting.