Most teams building AI agents are pouring effort into better memory, longer context windows, conversation summaries, retrieval systems that pull up anything the agent has ever seen. These are useful tools. But they do not solve the problem of knowing whether an action actually completed. Memory tells an agent what happened. It doesn’t tell the agent what’s true right now. And for any agent that takes real action — refunding money, changing an order, updating an account — that distinction is the whole ballgame.
Arjun Mullick
Memory can remember a request without knowing the outcome
Picture a customer service agent that approves a refund. The refund actually goes through, but the confirmation response times out before the agent hears back. From the agent’s point of view, all it has is a record of a request it made, not proof of what happened next. If the agent trusts its own memory, it sees an unfinished task and tries again. The reasoning is sound. The second refund is still wrong.
More conversation history doesn’t fix this. What the agent needs is a record it can trust: the request ID, the current status, the confirmed outcome. Memory can tell you what the customer asked for. It can’t tell you what another system actually did. This isn’t a new problem; recommendation systems ran into a version of it years before agents existed.
A prediction is not the same as current intent
I spent several years building recommendation and personalization systems, and one thing became clear fast: more history doesn’t automatically mean a better decision. A recommender looks at what someone bought, browsed, or listened to, finds a pattern and predicts what they’ll want next. These are all informed guesses rather than facts. I saw this play out around election season. A customer buys several books about a candidate or a political topic and the system, correctly, learns that as an interest. Weeks later, the election is over and the customer has moved on, but their purchase history hasn’t changed. The purchase history is still accurate. It just no longer reflects the customer’s current intent. So, customer data changes with each interaction, so recommendations need to respond to new information.
Freshness in a large-scale personalization system
Early in a real-time personalization platform I worked on, one of the hardest problems wasn’t traffic volume; it was freshness. A customer’s inferred interests could lag well behind their actual recent behavior, so the system would keep confidently recommending things that no longer matched what the person wanted. We rebuilt the pipeline so that signal updates reflected recent behavior almost immediately instead of with a long delay. That gap between what the system knows and what’s currently true is small when you’re recommending a book. It’s a much bigger problem once you move from recommending content to an agent that’s authorized to act on someone’s behalf. Consider a customer who has just started a trial and is eligible for a $0 first-item offer. Personalization should show that available benefit instead of another invitation to start a trial. A fresh eligibility signal lets it change the next offer. Unlike inferred interests, trial eligibility is a recorded fact.
Arjun Mullick
Stale data can produce a bad recommendation. Stale data acted on by an autonomous agent can produce a real-world mistake. Agents need more than memory; they need a reliable state.
Reliable state tells the agent what’s true right now
Reliable state is a verified record of a specific operational fact. In the refund example, the conversation records what the customer requested. The payment system records whether the refund happened. The order system records the order’s status, while current policy and permission records determine whether the action is allowed. Each fact has its own authoritative source. State can itself become stale, so the agent must check the relevant source rather than rely on its memory of an earlier answer.
This matters even after the “yes/no” check passes. A customer might withdraw permission mid-process. An order might fall outside the window where changes are allowed. And even when every check passes, the action itself can still fail partway through, so the agent also needs a safe way to retry without duplicating the damage. The action system must enforce current permissions and other preconditions when it executes, because they can change after an earlier check.
Designing a privacy-request architecture
In privacy and compliance architecture work I’ve done, a single customer request, like asking to delete their data, can trigger a long chain of downstream effects across many internal systems. The challenge wasn’t any one system doing its job correctly; it was making sure there was one authoritative, centralized place that recorded whether the overall request had actually been completed, rather than each system independently assuming it had. That’s the same principle an agent needs: a system of record it defers to, rather than trusting its own memory of what it asked for.
Arjun Mullick
A few categories of tooling exist specifically to solve different slices of this “what’s true right now” problem:
- Business state/workflow databases, Postgres, DynamoDB, Spanner, Cosmos DB.
- Workflow orchestration, Temporal, AWS Step Functions, Azure Durable Functions.
- Agent state, tools like LangGraph checkpoints.
- Session/cache state, Redis, Memcached.
- Event history, Kafka and similar streaming systems.
- Permission state, Open Policy Agent, Amazon Verified Permissions.
None of these replace the others. A production agent usually needs several of them working together, which raises the next question: what happens when an action only partly succeeds?
Safe actions need a receipt and a recovery plan
Every important action an agent takes should carry a unique identifier, like a receipt number. If the response gets lost, the agent must reuse that ID for the same intended operation. The receiving system must recognize the ID and prevent the operation from being applied twice, within its supported deduplication window. This is how an idempotent API makes retries safe; attaching an ID alone is not enough. A preliminary status check cannot prevent two concurrent requests from executing the same action. The AWS Builders’ Library explains this design in Making retries safe with idempotent APIs.
Teams also need reconciliation, regularly comparing what the agent believes happened against what the system of record actually shows, the same way you’d check a receipt against a bank statement. When they disagree, someone needs a clear next step: recheck, reverse the action, or escalate to a human. None of this works without clear ownership.
Reconciliation at high transaction volume
In large-scale commerce infrastructure work, we treated “did this transaction actually complete” as something that could never be answered from memory or assumption, at high volume, even a small rate of unconfirmed or duplicated actions adds up to real customer impact. We built reconciliation directly into the system so that what one part of the pipeline believed had happened was continuously checked against what was actually recorded, with idempotency built in to prevent retries from creating duplicate transactions. The lesson generalizes directly to agents: never let an action retry blindly without checking a source of truth first.
Arjun Mullick
Before you give an agent more autonomy, decide who owns each critical fact and who’s responsible for cleanup when something breaks, because something eventually will.
Monitor the decision, not just the model
All of this changes what a team should actually be watching. Latency, cost and model accuracy matter, but none of those metrics will tell you that an agent acted on a stale permission or announced a refund that never happened. For each consequential decision, trace the information used, its freshness, the rules checked, the attempted action and the confirmed result. What you actually want to be able to trace is:
- what information the agent used
- when that information was last updated
- which rules were checked before acting
- what action was actually attempted
- what result was recorded afterward
As a leader, the job isn’t just watching model quality; it’s making sure every piece of information an agent acts on has a clear source and a way to verify it’s current. Agents are genuinely good at interpreting messy, ambiguous situations and deciding what to do. But they shouldn’t be the record of truth themselves. That job still belongs to the systems built to hold it.
Memory tells an agent what happened. Reliable state tells it what’s true now, and whether it’s safe to act.