Answers
Isn't AI memory without a write policy just a faster way to hallucinate?
Yes, and it is the right objection to make about most of what is sold as agent memory. If anything an assistant produces can become a stored fact, the store turns into the place where one confident mistake is preserved and handed to the next run as settled. Better retrieval makes that worse rather than better, because it makes the wrong entry easier to find. What breaks the loop is a step between writing and governing: here an assistant can propose, and only a person on the project can make a proposal binding. Until someone approves it, it sits in a review queue as a suggestion, and no assistant reads it as a rule.
Last updated September 16, 2026
The failure is at the entrance, not the exit
Most of the discussion about AI memory is about retrieval — how to find the right thing. This objection is about what got in, and it is the harder half. An assistant that infers a rule from one conversation, writes it down and reads it back next week has not remembered anything; it has laundered a guess into a fact, and on the second reading it looks exactly like a real decision. Retrieval quality cannot help, because from the inside a confident wrong entry and a correct one are the same shape.
Proposing and deciding are two different acts
So they stay two. An assistant that notices something durable writes it as a proposal, saying what it thinks the rule is and what would make it stop being true. It goes to a queue a person reviews, and until that person approves, edits or turns it down, nothing treats it as current. The approval is recorded with the entry, so a later reader can tell what the team settled from what a model inferred — a distinction that does not exist at all in a store where every write is equal.
A refusal is a result, and it is kept
The queue only works if turning something down leaves a mark. A refused proposal stays visible as refused, so the same suggestion does not come back a week later from a different session that had no way of knowing. This matters more than it sounds: an assistant with no record of what was declined will re-propose it in good faith, and a reviewer who meets the same rejected idea three times learns to stop reading the queue — which is how a write policy quietly stops being one.
What it looks like in practice
An agent works through a support backlog and notices that three refunds in a row were approved outside the stated window. It writes down what looks like a rule: refunds are approved regardless of the window. It was wrong. Those three were one escalated account, handled as an exception by someone who knew it was an exception. But the entry is now indistinguishable from a real policy — same format, same confidence, written by the same process that wrote the entries that are correct. The next week a different agent answers a customer by quoting it. Nobody catches it, because the answer is consistent with what the system says the policy is, and consistency is what everyone was checking for. Had the same write arrived as a proposal, it would have been one line for a person to read — refunds approved regardless of window, yes or no — and thirty seconds, before it governed anything.
Questions people ask about this
- Doesn't requiring human approval defeat the point of automatic memory?
- It changes what is automatic. Noticing, drafting and proposing stay with the assistant, and those are the parts that otherwise do not happen — people do not stop to write down the rule they just applied. What stays with a person is the yes or no, which takes seconds and is the only part where being wrong is expensive. The alternative is not less work; it is the same work done later, by whoever has to unpick which of two hundred entries were real.
- What stops the review queue from becoming a chore nobody does?
- Two things, and both are design rather than discipline. A proposal has to state what would end it, which forces it to be concrete enough to judge quickly. And an assistant is expected to check whether something similar is already recorded before proposing, so the queue fills with genuinely new claims instead of near-duplicates. A queue of restatements is exactly what teaches people to ignore it.
- We already review what our agents do. Isn't that the same thing?
- It is the same instinct applied one step earlier. Reviewing output catches a wrong answer once; reviewing what becomes a stored rule catches it before it is the premise of every answer after. The difference shows up as cost: an unreviewed output is one mistake, and an unreviewed write is a mistake that other correct-looking work is then built on.
Where this is verifiable
Product documentation on this site (How it works, Install), the answers on human-sanctioned AI memory and on out-of-date memory for the neighbouring halves of this problem, and the proposal, approval and refusal rules in the sanctioned product spec — including the review queue and the record of what was turned down. Everything described here is behaviour the tools apply today, not roadmap.
https://www.arroway.app/en/answers/memory-without-a-write-policy-is-just-faster-hallucination