What is procedural memory for AI agents?
Most agent memory stores facts. Procedural memory stores the steps. It is the difference between remembering that you deploy from a script and remembering the exact order that script has to run in.
Short answer: procedural memory is memory for how to do a repeatable, multi-step task rather than a single fact. Remnic stores procedures as ordered steps you can edit, captures them when you teach a workflow, and mines candidate procedures from how work actually happened. It is on by default and can be turned off with one config key.
Facts versus procedures
A fact is one durable statement. The staging URL is a fact. The package manager for this repo is a fact. Most memory layers are built around facts: they extract short claims, store them, and recall the ones that match a query.
A procedure is different. It is an ordered set of steps for a task you do more than once. Cutting a release, deploying to staging, running the full test matrix before a pull request, resetting a local database. The value is not any single line. The value is the sequence, the order, and the small details that are easy to forget between attempts.
When an agent only has facts, it can answer “what is the deploy command” but it still has to reassemble the whole runbook from scratch each time. Procedural memory gives it the runbook directly.
Why procedures are their own kind of memory
Steps decay differently than facts. A fact is either current or stale. A procedure can be mostly right with one changed step, so it needs to be readable and editable rather than replaced wholesale. It also needs provenance, because you want to know whether a procedure came from something you taught or something the system inferred.
For those reasons Remnic treats procedures as a first-class category instead of squeezing them into the same shape as facts. Each procedure is a markdown file with the steps in the body and YAML frontmatter for its lifecycle, provenance, and review state. You can open the file, read the steps, and fix a wrong one by hand.
How Remnic captures a runbook
There are two paths into procedural memory.
The first is teaching. When you walk an agent through a workflow, the extractor can propose that the memory is a procedure. Remnic does not accept every proposal. The extraction judge requires at least two ordered steps and clear trigger-style phrasing, the kind of language that says “when you deploy, do this.” Candidates that fail those checks are dropped rather than saved as weak procedures. This keeps the procedures bucket from filling up with one-line notes that are really just facts.
Accepted procedures are filed under the memory directory in a dated procedures folder, stored the same way as every other memory: plain files on your machine, not a hosted service.
Trajectory mining and pending-review candidates
The second path is mining. Beyond what you teach on purpose, Remnic can look at how work actually unfolded. A dedicated miner clusters causal trajectory records over a bounded recent window, then proposes a procedure when it sees the same multi-step pattern repeat.
The thresholds are conservative on purpose. By default the miner wants at least three clustered runs of the pattern and a success rate of about three quarters before it will write anything. The lookback window is recent, roughly the last two weeks, so mined procedures reflect how you work now rather than how you worked months ago.
A mined procedure is not trusted immediately. It is written with a pending-review status. Pending-review candidates are held back from recall so a guess never gets injected into a live task as if you had approved it. You review the candidate, edit the steps if needed, and promote it. Promotion respects optional auto-promote rules and does not clobber a body you edited by hand. Mining runs as its own job through the remnic.procedure_mining_run tool, separate from routine memory maintenance, so you can schedule or trigger it deliberately.
Recall at the right moment
A procedure is only useful when you are about to do the task. Remnic recognizes prompts that look like starting hands-on work, things like deploy, ship, open a pull request, or run the tests. On those prompts it can add a short “Relevant procedures” block to the context, built only from active procedures. Pending-review candidates stay out of that block. The number of procedures injected per recall is capped so a runbook never crowds out the rest of the context the agent needs.
On an ordinary question that is not the start of a task, no procedure block appears. The point is to hand the agent the runbook exactly when the runbook matters.
Inspect what you have
Because procedures are files with a lifecycle, you can audit them. The remnic procedural stats command reports how many procedures you have and breaks them down by status, including how many are active versus pending review and how many the miner produced. If a procedure looks wrong, you open the file and fix the step.
Default-on, with an opt-out
Procedural memory is enabled by default. Fresh installs and any config that does not mention the feature turn it on with the safer thresholds described above. If you want to stay opt-out, set procedural.enabled to false, or choose the conservative memory preset, which pins the feature off. Either way the choice is one explicit setting, and turning it off leaves your existing memories and trajectory records untouched.
Set it up
Procedural memory ships with Remnic and works best behind a coding agent. Install the CLI from the install guide, then wire it into your agent through the coding agents page. Once the daemon is running and a connector is attached, teach it a workflow or let the miner surface one, and the runbook will be there the next time you start the task.