Pattern Matrix/White Paper/M5

M5 · Procedural Memory

What problem it solves

The agent has handled the same class of task five times and succeeded every time, but every time it started from scratch—reading five references, making three failed attempts, walking the exact same path as last time. When the sixth instance of the same task arrives, the agent walks it again. Tokens burn, time drags, and the user is annoyed. The root problem is that nothing is retained after the agent finishes. That clean "successful path" is lost.

This is exactly what procedural memory addresses: after the agent gets something done, it freezes "how it got done" into a reusable move, and the next time a similar task arrives it loads that move directly and reaches the main path in five seconds. The root problem it solves in one sentence—an agent does not get faster from having done something once. In an enterprise context, it is also the engineering vehicle that distills organizational process into a form the agent can digest—the "know-how" sitting in a veteran employee's head now has, for the first time, a container that can express it precisely.

Why the coordinate is "Memory × Hierarchy"

• Vertical axis · Memory: It encapsulates successful workflows as reusable "skills," corresponding to procedural memory in cognitive science ("how to do"), as distinct from declarative memory ("what is known," which is the object of RAG).
• Horizontal axis · Hierarchy: The skill library itself is layered—from atomic skill to composite skill to workflow, organized in a hierarchy from simple to complex. It shares a column with Layered Retention: Layered Retention is the shelf, procedural memory is the dedicated "moves section" on that shelf.

Core mechanism

1. Three-stage loading: At startup, load only each skill's name plus description (discovery, about 50 tokens/skill); read the full SKILL.md into context only when a task matches (activation, a few hundred to two thousand tokens); load scripts and resources on demand during execution (execution). This is the most correct implementation of procedural memory in terms of token economy—loading all fifty skills at full size would exhaust the context.
2. Two sources: handwritten with care (the Anthropic Agent Skills route—reviewed, versioned, committed to git) and auto-distilled by the agent (the Hermes route—written by the agent itself after finishing a task). The source field affects the trust level.
3. Auto-distillation: After a sufficiently complex task completes successfully (for example, five or more tool calls), the agent analyzes the trajectory, identifies the reusable pattern (input, tool sequence, output format), and writes it up as a structured skill. Simple tasks do not trigger distillation; otherwise the resulting low-generality skills would pollute the library.
4. Human- and machine-readable format: Use markdown plus YAML frontmatter—humans can read it, git can diff it, and the agent can read it too. A format readable by both humans and machines beats any format designed purely for machines.
5. Lifecycle management: Track each skill's use_count and success_rate; automatically evict low-success-rate skills (the moves that keep misleading the agent), and move skills that are not recalled for a long time into a cold tier. Production infrastructure changes, and a stale skill turns from a "move" into a "trap."

Suitable production scenarios

• Periodic, templated tasks: The same class of task recurs, has a relatively stable successful path, and has clear entry and exit conditions. Standard DevOps operations incidents (cluster configuration changes, batch restarts, backup and restore) are the best scenario.
• Distilling enterprise process: A law firm's client-tiering logic, a hospital's five-step emergency triage, a company's standard refund flow—tacit assets that used to depend entirely on senior employees mentoring juniors, that walked out the door when someone changed jobs, and that the wiki captured at maybe ten percent completeness, can now be written into a SKILL.md and become a reusable organizational asset layer.
• Scenarios that require judgment during execution: A skill provides the "usually do it this way" paradigm, and the agent retains its judgment after loading it—deciding which steps to follow verbatim, which to adjust to the current context, and when to abandon the skill and explore instead. This is the key thing that distinguishes it from rigid RPA.

Where it goes wrong

• Forcing distillation when every task is different: Tasks like open-domain research cannot distill a fixed flow; forcing them into a skill is a waste.
• Tasks that run only once: The cost of distillation exceeds the reuse benefit; it should not be done.
• Freezing too early while the successful path is still changing: Freezing before the underlying flow has stabilized turns the skill into a shackle for the agent.
• Adopting procedural memory before the process is mapped out: The same trap as enterprise RAG—wrong schema fields, vague trigger conditions, no lifecycle design, and even the best system spins idle. Map out the process before building enterprise procedural memory.
• Putting auto-distilled skills straight into production: Skills the agent distills itself should enter a "probation period" of dual-track execution (run one pass by the skill and one pass by exploration, and promote only after they agree multiple times), and the first recall should carry an annotation reminding "this was auto-distilled; verify before following it." Auto-distilled and handwritten skills need tiered trust—in enterprise agents this is a compliance requirement.
• A library that only grows: Without a lifecycle, stale, low-success-rate skills keep misleading the agent.

Key metrics

• Reuse rate (rises over time in the healthy zone): the proportion of similar tasks that hit an existing skill rather than exploring from scratch. This is the primary signal of whether procedural memory is working.
• Skill success rate (healthy zone ≥ 80%): the proportion of tasks that succeed after calling a given skill. Dropping below 80% triggers an alert to review whether an underlying service changed and rendered the skill stale.
• Token / time savings (against the exploration baseline): the tokens and time saved by reusing a skill versus doing it from scratch. Done right, a single high-frequency task can save an order of magnitude (for example, thirty thousand tokens plus ten minutes compressed to five thousand tokens plus ninety seconds).
• Auto-distillation promotion rate (a business judgment): the proportion of auto-distilled moves that pass probation and become formal skills; too low indicates a problem with the distillation trigger conditions or the quality checks.

Minimal implementation skeleton

Skill = the structured form of a SKILL.md:
                name / description (used for discovery) / body (workflow + best practices)
                triggers[] / preconditions[] / steps[] / failure_handling[]
                source(human|agent|refined) / use_count / success_rate
            SkillLibrary:
                discover()                    → at startup, return only name + description
                activate(task, top_k)         → when a task arrives, recall the top-K full skills by similarity
                mark_used(name, success)      → record the success rate after execution
                distill_from_trajectory(...)  → auto-distill on 5+ tool calls and success
                evict_stale(...)              → remove low-success-rate or long-unused skills
            

Four engineering points for landing this: use a cheap model plus a structured prompt for the distillation LLM call, with schema validation; the distillation trigger should be more than just "5+ tool calls" (also require success, non-trivial logic between tools, and no repeated user corrections); the lifecycle should track success_rate; and auto-distilled skills should carry tiered trust separate from handwritten skills.

Enterprise landing example

An ops team at a mid-sized company—five to eight engineers managing thirty-odd production services—needs its DevOps agent to catch the standard operations incidents it keeps running into: Redis cluster configuration changes, Kubernetes batch restarts, PostgreSQL backup and restore. Six key decisions: skills split into two classes—runbooks the team writes with care follow the Anthropic Skills route (entering the library only after SRE-leader review, placed under runbooks/), while agent auto-distilled skills go in a separate namespace (auto-skills/, entering the review queue after seven days); trigger conditions are schematized (the frontmatter's triggers field lists keywords or regexes, making "should this skill be used" testable, with rule matching plus an LLM hybrid judgment); preconditions enforce pre-checks (before execution, verify "the current user has SSH access" and "the target namespace exists"—the biggest firewall against production incidents); steps are rollbackable (each step is marked idempotent or carries a rollback, similar to a Saga in distributed systems); success-rate monitoring with alerts (any skill dropping below 80% triggers an alert to check whether an underlying service changed); and auto-distilled moves run dual-track during probation (promoted only after the two results agree five or more times). By the third month of operation, when the opening scenario—"the third time this half year manually changing maxmem-policy"—comes around again, the agent goes through discovery plus activation plus automatic precondition checks plus automatic rollback protection, and a job that was thirty thousand tokens plus ten minutes is compressed to five thousand tokens plus ninety seconds, saving ops time equivalent to half a full-time SRE.

Relationship to other patterns

• Reflection module F2 Skill Package: The two are almost structurally identical in practice—both are skill libraries, both use SKILL.md, both do three-stage loading and lifecycle management. The difference is design intent: M5 emphasizes "store what you learned" (a memory write—after completing a task the agent automatically distills the successful flow into memory), while F2 emphasizes "encapsulate after reflection" (a post-reflection consolidation—the agent consolidates a verified flow into a skill only after reflective evaluation). The same skill library, viewed from the memory angle, is M5's write end; viewed from the reflection angle, it is F2's output end. The course folds it into the 06-03 Skill Package lecture, but in itself it is an independent pattern of the memory module.
• Failure Journal (M4): A twin relationship—together they form the agent's experience base. Procedural memory retains "the work done right," the failure journal retains "the traps stepped into." One records successes, the other records failures.
• Layered Retention (M1): In the same Hierarchy column. M1 is the shelf (the container), M5 is the dedicated moves section on that shelf. The skill library itself is also layered (atomic to composite to workflow).
• RAG (M2): Two complementary kinds of memory. RAG handles declarative ("what is known," fact retrieval), M5 handles procedural ("what can be done," flow reuse). In enterprise agent deployments the two play together.

What the pattern teaches

Procedural memory is not a workflow template; it is the agent's professional competence—it lets the agent acquire a veteran's craft while keeping its judgment, and the agent's value scales with the experience it accumulates rather than with how clever it is today.

This page is part of the ADPS pattern white papers. Back to the pattern matrix, or see the runnable code catalog.