Retrieval is not enough: grounding agents in systems of record

The incident that taught us this

Eighteen months ago we deployed a collections agent for a mid-market logistics client. Its job was narrow: identify overdue invoices, draft dunning emails matched to the customer's payment history, and queue them for a human in AR to approve. We did what most teams did at the time - we embedded the invoice ledger, the customer master, and the payment history into a retrieval index, refreshed nightly.

On day eleven, the agent drafted a firm second-notice email to a customer who had paid in full at 9:40 that morning. The payment had landed in NetSuite. The index had not been refreshed. The human reviewer, trusting the agent's confident summary of an outstanding balance, approved the email. The customer, a top-twenty account mid-way through a renewal conversation, was not amused.

Nothing about the model failed. Retrieval worked exactly as designed: it faithfully returned the state of the world as of 2 a.m. The failure was architectural. We had built an agent that reasoned well over a snapshot and then acted in a world that had moved on. That distinction - reasoning versus acting - is the whole subject of this piece.

RAG answers questions; operations change state

Retrieval-augmented generation earned its popularity honestly. For knowledge work - policy lookup, contract Q&A, internal search - a nightly-refreshed index is fine, because the cost of a slightly stale answer is a slightly stale answer. The reader is still in the loop, still cross-checking, still the one who acts.

Operational agents break that bargain. An agent that reconciles payments, releases held orders, adjusts credit limits, or reroutes shipments is not answering a question. It is changing state in a system of record, or recommending a change that a human will approve in seconds without re-deriving it. In that setting, context freshness is not a quality metric. It is a safety property.

The failure modes are specific and, once you run these systems in production, depressingly familiar. Inventory sold against a count that was true four hours ago. A discount approved against a deal stage that closed yesterday. A refund issued twice because the first refund had not yet reached the index. A vendor payment held because the agent could not see this morning's updated banking details. Every one of these is a stale-read bug wearing an AI costume.

Our rule after that collections incident is blunt: a vector index is a photograph of your business, and your business is a video. Photographs are fine for remembering. They are dangerous for driving.

Systems of record are the ground truth, so treat them like it

Every enterprise we audit already has ground truth. It lives in NetSuite, SAP, Dynamics, Salesforce, HubSpot, in the WMS and the TMS. These systems are transactional, permissioned, audited, and current to the second. The strange thing about the first generation of enterprise AI was the instinct to copy all of that into a second, worse database and let the agent talk to the copy.

When we run our initial audit with a client - typically two to three weeks of mapping workflows step by step - we tag every data element an agent will touch with one question: what is the cost of this being wrong by one hour? For a product description, roughly zero. For an open order status, meaningful. For available credit, available inventory, or payment status, potentially thousands of dollars per occurrence.

That tagging drives the architecture. Anything in the last category never enters a retrieval index as a value. The index can know that a customer exists, what they generally buy, how they like to be spoken to. It must never be the source for how much they currently owe. For that, the agent goes to the system of record, at decision time, every time.

This is why we insist on building against the client's existing ERP and CRM stack rather than standing up a parallel data layer. It is not modesty about our own infrastructure. It is that the transactional stack already solved consistency, permissions, and audit - three problems you absolutely do not want to re-solve inside an agent framework.

The read-before-act pattern

Concretely, our production agents follow a pattern we call read-before-act. It has four parts, and we now consider all four non-negotiable for any agent with write access or human-approved write access.

First, retrieval is for orientation only. The agent uses indexed context to understand the situation: who this customer is, what the workflow is, what similar cases looked like. Nothing retrieved from an index may appear in the final action as a load-bearing fact.

Second, a live read happens inside the action boundary. Immediately before composing an action - a journal entry, an email, a credit release - the agent queries the system of record through a typed API tool: current balance, current stock, current deal stage. These reads are logged with timestamps, so every action can later be traced to the exact state it was based on.

Third, the write carries a precondition. When the agent submits an action, it asserts the state it observed: release this order provided the balance is still zero and the hold flag is still set. If the assertion fails because the world moved between read and write - and in busy ops queues it does, several times a week - the action bounces back for a fresh read instead of executing against reality that no longer exists. Ops engineers will recognize this as optimistic concurrency control. It is twenty years old and it works.

Fourth, the human review gate shows the live read, not the agent's prose. Our collections incident happened partly because the reviewer saw a fluent summary. Reviewers now see the timestamped figures pulled from the ERP seconds earlier, alongside the draft. Approval rates barely changed. Bad approvals dropped to near zero.

A vector index is a photograph of your business. Your business is a video.

Evals have to test staleness, not just accuracy

Most eval suites we inherit test whether the agent gets the right answer given the right context. That is necessary and wildly insufficient. The eval that matters for operational agents is: what does the agent do when the context is wrong, missing, or contradicted by a live read?

So our staleness suite deliberately poisons the scenario. We hand the agent an indexed balance that disagrees with the live API. We make the live read time out. We flip a deal stage mid-episode, between the agent's orientation read and its action. A production-ready agent must prefer the live read over the index one hundred percent of the time, must refuse to act when the live read is unavailable rather than fall back to cached values, and must re-read when its precondition bounces.

The refuse-to-act case is the one teams resist, because it shows up in the metrics as the agent being less autonomous. We hold the line anyway. In our rollouts - which run month by month, with the agent in draft-only mode for the first four to six weeks - an agent that escalates ten percent of cases to a human because it could not verify state is a system working correctly. An agent that quietly acts on a cache is a incident report with a delay timer.

What this means for your first agent

If you are scoping your first operational agent, the practical guidance compresses to five points. One: pick a workflow where ground truth lives in one or two systems you already trust, because agents amplify whatever data discipline you have. Two: classify every fact the agent touches by staleness cost before you write a line of orchestration. Three: give the agent typed, logged, permission-scoped API tools into the system of record, and treat the vector index as background reading only. Four: make every write conditional on the state that justified it. Five: build the staleness evals before you build the demo, because the demo will work either way and only one of them survives contact with a Tuesday afternoon in your AR queue.

None of this is glamorous. There is no new model capability here, no clever prompt. It is transaction hygiene applied to a new kind of actor. But it is the difference between agents your controllers trust with real workflows and agents that get quietly turned off after the first incident. Retrieval tells your agent what the world was. Systems of record tell it what the world is. Only one of those is a safe basis for action.