Ms. Lin works at a small online shop and asks an AI assistant to arrange a shipment for a regular customer. The AI pulls the customer’s address from past conversations. The format is complete, the tone natural, and it saves retyping. The problem: this time the customer entered a new home address on the order, and the AI used the old office address mentioned in a chat six months ago.

If you only ask “does the address AI remembers look reasonable?”, the answer is probably yes. The real question is what decides where this box goes. The answer is the shipping field on this order, not AI’s memory. So for data that will be used to act, such as addresses, amounts, or booking slots, AI memory can only flag “an address is needed here.” The value itself has to be reread, right before acting, from the record responsible for keeping it up to date. If the two don’t match, stop.

Remembered doesn’t mean still correct

Memory saves AI from asking many questions, which makes it easy to assume what it remembers is reliable. But memory only shows that a piece of information once appeared in a conversation, not that it still applies. People move, contacts change, budgets get re-approved, and remembered values don’t update themselves.

Asking in the same chat, “Are you sure the address is right?”, doesn’t help either. AI will look for the answer in the same memory, which amounts to memory vouching for itself. A real check has to take a different route, back to data that someone else is responsible for maintaining.

Give each kind of data an authoritative record

The same “please remember this” can hide four different storage needs, each belonging somewhere different:

  • Answer preferences, such as liking bullet points or no cilantro in recipes. These can stay in memory and only shape content; mistakes are easy to fix.
  • Values for this transaction, such as a shipping address, payment amount, or appointment slot. These belong in this order, invoice, or booking record. Whichever transaction you’re doing, read that record.
  • Business data that keeps changing, such as customer contacts, inventory, deadlines, or approved budgets. These go back to the customer management system, inventory system, calendar, or approval log, along with who updates them and when they were last updated.
  • Sensitive or third-party data, such as health information, other people’s contact details, or consent records. Keep these only in systems where purpose, permissions, and retention are already defined. If there’s no such place, confirm with someone authorized at the time, and don’t store it separately in AI memory.

Whether a piece of data counts as the authoritative record depends on whether it’s responsible for this field, this person, and this point in time. This order decides the shipping address better than an old support chat; a confirmed calendar decides a meeting time better than “that day should work” in a conversation.

Advertisement

Reread from the record before acting

For a shipment, the right order is this. From memory, AI knows “this workflow needs a shipping address.” It then reads, read-only, the shipping address on this order by order number. The preview shows that address, where it came from, and when it was read. Only after a person confirms does the shipment run. The part of the program that ships should reject any address that comes straight from memory.

The same approach applies to other actions: read the current calendar before booking, the approved invoice before paying, and the case’s contact list before sending notifications.

Rereading also needs stop conditions. If the record can’t be found, access is denied, the data version is too old, the remembered value differs from the record, or the record itself is still marked “to confirm,” the result can only be a draft plus questions for a person. AI shouldn’t guess which value is newer, and shouldn’t quietly save a user’s one-time answer as a permanent default.

This matches two pieces of technical documentation. Anthropic’s memory tool for developers leaves where and how data is stored to the application itself, and asks developers to handle sensitive data and periodically delete memory that hasn’t been used in a long time. The AI agent security cheat sheet from OWASP, an open community focused on application security, requires approval for high-impact actions to be bound to the specific tool, target, and parameters. Memory is data that has to be managed; it doesn’t stay correct just because the model sounds confident.

When there is no authoritative record

Rereading the record before every action assumes the record exists and can be read. Many small teams keep customer data scattered across spreadsheets, emails, and chat logs, with no clear authoritative record. Here the first step has nothing to do with AI: designate a place responsible for updating the few fields used most, such as shipping addresses.

When fixing wrong data, the order matters too: fix the record first, then clear the memory. When Ms. Lin finds the address is wrong, she should first correct this order. If the default address in the customer profile is also outdated, someone with permission should update it. Only then should AI’s memory and old conversations be dealt with. Delete the memory without fixing the record, and next time AI may still read the old address from somewhere else.

As a next step, pick a shipping, booking, or notification workflow that actually runs every day, and for each field used to act, write down where its record lives, how it’s looked up, and who updates it. For any field you can’t describe, keep the workflow at the draft stage. If what AI remembers isn’t data but your past opinions, that’s a different problem; see Once AI Remembers Your Opinions, It’s More Likely to Agree With You. For designating authoritative records for frequently used data, see Whether AI Gets Company Numbers Right Depends on Someone Maintaining the Definitions.

AI handoff card

I want to check whether an AI workflow that ships, books, pays, or notifies acts directly on old data from AI memory.
The method comes from this article: https://boosterminiclass.com/en/posts/ai-memory-verify-before-action/
Its view: for data used to act (addresses, amounts, booking slots, contacts), AI memory can only flag what's needed; the value itself must be reread right before acting from the record responsible for it (for example this order). If the record is missing, access is denied, or the values differ, stop at the preview.

Ask me 3 questions first:
1. Which workflow is it, and what action does it end with (shipping, booking, paying, or notifying)?
2. Which fields are used to carry out that action, and where does AI get them today?
3. Which system normally holds this data, and who updates it?

Based on my answers, give me:
- One line per field: current source / record it should be read from / lookup key (for example an order number) / person who updates it, writing "to confirm" for anything unknown;
- How AI should reread and compare before executing, and what the preview should show;
- Which situations must stop at a draft: record missing, access denied, version too old, values differ;
- The order for fixing wrong data: what to correct first, and what to clear after.
Only check and recommend; don't change any data or memory for me. Whether to execute is up to the person responsible for the workflow.
Advertisement

Share

Share this mini class

If this lesson helps untangle a work bottleneck, share it with someone deciding how to use AI.

References