What Is Agent Procedural Memory? (And How It Differs From Semantic Memory)

Semantic memory is what. Procedural memory is how. Only one of them is hard.

Think about assembling IKEA furniture.

You follow the manual, and you bump into a lot of things that don't work out. The dowel goes in before the panel, not after. That bag of screws has two sizes in it and they look identical. The backboard only fits one way round, and you find that out after hammering it in the other way.

Now assemble the same thing a second time. If you learned anything from the first attempt, you don't hit those problems again. You know which steps to do first. You know what to do the moment you open the box.

That difference — between having the manual and having built it once already — is procedural memory. And unlike with your own hands, you can write those steps down clearly, share them with other people, and reuse them next time.

First, why an agent needs memory at all

A language model is stateless. Every call starts from nothing. The weights hold a great deal of general knowledge and none of your specifics — not your repo, not your conventions, not the thing that broke last March.

The context window looks like memory but isn't. It's working memory: whatever you send this time, re-sent and re-paid for on every single call, and gone when the session ends. Making it bigger doesn't change what it is. And fine-tuning, the other obvious answer, is a poor fit for anything that changes weekly — you don't retrain a model because a deploy script moved.

So anything an agent should still know tomorrow has to live outside the model and be put back in at the right moment. That's what "agent memory" means, and people generally sort it into three kinds:

• Semantic memory — facts. The billing service runs on Postgres.

• Episodic memory — events. On Tuesday, Alice asked for a refactor.

• Procedural memory — know-how. How we cut a release, and what breaks if you skip a step.

The first two are broadly understood and increasingly boring to build. This post is about the third, which is neither.

What procedural memory actually is

Procedural memory is stored know-how: how a task is done, in what order, with which conditions and caveats.

Not the fact that your team deploys on Tuesdays. The whole procedure — tag the commit first, then run deploy.sh --prod, and if the migration touches the ledger table run it inside a transaction, because we corrupted it in March.

A useful test: could a competent new engineer do this correctly without asking anyone? If yes, it's documentation, or it's obvious, or your tooling already enforces it. If no — if they'd have to ask someone, dig up an old thread, or break it once to find out — that's procedural memory. It's the knowledge currently living in the heads of the three people who've been there longest, which is also why it's the kind that walks out the door.

What a stored procedure contains

This is where recent research is more precise than most explainers. The ProcMEM work (ICML 2026) defines a learned skill as three things:

• Activation conditions — when this procedure applies

• The execution procedure — the steps

• Termination conditions — when it's done, or when to bail

That's a far better answer to "what do I store" than the usual "learned behavioral sequences." A procedure without activation conditions is just a document sitting in a folder. A procedure without termination conditions is how an agent ends up looping.

It maps onto the furniture, too. When you open the box is an activation condition. Sort the screws before you start is a step. Stop when the back board is seated is termination.

The part that makes it memory: dead ends

Most systems record what happened. Procedural memory is only worth having if it records what didn't work — the dowel that went in the wrong order, the screw bag with two sizes. A procedure that captures only the happy path is a manual, and you already had a manual.

The research bears this out. ProcMEM refines skills using what the authors call semantic gradients — natural-language corrections extracted from trajectories after the fact — with a gate that only admits skills that actually improve. In plainer terms: the agent tries, fails, writes down what the failure taught it, and keeps the lesson only if it helps next time.

A companion paper introduces AFTER, a benchmark of 382 realistic enterprise tasks across six professional roles and 22 procedural skills. A single refinement cycle produced aggregate gains of 3.7 to 6.7 points, and skills distilled from multiple model traces reached 73.1% cross-model accuracy — better than any single-model source. Learning from varied failure beats learning from one clean run.

It didn't start with LLMs

Worth saying plainly, because the category gets marketed as new: procedural memory predates language models by decades.

A Zapier zap is procedural memory. So is an n8n workflow, a Makefile, a CI pipeline, a runbook in a wiki. Each encodes how an organization does something, in a form that can be replayed. They have exactly two limitations: a human had to write them, and they can't learn.

That's the actual frontier. Not should we store procedures — we've stored procedures forever. The new part is procedures that get written from experience and improve from it.

Why this matters more later, not less

The interesting case isn't a coding agent. It's a robot.

Tell a physical AI system "go to the kitchen and get me a drink." That one command decomposes into a procedure it has to learn: go to the kitchen first, position so the fridge is within arm range, open the door, grip without crushing, find the person who asked, come back. None of that is in the instruction. All of it is learned, mostly by getting it wrong — reaching from too far away, closing the gripper too hard.

Today the default answer is retraining the policy. Procedural memory offers something much cheaper: the robot records what the dead ends taught it, keeps the correction, and — this is the part that compounds — shares it with every other robot on the system. One machine learns the fridge door is heavier than it looks; none of the others have to.

Same mechanism as the IKEA box. Same mechanism as a release runbook. It just gets obviously valuable when a failed attempt costs a dropped bottle instead of a wasted token.

Where it sits next to semantic and episodic memory

If you've met the taxonomy before, here's the orientation:

Semantic is what. Episodic is when. Procedural is how.

The mistake most explainers make is implying these are three flavours of one problem, solved by the same infrastructure, and that your job is picking which you need. The more useful question is what you'd actually build for each — and the answers are completely different.

Semantic memory is close to solved, and it's usually a database. Facts about a user or a system are rows; most teams extract them from session history into a normal SQL table and query it. There's real engineering in extraction and dedup, but the storage question has a known answer.

Episodic memory is a log. Append-only, timestamped, occasionally summarized. Also a well-understood shape.

Procedural memory is a script — a sequence with conditions attached — and it has no natural home in a table. That's why it's the one where the standard answers run out, and where most of the remaining engineering effort goes.

What procedural memory is not

It is not a database. If you want deterministic lookup of a known key, use Postgres. Procedural memory exists to give AI-native tools the flexibility to do many different things and self-learn, and flexibility is precisely the property a database is designed not to have.

It is not a cache of answers. This is the subtle one. Say your agent looks up the system config, and it takes four steps to find it. The tempting move is to store the result as a memory — now it's a fact, instantly available. But config changes. The moment it does, your agent is confidently serving a stale answer as truth, and nothing in the memory tells it so. The right thing to remember is the shortest route to the config — those four steps, compressed — and re-run them whenever the config is needed. Store the route, not the destination. Facts about changing systems expire; the procedure for checking them doesn't.

It is not RAG over your docs. Same primitives, different object. Document search answers questions; procedural memory encodes decisions, with update semantics and precedence that document retrieval doesn't bother with. Longer version: Beyond RAG.

It is not chat history. A transcript is raw material; the procedure is what survived extraction, and most of a transcript doesn't — the difference between memory and a list of things that happened.

It is not a folder of markdown, past a certain size. That's where most teams start, and it works until every session pays for the whole corpus whether the task touches it or not — the failure we took apart in Too Many CLAUDE.md and Skill Files.

The honest limitation

Procedural memory does not transfer as cleanly as vendors imply, and AFTER says so directly: some skills generalize broadly across contexts, while others "become specialized to role-specific workflows and lose effectiveness under transfer."

Plan around it. A procedure learned in one team's workflow can be actively wrong in another's, which makes scoping a requirement rather than a feature — it's what stops one group's hard-won correction from becoming another group's bug. It also means procedures need versions, because the right method changes and you need to know what the agent believed before, which is the argument behind How X-Mem Thinks. Anyone promising a single universal skill pool is selling the easy version of a problem with a benchmark showing otherwise.

Where this leaves you

Semantic memory: a table. Episodic: a log. Procedural: a script that learns.

The first two have known answers. The third doesn't yet — which is where the leverage is, and why it's what we work on. XTrace stores procedural memory as retrievable, scoped, shareable records instead of files an agent reads at startup: what one agent learns, every agent and teammate knows.

The no-code path is claude mcp add xtrace. For your own agent, the Procedural Memory API is npm install @xtraceai/memory — grab an API key and org ID at app.xtrace.ai, and the docs open with a quickstart. For the map of how this sits against everything else calling itself memory, we wrote that up in Every Tool Solving the AI Memory Problem Is Solving a Different Problem.