Pattern Matrix/White Paper/M5

Problem

An agent can complete the same class of task repeatedly and still start from scratch each time, rereading references and rediscovering the same sequence. The successful path disappears when execution ends because it was never converted into a reusable process asset.

Procedural memory extracts triggers, steps, tool dependencies, and acceptance checks from a verified run and stores them as a reusable skill. It also gives organizational know-how a machine-readable form that people can review and version.

Classification: 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.

Solution and mechanics

1. Three-stage loading: At startup, load only each skill's name and description (discovery); read the full SKILL.md when a task matches (activation); load scripts and resources on demand during execution. This prevents the whole library from occupying startup 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 complex task succeeds, the agent analyzes the trajectory and writes a candidate skill describing input, tool sequence, and output contract. Triggering should consider complexity, reuse value, and user corrections rather than a fixed tool-call count.
4. Human- and machine-readable format: Use markdown plus YAML frontmatter so people can review it, git can diff it, and an agent can load the same source.
5. Two compilation levels: Instruction assets use a SKILL.md, runbook, or workflow while preserving agent judgment for exceptions. Executable assets compile stable calculations or operations into code; runtime work is reduced to intent matching, parameter validation, and invocation. This reduces generation variance when the intent space is bounded, while permissions, receipts, and failure handling remain mandatory.
6. First-run certification: Exercise a candidate in replay, shadow, or a controlled environment with known success cases, failures, and boundary conditions. Promotion to active records reviewer, evidence, and dependency versions.
7. Lifecycle management: Track use count, success, human correction, and dependency versions. A trigger, tool schema, or service change moves the asset to needs_revalidation. Retirement preserves the reason and a rollback version.

Applicability

• Periodic, templated tasks: The same class of task recurs, has a relatively stable successful path, and has clear entry and exit conditions. Cluster configuration changes, batch restarts, and backup and restore are common examples.
• Distilling enterprise process: A law firm's client-tiering logic, a hospital's emergency triage, or a company's refund flow can be written into SKILL.md as a reviewable organizational asset.
• 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.

Known failure modes

• 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.
• Heavily compiling an open task space: Executable assets need enumerable intents and stable inputs. When request structure keeps changing, return to instruction assets or continued exploration.
• 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.
• Compiling code without its contract: The procedure runs, but preconditions, permission scope, acceptance, idempotency, and rollback are absent. It produces unexplained side effects faster.
• Calling an asset after dependencies change: Tool parameters, data schemas, or policy change while the skill remains active. Dependency versions must participate in certification and invalidation.
• A library that only grows: Without a lifecycle, stale, low-success-rate skills keep misleading the agent.

Verification and metrics

• Reuse rate: The share of similar tasks that select an existing skill instead of exploring from scratch. Interpret it together with success and human-correction rates.
• Skill success rate: The share of tasks that succeed after calling a skill. A sustained decline from its own baseline may indicate stale infrastructure, triggers, or acceptance checks.
• Token / time cost: Compare skill reuse with exploration on comparable tasks while checking output quality and safety.
• 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.
• Certification validity: Verify that active assets still match current tools, schemas, policies, and test evidence.
• Fallback and human-takeover rate: Check whether executable assets stop safely at boundary conditions instead of improvising.

Reference implementation

Skill = the structured form of a SKILL.md:
                name / description (used for discovery) / body (workflow + best practices)
                triggers[] / preconditions[] / steps[] / failure_handling[]
                mode(instruction|executable) / source(human|agent|refined)
                acceptance[] / permissions[] / idempotency / rollback
                dependency_versions{} / status(candidate|active|needs_revalidation|retired)
                review_evidence[] / use_count / success_rate
            SkillLibrary:
                discover()                    → at startup, return only name + description
                activate(task, top_k)         → match trigger, scope, versions, and preconditions
                certify(candidate, replay_set)→ publish after replay, boundary cases, and review
                mark_used(name, success)      → record the success rate after execution
                distill_from_trajectory(...)  → create a candidate when complexity, success, and reuse criteria hold
                invalidate_on_dependency(...) → move to needs_revalidation after dependency change
                retire(...)                   → leave the active set with reason and rollback version
            

Distillation creates a candidate, not a production capability. Publication validates triggers, input range, permission, acceptance, and fallback, then records dependency versions. Auto-distilled and human-authored skills retain different trust levels.

Illustrative scenario

Consider an operations team using a DevOps agent for recurring Redis configuration changes, Kubernetes restarts, and PostgreSQL backup and restore. Reviewed runbooks live under runbooks/; auto-distilled candidates live under auto-skills/ and enter a review queue. Triggers use testable keywords or regular expressions, preconditions check access and namespace, and each step is idempotent or includes rollback. Candidate skills run in shadow or replay before human approval. Any time or token reduction must be measured against comparable local tasks.

Related 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.
• Approval Gate and Guardrail Sandwich: Executable procedural memory shortens the reasoning path but does not remove approval, parameter validation, or post-action acceptance for high-risk work.

Design conclusion

Procedural memory turns one successful run into a reviewable capability asset. Its value comes from stable triggers, explicit contracts, and continued certification; storing the trajectory alone is insufficient.