Memory and State Management

Memory and State Management

Procedural Memory

26 of 69 in this book · 3 min read

What it is

Retained know-how about how to get something done in this particular environment: the call sequence that actually works, the argument values that avoid the rate limiter, the order this system wants its forms filled in, the recovery step that clears a known error state. A procedural item is a routine plus its track record, which is what separates it from a stored description of a procedure — a description is a claim about the world, a routine is something the agent re-uses and whose value is measured by whether re-using it improved the outcome.

Why it matters

Most of what makes an agent effective against a real system is not in any documentation. It is the accumulated knowledge of which of five plausible approaches survives contact with this deployment, this version, and this tenant's configuration. Without somewhere to keep it, every agent instance rediscovers it by trial and pays for the failed attempts each time. With it, a lesson costs once — and a wrong lesson also costs once and then keeps costing, which is why promotion and invalidation matter more here than storage does.

Key decisions

  • Whether a routine is stored as replayable structure — a parameterised sequence of calls — or as advice in prose for the model to follow. Structure is reliable and brittle when the environment shifts; advice survives change and can be silently ignored.
  • What promotes a one-off success into a stored routine: a single success, a run of them, or human approval. This is the main control on how fast the store fills with superstition.
  • How a routine is invalidated when the environment changes underneath it, given that nothing will stop retrieving it and nothing will stop it failing until someone intervenes.
  • Whether routines are scoped to one environment or shared across all of them. Sharing spreads a good fix immediately and spreads a bad one just as fast.
  • Whether a retrieved routine is executed directly, proposed to the model as a suggestion, or shown as context. The three have very different blast radii when the routine is wrong.
  • Whether failures are recorded against the routine, since a store that only records successes cannot demote anything.

Failure modes

  • A routine encodes a workaround for a defect that has since been fixed, and applying it now causes the failure it was written to avoid.
  • Success is attributed to the routine when it was incidental, and a superstition is reinforced every time it is retrieved and the task happens to succeed again.
  • Stored sequences embed identifiers from the session that produced them, and replaying them acts on the wrong record in the target system.
  • Only successes are written, so routines that stopped working are never demoted and the store's measured success rate is structurally optimistic.
  • Routines are retrieved by surface similarity of the task description, and one written against a staging environment is applied in production.
  • A routine captured from a privileged operator's session is retrieved for a user without those permissions, producing a cascade of authorization errors the agent cannot interpret.
  • The routine is correct and the environment's rate limits have changed, so the routine now reliably triggers throttling and the agent attributes the failure to the task.

Related capabilities


Applies: Production readiness · Design questions