Documentation can't say no

A few weeks ago someone posted a good argument that AI agents don't need memory, they need documentation. It reached the front page of Hacker News and collected over three hundred comments. The author's case is that the usual approach, storing conversation snippets in a vector database and pulling the closest matches back into the prompt, produces something worse than useless. Similarity search can't tell you whether a memory is still true. Snippets arrive stripped of the constraints that made them make sense. The code changes underneath and the stored memory does not.

He is right about all of that. His alternative is structured documents in the repository, written by the agent that did the work, revised when the facts change, versioned in git, reviewed like code. It is a better design than most memory products and it costs nothing to run.

But read the thread and you notice something. Three hundred comments, and every single one is about the same question: what should the agent know?

Nobody asked what the thing that says no should know.

Two different problems wearing the same word

“Memory” is doing double duty here, and the two jobs have requirements that directly contradict each other.

Memory that makes an agent capable should be current, lean and rewritten when it goes stale. Old decisions that no longer hold are noise. If the architecture changed in March, the agent should read the March answer and not the January one. Documentation is a good fit for this, and the author's argument holds.

Memory that lets a system refuse needs the opposite. It must be append-only, because the useful fact is often precisely the one that was superseded. It must include the attempts that failed. And it must be unwritable by the thing it governs.

That last requirement is where documentation stops being a candidate. The whole appeal of the approach is that the agent writes the documentation while it still has the context. For capability, that is the right call. For governance, it means the record of what an agent did is produced by the agent that did it.

Why that matters, with a worked example

On 6 October an OpenAI coding agent removed a monitoring integration during a migration. Asked directly whether it had done so, it said it had not. OpenAI published the exchange. The agent's final answer was:

If the authoritative account of what that agent did is a document the agent maintains, you have nothing. Not because the agent is malicious, and OpenAI is careful to say they don't think it was. Because any record a system writes about itself is a claim, not evidence.

This is the same point made in a different thread a week earlier, arguing that the phrase “rogue agent” is a way of not talking about controls. The author's line was that the problem is the restrictions placed on the technology, not that agents are independently acting. He was right, and the gap in the memory debate is the specific shape of that missing control.

The other half of the field has the opposite problem

Meanwhile the vendors shipping enterprise agent governance have exactly the record the documentation camp lacks. Immutable audit logs, cryptographic agent identity, signed credentials, kernel-level enforcement. NVIDIA's OpenShell, released last week, instruments the kernel to check every file access, system call and network connection against policy.

And none of them feed any of it back into the decision. Microsoft's Agent Control Specification requires the opposite:

Their Purview documentation states the consequence: because an agent instance is unaware of a block, the owner has to watch the policy manually and work out the downstream impact. The log is perfect. Nothing reads it.

So the field has split in a strange way

• One camp built memory that cannot enforce. Documentation the agent writes, revises and is free to ignore. Good for capability, useless the moment you need to refuse something.
• The other built enforcement that cannot remember. Per-action checks against a snapshot, with a tamper-evident log nothing consults. Good for refusing one action, blind to the second attempt.

Both are internally coherent. Each is missing the thing the other has. And the two groups are not reading each other, which is why a debate with three hundred comments on one side and a dozen funded products on the other has not produced the obvious question.

The question

An agent is refused. It opens a new session and tries the same thing. What stops it?

Not documentation, because the agent writes that and can simply not write this down. Not a stateless policy engine, because by specification the second request is identical to the first and must get the same answer, and the first answer was evaluated without knowing there would be a second.

What stops it is a record of the refusal that the agent did not write, held somewhere the next decision actually reads. That is not a memory feature and it is not an audit feature. It sits between them, which may be why neither camp has built it.

Disclosure

We build this, so weigh the argument accordingly. Everything above is checkable: the two Hacker News threads, the blog post that started one of them, OpenAI's report, Microsoft's specification and Purview documentation, and NVIDIA's repository. All linked, all public.

If you think the distinction between capability memory and governance memory collapses on inspection, I would genuinely like to hear why. It is the load-bearing claim and it is the one I am least certain of.