Why is agent procedural memory usually stored as code or skill files, not prose?

## What procedural memory is Of the four agent memory types, procedural memory is the one about capability rather than content. Working memory is the current task, episodic memory is what happened, semantic memory is what is true — procedural memory is how to do something, packaged so it can be done again without rediscovering it. The interesting design question is not whether to keep it but what form to keep it in, and the field converged on executable artifacts rather than remembered text for reasons worth being able to list. ## Verifiability is the deciding property A procedure has a success condition; a fact does not. That asymmetry drives everything else. If a skill is code, you can run it in the environment it targets and observe whether it worked, and only then write it to the library. If a skill is a paragraph of advice, there is no equivalent check — the only test is trying it later, on a real task, where failure is expensive and diagnosis is hard. This is why the strongest reflection and self-improvement results come from procedures with external verifiers attached: tests, compilers, schema validators, or an environment that reports success. Verified skills accumulate into an asset; unverified prose accumulates into noise. ## Voyager and the growing skill library The Minecraft agent Voyager remains the clearest illustration. It operated in an open world with no fixed task list, generated programs to accomplish goals, executed them, used environment feedback and self-verification to iterate until a program worked, and then stored the successful program in a skill library indexed by a description of what it does. Later tasks retrieved relevant skills and composed them, so the agent's capability compounded instead of resetting each episode. Two properties made that possible and neither survives a prose formulation: the stored artifact was executable, so success was checkable, and it was composable, so a skill could be called from inside another. ## Determinism and drift A stored program executes identically each time. A remembered description has to be re-interpreted by the model on every use, and interpretation drifts — the agent that reads "remember to check the staging environment first" will do something slightly different on each occasion, and there is no way to pin it. For anything with side effects, that variance is the difference between a procedure and a suggestion. ## Review, versioning and safety Because a skill is executable, it is a security surface. A memory system that lets an agent write arbitrary new procedures and invoke them later is a self-modifying execution path, and treating skills as files in source control is what makes that governable: changes are diffs, diffs can be reviewed, a bad skill can be reverted to a known-good version, and the whole library is auditable. None of that is available for a fuzzy body of remembered advice, where you cannot even enumerate what the agent currently believes it should do. ## Token economy and progressive disclosure A large skill library cannot sit in context. The standard packaging is tiered: a short name and description per skill — on the order of tens of tokens — kept available for selection, with the full instructions loaded only when a skill is activated, and any bundled scripts read or executed only if that skill actually needs them. The open Agent Skills format standardises exactly this three-tier disclosure around a skill document plus its bundled files, and providers ship it as a portable way to hand an agent new procedural capability. The design goal is that adding the hundredth skill costs almost nothing until it is used. ## The failure mode of prose procedural memory Systems that store how-to as accumulated natural-language lessons run into a predictable decay. Entries contradict each other as practice changes, with no mechanism to decide which wins. Retrieval is by similarity, so the agent gets an approximately relevant instruction rather than the right one. Nothing is testable, so nothing is ever confidently deleted. And the library's behaviour cannot be reasoned about ahead of time, because it is only realised through the model's interpretation at read time. ## When prose is still right Not everything procedural can be code. Judgment-shaped guidance — how to phrase a refusal, when to escalate to a human, what tone this customer segment expects — has no executable form, and forcing it into code produces brittle rules that miss the point. The defensible split is that deterministic, checkable steps become code, and judgment becomes written guidance that is still versioned, reviewed and scoped like code even though it cannot be tested. Structured skill documents are exactly the hybrid: prose instructions with executable scripts alongside, both living in the same reviewed, versioned artifact.