AI Agent Memory Needs an Expiration Policy

A customer changes their delivery instructions. Your CRM reflects the update. An AI agent remembers the old instructions from a conversation last month and uses them to prepare today's order.

Nothing crashed. The agent remembered exactly what it had learned. The problem is that the business moved on.

That hypothetical failure is worth considering as agent platforms make persistent memory easier to adopt. For a business leader, the question is what an agent should be allowed to remember, when it must check again, and who can correct it. Those decisions belong in the workflow design before memory becomes part of daily operations.

Why this matters this week

On September 29, 2026, MongoDB announced Atlas Agent Engine in public preview. The company describes a platform combining execution, memory, retrieval, and governance, with memory and governance components that can be adopted separately from its runtime. Read the launch announcement.

The announcement is evidence of a new product offering, not proof that a particular customer workflow will become more accurate or cheaper. Public preview also deserves to remain visible in any adoption decision. Revival Group has not independently evaluated this release.

Our interpretation is that easier access to memory infrastructure makes its operating rules more important. A platform can provide a place to retain context. Your business still has to decide which context deserves to influence the next action.

Separate useful context from current business facts

A useful starting point is to distinguish preferences, observations, and authoritative records.

A preference might be that a customer likes concise updates. An observation might be that they asked about an additional service during a call. A current business fact might be the service package they actually purchased.

These should not carry equal weight. An agent can use the preference to shape a draft. It should not turn the sales conversation into an entitlement or treat an earlier summary as the current contract.

For each workflow, name the system that owns each consequential fact. In the delivery example, the order system might own the confirmed shipping instructions. A remembered conversation can help the agent locate the relevant record, but the workflow should check that record before preparing a shipment.

This is an extension of the integration problem described in Seven Systems and One Person. Connecting systems is useful only when the workflow knows which one to trust for the decision in front of it.

Give remembered information a review rule

Avoid one expiration period for everything. The appropriate lifetime depends on how quickly information changes and what happens if it is wrong.

A writing preference may be useful across many interactions. A statement about stock availability can become stale before the next order. A temporary exception approved for one transaction should not silently become a standing policy.

For consequential memories, retain enough context to assess them: where the information came from, when it was observed, which customer or project it applies to, and what event should trigger a fresh check. If a memory was inferred rather than explicitly confirmed, preserve that distinction.

Then define the behavior at that trigger. The agent might reread the source, ask the owner to resolve a conflict, or stop the affected step. Treat missing timestamps and unavailable source records as reasons to reduce confidence, rather than permission to continue from an old summary.

The operational test is simple: when the source changes, can the team explain how the agent stops relying on the earlier value?

Make correction reach the next action

A correction process should do more than add another note alongside the wrong one.

Suppose a service manager corrects the delivery instructions. The next run should use the current value and recognize that the earlier instruction was superseded. If several summaries or stored representations contain the old value, the implementation needs a way to invalidate or refresh the affected context.

This creates a practical tradeoff. Keeping everything can make historical investigation easier, but it also gives retrieval more outdated material to surface. Removing all history can make a decision harder to reconstruct. Separate the history needed for accountability from the context eligible to guide a current action, with access and retention rules appropriate to each.

Assign an owner for corrections and define how urgent changes reach active work. Correcting tomorrow's memory is insufficient if today's order is already waiting to be submitted. The exception path should cover that handoff.

Test memory across several runs

A single successful conversation tells you little about persistent memory. Before expanding a pilot, test a sequence with synthetic records:

• Introduce a preference and check that the next run uses it appropriately.
• Change an authoritative fact and check that the old memory no longer drives the action.
• Provide conflicting records and check that the workflow requests resolution.
• Correct an inferred statement and check that it is not repeated as confirmed fact.
• Switch customers and check that one account's context does not appear in another's work.

Measure repeated errors after correction, unnecessary escalations, and the effort required to maintain the context. Compare those results with a version that retrieves current records without persistent memory. The added complexity should earn its place through better workflow outcomes.

For your next agent review, pick one consequential fact and follow it from its source through storage, correction, and final use. If nobody owns that lifecycle, assign the owner before expanding the rollout.

Revival Group helps organizations build and operate AI workflows with clear data sources, integrations, monitoring, and accountability. Talk with us about the workflow you want to make dependable.