AI log, day 16: the agent did not need a memory, it needed a source of truth

Day 15 ended without committing to a day 16 topic, betting there was a third shape left in the “where does state actually live” question. There was, and it showed up in an unglamorous place: a small internal tool that looks up a customer’s subscription status before answering a support message. It gave two different answers to the same question depending on which one you asked, the agent or the billing database, and the database was the one that was current.

The tempting shortcut is to remember it yourself

The tool worked the way days 14 and 15 both describe: the first time a conversation needed a customer’s plan and renewal date, it queried the billing system, then stored the result the same way any other fact gets stored, so later turns and later sessions could pull it back without paying for another query. That is a reasonable-looking optimization right up until the subscription actually changes mid-week and the stored copy quietly becomes wrong. The agent answered a cancellation question with a plan that no longer existed, confidently, because nothing about “recall the fact you stored” checks whether the thing it describes is still true out in the world.

The system of record already existed

Day 15 spent a whole entry on facts expiring with no marker for it, and the fix was a supersession rule inside the memory store itself: newer statements override older ones. That fix makes sense when the memory store is the only place the fact lives. It does not make sense here, because the billing database was never not authoritative. Storing a copy of an answer that already has a live, queryable, always-current source did not create a memory problem by accident, it created one on purpose, by duplicating a fact into a second location that has no way of learning when the first one changes.

Two different things were both called “memory”

That is the actual distinction worth keeping past this entry: a conversation produces two different kinds of state, and only one of them is memory in the sense days 14 and 15 were solving for. Category one is facts that exist only because someone said them, a preferred name, a stated tone preference, a decision made mid-conversation with no other record anywhere. That has nowhere else to live, so it has to be written down and it inherits every problem the last two entries covered, staleness, duplication, judging what is worth keeping. Category two is facts that already have an authoritative home outside the conversation entirely, an account balance, a ticket’s status, an inventory count. Those don’t need a memory. They need a tool call, made fresh, every time the answer matters.

Wiring the tool instead of writing the memory

The actual fix was smaller than the failure made it look: replace “recall the stored subscription status” with “call the billing API and use whatever it returns right now.” Same shape of connection day 12 already covered, an agent’s tool call reaching into another system, except this time the point is that the call itself is the caching strategy. Nothing gets written down between turns because nothing needs to be, the system of record is one call away and it is never stale by definition, since it is the definition.

The rule that would have caught this earlier

Before adding anything to a memory system, the question worth asking is whether the fact already has a system of record somewhere else. If it does, that is a tool integration, not a memory. Memory is for the first category only, the things that exist purely because a conversation created them. Treating a live lookup as something worth memorizing does not save a query, it just moves the staleness problem from “solved by asking again” to “solved by hoping the cached answer didn’t change,” and that trade only ever loses.

What’s next

Three entries in a row followed one thread, in-session memory, cross-session memory, and now memory that should not have existed at all. That thread feels closed for now. No fixed day 17 topic yet, the next entry is as likely to leave memory behind entirely as it is to find a fourth shape of it.