Research into practice
AI memory for a business that keeps changing
A new price does not replace every old price. Useful memory connects decisions to the customers, periods and work they affect.
Published: Updated:
In this article
In this illustrative scenario, an AI agent remembers the new price perfectly and still prepares the wrong forecast. It applies the new price to customers whose agreements retain the old one. Another agent uses the correct old price, but applies it to the new sales pipeline. Both can point to a real document.
Business memory becomes useful when it can connect a fact to the people, period and decision it applies to. More stored text does not automatically provide that connection. The product question is how memory helps a business change without repeatedly rebuilding its understanding from scratch.
The difficult part is deciding what still applies
MINTEval, version 2 dated 19 May 2026, studies memory with interacting updates and questions about current facts, earlier states and multiple pieces of evidence. The evaluated systems struggled with those settings; retrieval and memory construction were important bottlenecks. This is a benchmark finding, not a measured failure rate for a particular business. It gives me a useful reason to test change, not just recall.
A search system may retrieve a relevant page without establishing whether it is an approved decision, an abandoned proposal or an explanation of what used to happen. All three might contain the same product name and plausible numbers. The answer needs the relationship between them.
That relationship is commercially valuable. It can let an agent prepare an updated offer, identify which forecasts need revision and explain why a customer received different terms. Without it, the business spends its automation gains reconstructing context each time work resumes.
A price change with three different meanings
Consider an illustrative subscription product. Thirty existing customers pay £120 a month. The business approves £150 for new customers from the following month. A separate draft explores £130 for a future pilot, but nobody has approved that proposal.
The sales plan assumes 40 new customers at the approved price. On those assumptions, existing monthly revenue is £3,600 and new monthly revenue would be £6,000: £9,600 in total. Applying £150 to all 70 customers instead gives £10,500. The £900 difference is a modelling mistake, not a forecast of extra revenue. These are invented planning numbers for this example.
| Statement | Applies to | State |
|---|---|---|
| £120 per month | Existing customers on their current terms | Still active for this group |
| £150 per month | New customers from the next month | Approved, with an effective date |
| Possible £130 pilot | A proposed future offer | Draft; not an operating instruction |
“Keep only the newest price” would destroy a fact that remains valid for existing customers. “Remember everything” would leave the agent to resolve the same ambiguity every time. A useful memory preserves the earlier price, records the new decision and distinguishes the draft from both.
Connect the decision to the work it changes
I would give the price decision an identifiable record: source, approval state, effective period, customer scope and what it replaces. This does not require turning every conversation into a formal database project. It means preserving the fields that determine whether the statement can be used.
The next step is a dependency: which work relied on the old assumption? The proposal template for new customers may need changing. The existing-customer billing schedule may not. The forecast’s new-sales line needs recalculating, while its existing-customer line remains intact.
That distinction supports parallel work. Agents can update the offer, forecast and launch material concurrently against the same decision reference. They do not need to wait for one agent to finish every document. If the approved price changes again, the system can identify the affected outputs and reconsider them, rather than restarting unrelated work.
This is my design interpretation, not an architecture established by MINTEval. The memory becomes an operating aid because it connects decisions with their consequences. It does more than produce an impressive answer to “what did we discuss last week?”
Keep recoverable history outside a temporary conversation
There is also an infrastructure question: what happens when the working context ends? Anthropic’s April 2026 engineering account describes separating durable session history from the agent harness and its execution environment. A replacement harness can retrieve the history after a failure. That illustrates persistence and recovery; it does not establish which business statement is authoritative.
I would keep that distinction. Durable storage preserves an event. A current-state view explains what the event means now. The proposal agent should not need to read every previous pricing discussion to discover the approved price, but it should be able to follow a reference back when a conflict matters.
Nor should a short summary become the only surviving evidence. “Pricing updated” omits who it applies to and when. A useful handoff could instead say: new-customer price approved, existing terms unchanged, forecast update pending, source attached. That gives the next agent somewhere concrete to begin.
Sometimes a small lookup is the better product
A stable FAQ with ten approved answers may not need sophisticated memory. Looking up the current document can be simpler and more reliable. Adding a memory layer introduces another representation that must stay aligned with the source.
The investment starts to make sense when work regularly crosses versions, sessions or several related outputs. I would judge it by the continuation it enables: can the system resume a proposal, update only the affected forecast and explain an earlier decision without reconstructing everything?
I would also avoid treating recency as authority. The latest message could be a question, a draft or an experiment. The fastest response is sometimes to retrieve the relevant approved source; sometimes it is to mark an unresolved conflict and continue with the work that does not depend on it.
For a first implementation, I would choose one fact that changes often—pricing, launch scope or a delivery date—and trace it through two dependent outputs. Then introduce a revision and a contradictory draft. The useful outcome is not “the agent remembers more”. It is that the next piece of work uses the right state and preserves the history needed to explain it.