Procedural Memory in AI Agents
Procedural memory is how an agent stores knowing-how rather than knowing-that. Explicit skills versus weights, why self-written tools are an unreviewed deployment pipeline, and how to version it.
Procedural memory is how an AI agent stores knowing-how rather than knowing-that. Skills, tool definitions, learned routines, the sequence of steps that reliably gets a job done. Where semantic memory holds the deploy script requires an env file and episodic memory holds the deploy failed last Tuesday, procedural memory holds the working deploy procedure itself.
It is the third long-term memory type in the CoALA framework and the one that breaks the tidy analogy, because it lives in two incompatible places.
Explicit versus implicit
Implicit procedural memory is in the model's weights. GPT-class models know how to write a SQL query, structure a JSON response, and follow a ReAct loop because that competence was trained in. You did not put it there and you cannot inspect it. You can only observe it working or failing.
Explicit procedural memory is code and definitions the agent can read and write: a skill library, a set of tool schemas, a file of learned routines. The canonical example is Voyager (Wang et al., 2023), which builds a library of code-based skills while playing Minecraft and retrieves them via dense search when a similar task appears.
The practical difference is accountability. Weights are a black box you rent. A skill library is an artefact you own, review, version, and roll back.
| Implicit (weights) | Explicit (skill library) | |
|---|---|---|
| Inspect | No | Yes |
| Version | Only by changing models | Git |
| Roll back | No | Yes |
| Test | Behaviourally | Directly |
| Changes when | You switch models | The agent or a human writes to it |
The thing to be careful about
When an agent writes its own tools, you have a deployment pipeline with no review step.
That sentence is worth sitting with. A skill library that the agent extends autonomously means code is being written, stored, retrieved and executed without a human in the loop. In a hobby project that is the fun part. In anything regulated it is a finding.
Three controls, roughly in order of how much they cost you:
Version it like code. Skills in git, diffs reviewable, every change attributable. If your skill library lives in a database with no history, you cannot answer what the agent knew how to do last month, and that is a question you will eventually be asked.
Gate promotion. Let the agent draft skills. Require a human, or at minimum a test suite, before a draft becomes retrievable. Most teams that do this find the review load is manageable because genuinely new skills are rarer than they expect.
Scope execution. A retrieved skill runs with whatever permissions the agent has. If you are running MCP tools in an IDE, this is where allowlists become relevant, and it is worth understanding what your allowlist actually permits: see our Cursor permissions reference.
Retrieval
Procedural retrieval is closer to a search over a function library than to semantic recall. What matters is matching the task shape rather than the vocabulary.
Two things help. Index skills by what they accomplish rather than how they are implemented, because the agent is querying with a goal, not an algorithm. And record success rates: a skill that has worked forty times should outrank a superficially similar one that has never been executed. That success signal is the main reason procedural memory improves with use, and most implementations do not capture it.
Where it overlaps with the other types
The three long-term types are not cleanly separable in practice, and pretending otherwise causes design mistakes.
An episode of failure often produces a procedural update: the deploy failed because we skipped the migration becomes a deploy procedure with the migration step made mandatory. That transition, from episode to procedure, is the same consolidation mechanism that turns repeated episodes into semantic facts. It is arguably the most valuable thing a memory system does, and it is the least commonly implemented.
Semantic facts also constrain procedures. The API rate limit is 1,000 per minute should shape any procedure that calls the API. If your semantic and procedural stores do not talk to each other, the agent knows the limit and still writes a routine that exceeds it.
Related reading
OctaMem treats procedural memory as versioned, attributable artefacts rather than opaque stored strings, so you can answer what an agent knew how to do at any point in time. Docs
Frequently asked questions
What is procedural memory in AI?
An agent's store of how to do things: skills, tool definitions and learned routines, as opposed to facts or events.
Where does procedural memory live?
Either implicitly in the model's weights, or explicitly as code and definitions the agent can read and write. Only the explicit kind can be inspected or versioned.
How is procedural memory different from a tool definition?
A tool definition is a static contract you wrote. Procedural memory includes routines the agent has learned or composed, along with a record of whether they work.
Should agents write their own tools?
They can, but treat it as an unreviewed deployment pipeline. Version the library, gate promotion behind review or tests, and scope execution permissions.
What are the four types of agent memory?
Working, semantic, episodic, and procedural, following the CoALA framework.