Short answer: It is memory of how to do something well: methods, playbooks, and learned techniques.
Procedural memory is not a diary of events or a list of facts. It encodes approaches that change how work gets done. Agents use it to reuse successful steps instead of rediscovering the same process every time.
Episodic memory records what happened, and semantic memory records what’s true, but neither one captures a third, distinct kind of knowledge: knowing how to do something well. Procedural memory holds methods, approaches, and learned techniques, the kind of knowledge that shapes how a task gets performed rather than describing an event or stating a fact. It behaves differently enough from the other two categories that treating it the same way, especially when it comes to who it belongs to, tends to waste exactly the thing that makes it valuable.
What Actually Distinguishes a Procedural Memory From a Semantic Fact?
A semantic fact states that something is true: a field exists, a policy applies, a person has a certain preference. A procedural memory states a method that works: when asked to filter results by category, use the dedicated category field rather than a generic text search; when a customer mentions a delay, acknowledge it before offering a solution. The difference is between knowing a fact about the world and knowing how to act correctly within it.
This distinction matters because procedural memory is fundamentally learned from experience of doing a task, successfully or unsuccessfully, rather than stated directly the way a preference or a fact usually is. Nobody typically announces “here is a procedure worth remembering” the way they might state a preference outright. It gets inferred from what happened when a particular approach was tried.
Why Doesn’t Procedural Memory Usually Belong to Just One User?
A preference belongs to the specific person who holds it, but a method that works usually generalizes well beyond whoever happened to be involved when it was first learned. If an agent discovers that filtering by a dedicated category field produces better results than a generic text search, that lesson applies to every future request shaped like that one, regardless of which user happens to be asking. Scoping something like this to a single user, the way a personal preference should be scoped, would mean every other user’s identical request keeps hitting the same avoidable mistake, one that’s already been solved once and simply isn’t being shared.
This is why procedural memory frequently makes more sense scoped to the agent or the project as a whole, rather than to an individual person. It isn’t personal information about anyone. It’s the agent’s own accumulated competence at doing its job, and competence learned once is meant to carry forward for every future user it serves, not just the one present when the lesson happened to land.
Should Procedural Memory Always Be Shared Project-Wide?
Not universally, since some methods genuinely are specific to how one particular relationship needs to be handled rather than a general improvement to the task itself. A lesson like “always double-check before quoting a discount to this specific client, since they’ve disputed pricing before” is procedural in the sense that it’s guidance about how to act, but it’s tied to this one client’s history, not a generally better way to handle discount requests for everyone.
The deciding question is the same generalization test used to separate this chapter’s earlier examples: would this method genuinely help with a completely different user’s request, or is it really about how to handle this one specific relationship? Both kinds of procedural memory are legitimate, and the scoping decision has to be made deliberately case by case rather than defaulting to either option automatically.
How Does a System Even Recognize That a Procedure Is Worth Capturing?
Procedural memory is rarely handed over as a clean, explicit statement the way a preference often is. It typically gets triggered by an outcome: a correction after something went wrong, positive feedback after an approach worked particularly well, or an agent noticing on its own that a certain method consistently produces better results than an alternative. Capturing this kind of memory well means paying attention to outcomes and corrections as signals worth extracting from, not limiting extraction to only what a user states directly about themselves.
This connects directly to a pattern already covered when a correction arrives from one agent while the actual behavior that needs fixing sits with a different one: the raw pieces, the goal, the action taken, and the resulting feedback, need to be combined into a single, distilled lesson before they’re genuinely useful as procedural memory, rather than left as separate, disconnected fragments describing what happened around the correction.
How Does Weaviate Engram Store Procedural Memory as Project-Wide Experience?
Weaviate Engram supports exactly this kind of project-wide scoping for topics that represent an agent’s own learned experience rather than information about a specific person. Consider a recruiting-sourcing assistant that reaches out to candidates on behalf of many different hiring teams, and learns, after several campaigns, that a certain approach to outreach messages gets noticeably better response rates:
from engram import EngramClient
client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])
client.memories.add(
"Outreach messages that mention a specific project the candidate has worked on get significantly higher response rates than generic role-fit messaging.",
group="sourcing-experience",
)
No user_id is attached here, deliberately, because this isn’t a fact about one candidate or one recruiter. It’s a method that should improve every future outreach campaign the assistant runs, for any team using it:
results = client.memories.search(
query="What approach to outreach messaging has worked best in past campaigns?",
group="sourcing-experience",
)
The next recruiting team to use this same assistant, on a completely different role and completely different candidates, benefits from this lesson immediately, without having to rediscover it through their own trial and error first. That’s the practical payoff procedural memory offers when it’s scoped correctly: competence that compounds across every future use of the agent, rather than knowledge trapped inside whichever single interaction happened to teach it.
Working memory, episodic memory, semantic memory, and procedural memory cover most of what an agent needs to know about the world, events, and how to act within it. There’s still a further, less obvious category worth naming: memory about the agent’s own memory, knowing what it knows, how confident it should be in a given recollection, and when its own stored knowledge might be incomplete or unreliable. Our next chapter, What is reflective or meta-memory?, takes up exactly that idea.