Procedural Memory: How Agents Remember How to Act

Tell an agent “always run tests before pushing” and watch what happens next week. If it pushes untested code again, the correction landed in a diary. If it just runs the tests - unprompted, forever - the correction landed in procedural memory. This is the type that changes what the agent does, not what it can recall. It comes in two main forms.

Form 1: Standing instructions - rules the agent always carries

The simplest procedural memory is a persistent instruction set loaded into every session: a file of rules that travels with the agent.

The everyday example is the CLAUDE.md / AGENTS.md pattern from coding agents: a file in your repository - “use pnpm, never npm; run make test before committing; our API errors follow RFC 7807; don’t touch legacy/” - automatically included in the agent’s context every session. Nobody retrieves it; it is simply always there, shaping behavior. Teams routinely maintain these files like documentation, because that’s what they are: documentation the agent actually obeys.

Three properties make standing instructions the workhorse form:

• Always-on. No retrieval step to miss. The rule applies even when nobody remembered it was relevant - which is exactly when rules matter.
• Inspectable. It’s a text file. You can read precisely what behaviors the agent carries, edit them, version-control them, review them in a PR.
• Expensive real estate. It ships with every call, paying tokens every time (Blog 2). So it must stay small and sharp - a few hundred lines of high-value rules, not a wiki. The moment it bloats, context rot starts eating its own rules.

Form 2: Skill libraries - whole procedures on the shelf

Rules fit in a line; procedures don’t. “How to set up a rate limiter in our stack” is fifty lines of steps and code. Skill libraries store such procedures as retrievable units: each skill = a name + a short description (“when to use me”) + the full procedure (steps, code, checklists). Descriptions are indexed for search; when a task matches, the skill body is pulled into context and followed.

The landmark demonstration is Voyager (2023): a Minecraft-playing agent that, whenever it solved something new, saved the working code as a named skill (“craftStonePickaxe”) in a library - then retrieved and composed old skills for harder goals. Skills built on skills; competence compounded. The same pattern now runs in production coding agents as skill/command files (e.g., a skills/ folder of markdown procedures - “how we do database migrations” - loaded on demand).

The design split to remember: standing instructions are always-on and tiny; skills are on-demand and rich. Rules you must never break go in form 1; recipes you sometimes need go in form 2. Confusing the two either bloats every call or lets critical rules get missed.

The loop that makes it memory: learning new behavior

A hand-written rules file is configuration. It becomes memory when the agent’s own experience writes it. The loop:

1. Experience: the agent pushes untested code; the build breaks; Maya corrects it. (Or: the agent notices its own repeated pattern.)
2. Distill: reflection (Blog 4) turns the episode into a candidate rule: “Before any push, run the test suite.”
3. Install: the rule is appended to the standing instructions - or saved as a skill; ideally with provenance (“learned from incident, July 12”).
4. Behave: every future session carries the rule. The mistake is now structurally hard to repeat.

This is the “self-editing prompt” idea: the agent’s instruction file is writable by the agent (MemGPT/Letta made this explicit - the agent has tools to edit its own persistent memory blocks, including its persona and rules; Blog 10 goes deep). It is also the mechanism behind product features where an assistant “learns your preferences”: your feedback is being distilled into standing instructions attached to you.

Two safety rails, because self-modifying behavior can go wrong:

• Guard the installs. A rule distilled from one grumpy comment shouldn’t override a core behavior forever. Production systems gate step 3: require repeated evidence, keep learned rules separate from human-authored ones, cap the learned section’s size, and make everything reviewable and reversible.
• Watch for rule conflicts. “Be concise” (learned in January) vs “explain your reasoning fully” (learned in March). Like semantic memory’s truth problem, procedural memory needs reconciliation - new rules should be checked against existing ones, merging or superseding rather than piling up contradictions.

Where the value shows up

Procedural memory is arguably the most underrated type commercially, because its effect compounds:

• Corrections become permanent. The user who says “stop doing X” never has to say it again. This single property converts frustrated users into loyal ones.
• Onboarding disappears. A new session - or a new teammate’s session, if instructions are shared at team level - starts with all the house rules already active.
• Competence accumulates. With a skill library, every solved-hard-problem becomes a reusable asset. The hundredth week’s agent is meaningfully better than the first week’s, on the same underlying model.

And one warning: procedural memories are the highest-risk writes in the whole system. A poisoned semantic fact misinforms one answer; a poisoned rule corrupts every future action (Blog 12 covers this attack surface). Write-time review matters most exactly here.

Quick recap

• Procedural memory = remembered behavior: it acts without being asked, unlike semantic memory which answers when asked.
• Form 1: standing instructions - always-on, tiny, inspectable (the CLAUDE.md pattern). Form 2: skill libraries - on-demand, rich procedures (the Voyager pattern). Rules always-on; recipes on-demand.
• It becomes true memory via the loop: experience → distill → install → behave. Self-editing instructions with guardrails: evidence thresholds, separation of learned vs authored, size caps, reviewability.
• It needs reconciliation (rules conflict) and protection (highest-value target for poisoning).
• Commercially compounding: permanent corrections, zero re-onboarding, accumulating skills.

We now know all four memory types. Next, we descend into machinery: where memories physically live - files, vector databases, knowledge graphs - and how to choose.