A Directive Is Not a Memory
Agent memory stores two kinds of thing in one place and treats them identically. One of those kinds cannot be tested by any of the mechanisms the store uses, and the reason is not that it is hard. It is that obeying it removes the evidence that would test it.
Most memory systems are a small operation table. Write a note. Read it back. Replace it with a newer value. Delete it on demand or on a schedule. Some systems can also record that a deletion happened, as an audit event or a tombstone row. That is close to the entire surface area of the field as it ships today.
Almost every one of those systems stores two kinds of thing in the same place. It stores observations, claims about the world that can be checked by going to look, and it stores directives, instructions about what to do. It applies the same apparatus to both: the same staleness checks, the same corroboration, the same trust classes, the same revocation. The apparatus works on observations and is inert on directives, and the reason is not a defect of any particular implementation. Obeying a directive destroys the evidence that would test it. A rule that is followed suppresses its own counterexample, and nothing in the store can tell it has happened.
The categories are not a taxonomy for its own sake. They differ in the one property a memory system exists to manage, which is how a stored belief can be found wrong. The rest of the post walks through why the standard checks miss the directive half, what the falsifiable core of a directive actually is, what the right test looks like, and what the accumulated consequence is for any store that has been running for a while.
One thing up front, since the reading is otherwise easy to misread. This is not an argument against directives. Rules are how hard-won operational knowledge is transmitted, they work, and an agent that follows them is better than one that does not. The argument is that storing them in a system whose verification machinery cannot touch them, and displaying them with the same status as verified observations, misrepresents what is known.
Observations and Directives in One Place
Look at what a memory store actually contains after a few months of real use and the two categories are obvious once you separate them.
An observation has a referent. It names something that exists in the world: a file, a function, a value, an event that happened. Because it has a referent, it can be verified by going and looking, and it can be falsified by the referent changing. Every mechanism a memory system uses to keep notes honest is built on this: anchor the note to the artifact, hash the artifact, flag drift, ask for corroboration, surface contradictions.
A directive has no referent. "Always run the tests in the venv" does not name a thing that exists. It names an action to take, and the world does not contain a fact that the note is a description of. There is nothing to anchor to and nothing to hash.
You can of course anchor a directive to a file anyway. Most systems will happily let you attach "always use the venv" to the test configuration and watch that file's hash. But notice what the drift signal then tells you: that the file changed. It says nothing about whether the rule is still warranted, because the rule was never a claim about that file's contents. The anchor is decorative. It fires and it means nothing, which is worse than not firing, because a signal that carries no information trains the reader to ignore the ones that do.
The categories are not a taxonomy for its own sake. They differ in the one property a memory system exists to manage, which is how a stored belief can be found wrong. Treating a note with a referent the same as a note without one means the verification machinery, designed for the first case, runs without effect on the second, and the second case looks identical to the first on the dashboard.
A related distinction appears in the philosophy of language, and the post's central claim depends on it. Imperatives and declaratives differ in kind. Declaratives are the sort of statement that can be true or false. Imperatives are not: they are satisfied, obeyed, or appropriate, and asking whether one is true is a category mistake. The argument here does not say directives are meaningless, only that the falsifiability apparatus developed for propositions cannot reach them, and a memory system that treats them as propositions will be unable to test them.
None of this is to claim the current literature has noticed nothing. CoALA's framework for language agents separates declarative memory from procedural memory, and the design intent is to keep rules out of the fact store. Practical advice in the same vein says rules belong in the system prompt or agent policy, and memory should hold facts; A-MEM's Zettelkasten-inspired architecture moves in this direction with separate components for stable rules and time-stamped facts. The split is the right idea, and Part 3 of this post will argue it is not yet enough. The split as drawn treats rules as a different storage class with different update rules, but it does not yet address the deeper problem: rules in that storage class are still never tested against the world, only managed.
Compliance Is What Removes the Evidence
Here is the mechanism, and it is the heart of the post.
A rule exists because of a condition. "Always run the tests in the venv" exists because at some moment the global interpreter was missing something the suite needed. That condition is a fact about the world, and facts about the world change. The package gets installed globally. The dependency is vendored. The suite stops needing it.
Now ask what would inform anyone that the condition no longer holds.
The only observation that could is someone running the suite with the global interpreter and it working fine. And that is precisely the observation the rule exists to prevent. Compliance is what removes the evidence. Every session that follows the rule generates a record of the rule being followed and no information whatsoever about whether it needed to be.
So the rule's evidential position never changes. It was warranted once, it may be unwarranted now, and the world will never produce a signal either way, because the only source for that signal is the action the rule forbids.
A false belief that forecloses an action is recognized as a failure mode, sometimes named self-reinforcing error in the agent-memory survey literature. A directive that forecloses the same action is recognized as good practice. Structurally they are the same object: both remove the only observation that could correct them. The difference is that somebody meant to write the second one, which affects how it got there and not at all whether it can ever be found wrong.
This is the same closed loop as a self-sealing false belief, arrived at from the opposite direction. In the false-belief case, an agent wrongly concludes an action fails, stops taking the action, and thereby never collects the evidence that would refute the conclusion. In the directive case, a rule forecloses the alternative deliberately, and everyone involved endorses the foreclosure. That endorsement is exactly why nobody looks at it as a defect. The loop is identical; only the intent differs, and intent has no bearing on whether evidence gets collected.
The asymmetry of failure types makes this invisible in normal operation. A directive that is wrong in the direction of forbidding something harmless produces no failures at all. It produces slightly slower work, or an unnecessary constraint on a subagent, or a confusing instruction that a new contributor follows without understanding. There is no incident, no red test, no error message. The cost of an obsolete directive is paid continuously in small amounts and never shows up as an event.
Three Checks That Do Not Apply
Take the standard mechanisms a memory system uses to keep a note honest, and apply each to a directive.
Staleness by anchor drift does not apply, for the reason in Part 1: the directive has no referent, so any anchor is arbitrary. Watching the file the rule is about tells you when that file changed, which is uncorrelated with whether the rule is warranted. A rule about interpreters is falsified by an installation on a machine, which is not in the repository at all.
Corroboration does not apply, and this one is actively misleading. The natural way to corroborate a note is to check it against the codebase. Do that with a directive and you find that every test invocation uses the venv, that the CI config uses the venv, that the documentation says to use the venv. The evidence is overwhelming and it is entirely circular: the codebase is a product of the directive. You are confirming compliance and reading it as correctness. A directive that has been obeyed for a year has more apparent corroboration than one written yesterday, and the apparent corroboration is a measure of how thoroughly it was followed, not of how true it is.
Contradiction does not apply, because nothing observed contradicts a rule. Suppose someone does run the suite with the global interpreter and it passes. Does that contradict "always use the venv"? Not in the way a conflicting observation contradicts an observation. The rule can absorb it without strain: it worked this once, on this machine, for this subset. An imperative is not the kind of statement a single observation refutes, which is a property of imperatives generally and not a weakness of anyone's implementation.
| Standard check | What it tests | What it does to a directive |
|---|---|---|
| Anchor drift | Did the artifact the note describes change? | Fires or doesn't fire; the rule was never about the artifact's contents |
| Corroboration | Does the codebase agree with the note? | Confirms compliance, then reads it as correctness |
| Contradiction | Does an observation conflict with the note? | The rule absorbs the outlier; the claim is not the kind a single observation can refute |
So the three mechanisms that exist to prevent a memory store from filling up with wrong beliefs are all inert on directives, and they are inert quietly. Nothing reports that the check was skipped. The directive sits in the store with the same trust class and the same green status as a note that has been verified fifty times.
The Condition Inside Every Directive
The situation is not hopeless, and the way out comes from noticing that a directive is a compound object.
It has three parts:
- The rule. "Always run the tests in the venv." This is stored.
- The reason. "Because the global interpreter is missing a grammar package the suite needs." This is sometimes stored, as prose, when whoever wrote the rule was careful.
- The condition. The state of the world under which the reason holds. This is essentially never stored, and it is the only falsifiable part of the whole object.
The rule is an imperative and cannot be true or false. The reason is a historical explanation and was true when written, permanently. The condition is a proposition about the present, and propositions about the present can be checked.
And the condition is usually checkable trivially. "The global interpreter lacks that package" is one command. "The generated files are still generated by that script" is one command. The reason a directive feels unfalsifiable is not that its underlying claim is hard to test. It is that the claim was converted to prose at write time and the executable form was thrown away.
Every directive contains one falsifiable claim: the condition under which its reason still holds. Every memory system throws that claim away at write time and keeps the prose. Store the condition as a check instead, and a rule becomes as testable as any other note.
So the design move is narrow and concrete: a directive should carry its condition as a predicate, not as an explanation. Not "because the global python lacks tree-sitter" in a sentence, but a recorded check that returns true or false today. At that point the directive becomes exactly as checkable as any observation, because it now contains one.
A Directive With and Without a Stored Condition
Edit the rule, the reason, and the predicate below, then click the two condition buttons to see what a memory system would report. The stored rule is identical in both arms. The only difference is whether the system has something to test against. Watch the rendered memory row change as the predicate flips.
This also produces a useful classification of directives that a store could act on.
Some directives have a checkable condition, and those should carry it and be re-checked. Some have a condition that is checkable only by taking the forbidden action, and those need Part 4's treatment. And some are genuine preferences with no world-condition at all: "write commit messages in this style" is not warranted by any fact and cannot go stale. Those are fine, and they are also the minority, and conflating them with the first two categories is part of why the whole class gets treated as un-checkable.
Directives Need Re-Test, Not Age
The tempting fix at this point is a time limit. Rules expire after six months; review them. The argument from a earlier post applies here without modification: age is not evidence and should never decide a memory's validity. A directive from two years ago may be more load-bearing than one from last week. Expiry by age would discard the durable rules along with the obsolete ones, at a rate determined by nothing but the calendar.
What a directive needs is the mechanism its structure actually calls for: an active re-test that deliberately takes the foreclosed action in a context where doing so is safe.
This is forced exploration, which is the standard remedy for exactly this loop in sequential decision making. In a multi-armed bandit problem, an agent repeatedly chooses among actions whose payoffs it does not know, and it learns only about the actions it actually takes. Give a greedy agent a false negative belief about one arm's value and the arm leaves its action set forever. Once removed, the posterior over that arm cannot update, because updates require pulls. The standard remedy, going back to Sutton and Barto's treatment of the exploration-exploitation dilemma, is a mechanism that occasionally takes the action the current posterior says is worthless, specifically to keep the posterior honest. The simplest version is epsilon-greedy, where a small fixed probability picks at random regardless of the current estimate; UCB is a more adaptive version that uses confidence bounds.
It is not an accident that the same remedy applies to directives. It is the same failure. A policy that stops taking an action stops accumulating evidence about that action, and the fix is forced exploration: occasionally taking the action anyway to keep the estimate honest. The action here is "run the suite with the global interpreter"; the estimate is "the global interpreter is missing the package."
For a directive with a checkable condition, the re-test is the predicate from Part 3 and costs nothing. For a directive whose condition can only be checked by violating it, the re-test is a deliberate, scoped violation: run the suite once with the global interpreter, in a sandbox, and record what happened. The result is not "delete the rule" or "keep the rule." It is the first new evidence about that rule since the day it was written.
Two honest limits on this, and they are real.
Not every directive can be safely re-tested. A rule that exists to prevent an irreversible action must not be periodically violated to see what happens. Those directives are genuinely uncheckable, and the correct response is to mark them so, explicitly, rather than to leave them looking like the checkable ones. A store that distinguishes "verified last week" from "unverifiable by design" is telling the truth. A store that shows both as active is not.
A re-test is evidence, not a verdict. One successful run with the global interpreter does not prove the rule is obsolete; it might be a machine-specific accident. But it converts a rule with zero evidence since inception into a rule with one data point, and the direction of travel matters more than any single result.
Why Directives Accumulate Forever
Step back and the accumulated consequence is organizational rather than technical.
Directives accumulate monotonically. New ones get written whenever something goes wrong, which is the correct response to an incident. Old ones are never removed, because nothing can ever show that one should be. The count only goes up.
And nobody deletes one, for a reason that connects directly to the reversibility argument: removing a directive is destructive and, in most stores, irreversible, so it demands a confidence nobody has. To delete "always use the venv" you would need to be sure it is unwarranted, and Part 2 explains why you can never become sure. So the rational move for any individual is to leave it, and the rational move for every individual produces a store where the rules outnumber the findings and most of them are load-bearing for reasons nobody alive remembers.
The earlier post on reinstatement argued that making revocation reversible lowers the threshold for using it: when reinstating costs one event, agents are willing to revoke on suspicion. The same logic applies here. A store that records a directive's condition as a check, and lets a failed check downgrade the rule to "needs review," makes the cost of questioning a rule non-destructive. That is what unblocks the slow accumulation.
That is the observable symptom, and it is familiar to anyone who has read a long-lived project's agent configuration file: a list of imperatives of unknown vintage and unknown warrant, followed by everyone, questioned by no one, growing every quarter.
The point is not that these rules are bad. Most of them were right when written and many still are. The point is that a store containing them is not doing what a memory system claims to do. A memory system claims to hold beliefs that can be checked and corrected. For the directive half of its contents it holds beliefs that cannot be checked, and it presents them with the same confidence as the half that can. That is a governance function wearing memory's interface, and the mismatch is why the trust machinery keeps failing to bite.
What This Is and Is Not
No measurement is offered. The argument is structural. It distinguishes two categories that memory systems merge, shows that the standard verification mechanisms are inert on one of them, identifies the falsifiable component that is discarded at write time, and proposes an active check in place of a passive one. That is an argument, not a result.
The experiment is specifiable. Take a real store's directives and, for each, attempt to determine whether its condition still holds. Record how many have a stated reason at all, how many have a condition recoverable from the reason, how many of those conditions can be checked without violating the rule, and how many turn out no longer to hold. That last number is the interesting one, and my expectation is that it is not small. A second measurement: for directives whose condition has lapsed, determine how long ago it lapsed. The gap between when a rule stopped being warranted and when anyone noticed is the quantity this whole post is about.
This is not an argument against directives. Rules are how hard-won operational knowledge is transmitted, they work, and an agent that follows them is better than one that does not. The argument is that storing them in a system whose verification machinery cannot touch them, and displaying them with the same status as verified observations, misrepresents what is known.
This is not the same argument as instruction-following security. A separate earlier post argued that compliance with ambient instructions in agent memory is not a function of source authority but of the shape of the payload: a planted imperative that rides an action the agent was about to take gets obeyed, while a corrective declarative in the same file gets ignored. That post is about text that should not have been obeyed at all, and asks why shape beats source. This post is about text that should have been obeyed, was obeyed correctly, and can never afterwards be found to have outlived its reason. Both end at the same uncomfortable place, which is that an instruction's authority in an agent's context is not connected to anything that could evaluate it. They get there by different routes and neither subsumes the other.
The argument here concerns the verification gap, not adversarial input. A malicious writer can still plant false directives, and the design above does nothing to defend against that. It governs accidental staleness, the case where a rule was warranted once and is no longer. A defense against the planted case is a separate problem with a separate literature, and the two should not be confused.
An observation describes the world and can be checked against it. A directive causes the world, and once obeyed, the world it caused is the only evidence available about it. That evidence confirms it no matter what.
Every directive contains one falsifiable claim, the condition under which its reason still holds, and every memory system throws that claim away at write time and keeps the prose. Store the condition as a check instead, and a rule becomes as testable as any other note. Where the condition can only be tested by breaking the rule, the answer is not to trust the rule forever. It is to break it once, on purpose, somewhere safe, and to record what was learned.
The fix is small, the diagnostic is structural, and the consequence of doing nothing is the slow accretion of rules whose warrant nobody can reconstruct and nobody is willing to remove. A memory store is a governance system. It is time to start telling the truth about what it is governing.
Sources
- Karl Popper (Stanford Encyclopedia of Philosophy).
- Sutton, R. S., Barto, A. G. Reinforcement Learning: An Introduction.
- Sumers, T., Yao, S., Narasimhan, K., Griffiths, T. Cognitive Architectures for Language Agents (CoALA).
- Xu, W., Liang, Z., Mei, K., Gao, H., Tan, J., Zhang, Y. A-MEM: Agentic Memory for LLM Agents.
- Austin, J. L. How to Do Things with Words.
- Agents Over-Trust Instructions and Under-Trust Corrections.
- Agent Memory Expiry Is a State, Not a Delete.