What Is Procedural Memory for AI Agents, and When Is It Useful?

Procedural memory gives an AI agent reusable instructions or executable procedures for a recurring task. Instead of reconstructing the same method each time, the agent can select a stored version, check whether it is appropriate and run it within the task's permissions. It is useful when the repeated part is stable enough to test.

Our reporting, document-processing and monitoring work prompted a practical question: which steps should an assistant compose, and which should it reuse? We built a versioned registry to explore that distinction. This article explains the pattern and the checks needed before relying on it; it is not a claim of measured company-wide savings.

Imagine a talented line cook who invents a great dish on Monday, then shows up Tuesday with no memory of the recipe and invents it again. The food is usually good. But you are paying for invention every night, the dish varies a little each time, and occasionally an experiment misses. A restaurant runs on recipes for a reason.

This guide separates the idea from the implementation. A stored recipe may help with repeatability, but storage alone does not prove correctness, lower costs or permission to run. Our published benchmark articles discuss limited experiments and failures as well as promising uses.

The three types of AI agent memory

People use "AI agent memory" to mean one of three different things, and the distinction matters.

Procedural memory is particularly relevant to recurring operations because the method, not just the surrounding facts, needs to survive between runs.

Procedural memory is muscle memory for software: the difference between knowing about riding a bike and knowing how to ride one.

The insight: store the working code, not a description of it

Suppose an assistant produces a working script that transforms approved analytics exports into a report. Saving only a prose recap still leaves the next session to recreate the method. Saving the script, its inputs and its checks gives the next session an inspectable candidate to reuse.

That is like keeping a restaurant review of the dish instead of the recipe.

A reusable skill can contain instructions, code or both. In our registry, the executable artifact is accompanied by provenance and validation information. That is a different contract from asking an assistant to remember that a previous session went well.

The assistant still has judgment work: choose a suitable candidate, provide valid inputs, check its authority and interpret failures. Reuse should reduce unnecessary reconstruction, not remove those responsibilities.

How it works at Rhize

Our implementation is a loop with five steps.

1. Capture a candidate. Preserve useful working code and the conditions under which it ran. A successful run is a reason to review a candidate, not automatic approval to promote or execute it.
2. Version and record provenance. Bind the artifact to its content digest, inputs, dependencies and verification history. Report unavailable usage or cost data as unavailable rather than inventing a value.
3. Index. Give each artifact a clear task description. Recall reports similarity alongside trust, health and verification information so a plausible match is not mistaken for a safe instruction.
4. Check and run. Use the registry launcher to check the artifact's digest, trust and health before execution. External writes still need the task's authorization; the registry does not grant it.
5. Investigate a failure. Preserve the failed result, identify the cause and review a proposed repair. A changed script is a new candidate requiring the relevant checks. Do not silently bypass a refusal or label an improvised fallback as a verified run.

Example: a document-processing script can retain the same parsing and output checks across batches. The next run still needs valid input files, a compatible environment and verification that the outputs are complete. Whether it reduces total work depends on review and maintenance as well as execution time.

What repeatability does and does not establish

Versioned code makes the chosen implementation identifiable. It does not, by itself, make every execution deterministic: model calls, randomness, live services and changing dependencies can still affect results.

An improvising AI produces work that varies run to run. Usually the variation is harmless. Occasionally it is not: a slightly different report structure, a metric calculated another way, a step silently skipped. For internal experiments, tolerable. For client deliverables, no.

Frozen, versioned procedures change the contract.

• Repeatability. A digest lets you check that you selected the same implementation; tests and environment controls determine how much behavior is repeatable.
• Auditability. A useful receipt connects the artifact version, inputs, outcome and validation. Missing receipts remain a gap rather than proof that a procedure ran.
• Cost visibility. Measure execution, model usage, review and maintenance before claiming savings. A stored script may still call metered services and its cost can change with inputs.
• Versioned improvement. Reviewed fixes can be retained for later runs. They should not overwrite the history of the version that failed.

A pure calculation with controlled inputs can be deterministic. A script that reads live rankings, generates prose or posts to a CRM has additional dependencies and effects. Reusing its code does not make retrying those effects safe.

How to measure whether reuse helps

Choose comparable tasks and define success before comparing methods. Our later articles report small studies, including an invalid early comparison. Those results do not establish a general productivity or cost improvement.

• Baseline. Record how the task is completed without the stored procedure, including all preparation, checking and recovery work.
• Reuse arm. Run the stored procedure on comparable inputs with the same acceptance criteria. Separate deterministic calculations from model decisions and external writes.

Compare completed, accepted outputs as well as timing. Count failed runs, corrections and manual intervention. Keep synthetic fixtures separate from live operational work, and do not treat missing usage data as zero.

What this unlocks for clients

The opportunity is to make the recurring part inspectable and maintainable. That only becomes useful to a client when the procedure fits the task and the resulting work passes review.

Monthly reporting, document processing and data cleanup are reasonable candidates when inputs and expected outputs are well specified. Start with one bounded step, preserve the original workflow for comparison and stop if the stored method no longer fits.

For a reporting workflow, begin with a pure transformation of approved exports before automating delivery. Validate totals and formatting first; treat emailing a client as a separate authorized action.

An owner should decide what evidence is sufficient to adopt the procedure, who maintains it and what happens when it fails.

For the evidence behind this approach, read our companion articles on AI agent memory benchmarks and why our first workflow comparison was invalid. Their limited results are a useful reminder to measure the task you intend to run.

Appendix: how it actually works (for the technically curious)

Storage. A skill is a directory: a markdown spec (SKILL.md) plus the executable scripts it wraps, committed to a Git-backed registry. Nothing exotic, just version control doing what version control does.

Provenance. Each skill carries a sidecar contract: input schema, pinned dependency versions, environment assumptions passed as parameters rather than hardcoded paths, an exit-code and verification contract, and lineage recording what it forked from, what it supersedes, and which routine generated it. Secrets are keychain references, never values in code.

Indexing and retrieval. The plugin uses a separate registry runtime and semantic recall. A result includes provenance and health signals; its similarity score alone does not justify execution. Consult the registry documentation for the current storage implementation.

Execution surface. The plugin wraps a registry CLI through a launcher. The stored artifact's contract determines its inputs, environment and permitted operations; a shell wrapper is not an exemption from access controls.

Where to start. A stable calculation or formatting step is easier to compare than an open-ended workflow with many external dependencies. That makes it a useful pilot, not a guarantee of the largest gain.

Verification and maintenance. Promotion does not establish runtime health. Verify the artifact, record a real result and investigate stale or failing dependencies before later use. Plugin reference: https://github.com/Rhize-Media/rhize-plugins/tree/main/procedural-memory