Your AI Agent Is Reading a Stale Copy of Your Data

An AI agent reading stale data is the quietest way to ship wrong answers. The agent doesn’t crash, the query doesn’t error, and the number it returns looks exactly like a correct one — because three hours ago, it was. Every agent answers from some copy of your data, and a stack can hold several: the system of record, a replicated mirror, a cache, a derived rollup. Which copy the agent reads decides whether its answer can be trusted at all.

That decision is easy to make by accident. A mirror exists because someone needed read scaling; the agent’s tool gets pointed at it because that’s the connection string lying around; nobody writes down what lag the questions flowing through that tool can actually tolerate. It works until the one afternoon the sync worker stops applying changes — and the mirror keeps answering, confidently and wrong, because serving stale rows looks identical to serving fresh ones.

This guide is the read-side framework: the vocabulary for the four copies your data lives in, a staleness budget you set per question rather than per system, a classification matrix for which questions a mirror may answer, the replication mechanics that determine how far behind a mirror really is, and the reconciliation habits that catch a silent sync failure before a human acts on its output. It assumes your data is already correct — the data-quality problem is its own trap — and asks the narrower question: which copy of that correct data is current enough for this question, right now?

When engineers argue about read replicas, they argue about load, latency, and isolation. Those are performance arguments, and for dashboards they are the right ones. An agent changes the frame: it reads a value and then acts — it quotes the number to a customer, drafts the email, fills the form, calls the write API. A stale read stops being a display inconvenience and becomes an input to a decision.

The failure is well documented, and recent. On July 21, 2026, the engineering team at incident.io published a detailed account of what happened when they moved background workers to read from a Postgres read replica: workers began hitting intermittent not-found errors — on roughly 0.1 to 0.5 percent of reads that immediately followed a write — when they looked up a row right after a queue message announced that row’s creation. Their write-up traces the root cause to a race: the gap between publishing a message to the queue and a worker picking it up could be shorter than the replication lag to the replica. The row existed on the primary and had already been announced downstream; the copy being queried simply hadn’t received it yet.

Notice what kind of failure that is. Nothing was down. No data was lost. Every system behaved exactly as documented. The answer was wrong anyway, because the question — does this row exist? — was asked of a copy whose lag exceeded the question’s tolerance, which for that question was zero. That is the entire subject of this post, generalized: for every question an agent answers, some copy is fresh enough and some copy is not, and nothing in the infrastructure will tell you which is which unless you decide it deliberately.

The term system of record has a formal pedigree. NIST’s glossary, drawing on its identity-guideline series, defines it as “A collection of records that contain information about individuals and are under the control of an agency. The records can be retrieved by the individual’s name, an identifying number, a symbol, or other identifier.” That definition is deliberately narrow — it describes identity records held by a federal agency, not enterprise data generally — so cite it for the term’s provenance, not as the working definition.

The working definition comes from practitioner and master-data-management literature, where it recurs near-verbatim across vendors: a system of record is the authoritative source within an organization for a given data element. Authoritative sources are plural across an organization — one per data domain. The CRM is the system of record for lead status; the billing system is the system of record for invoiced amounts. A fact is born and changed in its system of record, and a write anywhere else must eventually reconcile back to it.

Two neighboring terms are worth separating, because conflating them is exactly the failure this post argues against. A golden record, in MDM vocabulary as documented by Informatica and Profisee, is a derived, reconciled artifact — the consolidated best version of an entity built from systems of record by an MDM process. It is not itself a system of record. And a single source of truth is an organizational practice — managing a given fact in one place — not a specific store. Mirrors, caches, and golden records all sit downstream of a system of record, and they solve different problems.

A stack that runs agents against operational data can hold all four copies at once, and a sync pipeline built to get CRM data somewhere queryable is one way it happens. If you’re building that pipeline, our sync-agent tutorial walks through the build; this post owns the question that starts the day the sync goes live and never goes away: which of these copies should each of the agent’s questions be answered from?

Distributed-systems vendors have spent a decade building precise machinery for bounded staleness — and then attaching it to the wrong unit. Azure Cosmos DB’s consistency documentation defines the construct cleanly: “In bounded staleness consistency, the lag of data between any two regions is always less than a specified amount. The amount can be 'K' versions (that is, 'updates') of an item or by 'T' time intervals, whichever is reached first.” That is a staleness budget as a first-class, configurable number — and Microsoft publishes its floors: “For a single-region account, the minimum value of K and T is 10 write operations or 5 seconds. For multi-region accounts, the minimum value of K and T is 100,000 write operations or 300 seconds.”

DynamoDB draws the same line per read instead of per account. Eventually consistent reads are the default, and AWS’s documentation is plain that with them “the responses might not reflect the results of a recently completed write operation”; setting ConsistentRead to true instead returns “the most up-to-date data, reflecting the updates from all prior write operations that were successful.” Cross-region, DynamoDB Global Tables under the default mode replicate item changes “typically within a second” — a typical figure the docs hedge themselves, not a guarantee.

And freshness is priced. Per AWS’s own framing, eventually consistent reads are half the cost of strongly consistent reads. Read that as an economic signal: the industry already treats staleness tolerance as a metered commodity you buy more or less of. The interesting pattern beneath the pricing is where the choice is attached. Cosmos DB pins it to an account-level default; DynamoDB exposes it per read. Neither can know what the read is for.

Here is the reframe this post exists for: an agent sits at the one layer of the stack that does know what the read is for. It parsed the question. It knows whether it’s about to summarize a quarter or authorize a refund. So the staleness budget should not be a property of the connection the agent happens to hold — it should be decided per question, in the agent’s tool layer, the way DynamoDB lets a caller decide per read. The same vendor machinery, pointed at the right unit.

One boundary to draw before the matrix: read-your-writes consistency — a client being guaranteed to see its own prior writes — is a per-client session property, not a property of the mirror. (The definition here is synthesized from common usage across the distributed-systems literature rather than any single vendor’s wording.) Cosmos DB’s session level names the guarantee explicitly: “In session consistency, within a single client session, reads are guaranteed to honor the read-your-writes, and write-follows-reads guarantees.” An agent that just wrote a row and needs to see it has a session problem. An agent answering questions about data other actors write has a mirror problem. This post is about the second.

Even the vendor selling the staleness bound names the boundary condition where it stops making sense. That is the discipline to copy: a staleness budget is only meaningful when you can say which questions it covers and which it never may.

The matrix below classifies the question classes that recur in agent workloads. It is our synthesis — no vendor publishes this mapping — but its anchors are vendor-documented. On the mirror-safe end, Microsoft’s Cosmos DB docs give the canonical worked example: “Eventual consistency is ideal where the application doesn’t require any ordering guarantees. Examples include count of Retweets, Likes, or nonthreaded comments.” On the other end sits DynamoDB’s ConsistentRead — the read you pay double for because the caller is about to act on the answer. The budget values are starting points to tighten against your own operations, not universal constants.

Two rows deserve emphasis. The write-authorization row is absolute because it is where staleness turns into damage: an agent that reads an account balance, a stock level, or an approval status from a mirror and then acts on it is making a decision on data the source may have already contradicted. And the denominator row is the subtle one — an agent that fetches a numerator from the source and a denominator from a lagging mirror produces a rate no copy of the system ever contained. Mixed-copy arithmetic is stale data’s least visible form.

To enforce a budget you have to measure lag. Postgres logical replication streams committed row-level changes from publisher to subscriber via the write-ahead log, and its pg_stat_replication view then exposes lag as three separate named columns — write_lag, flush_lag, and replay_lag — each a time interval measuring a different stage of propagation. The last one is defined as “Time elapsed between flushing recent WAL locally and receiving notification that this standby server has written, flushed and applied it.”

Our reading of those three definitions — an inference from the docs, not a claim they state — is that replay_lag is the only one a read path should care about. Write and flush lag describe durability on the standby; only once WAL is applied can a query against the standby actually see the change. A replica can be fully caught up on receipt and still behind on visibility.

Downstream of the database, the open-source CDC tool Debezium rides the same machinery: its Postgres connector uses logical decoding through a replication slot, takes an initial consistent snapshot, then “continuously captures row-level changes that insert, update, and delete database content and that were committed to a PostgreSQL database,” streaming change events onward. It tracks its position in the WAL per event, which is what makes restarts safe — the connector resumes from its last recorded position.

Each replication ecosystem names lag differently, measures it in different units, and breaks differently when the number is ignored. The cross-reference below puts the four vocabularies this post has touched side by side — a comparison none of the four vendors’ docs draw themselves.

The Cosmos DB row carries one more idea worth stealing: Probabilistically Bounded Staleness, a metric Microsoft describes as showing how eventual your eventual consistency is — how often reads come back fresher than the configured level. The academic lineage (Bailis et al., VLDB 2012) matters less than the framing: staleness is a probability distribution, not a single number. A mirror whose lag is usually small and occasionally large has an average that flatters it and a tail that defines the risk.

Mechanically there are three distinct failures, each with a different primary-source anchor and a different detection strategy — and all three share the property that makes them dangerous under an agent: the system keeps answering throughout.

Failure 02 deserves its primary source verbatim, because a CDC vendor documenting the hazard in its own tool is rarer than it should be. From Debezium’s Postgres connector documentation:

The incident.io write-up adds the operational lesson on detection. Their engineers argue against alerting on raw time-based replication lag, pointing out that a replica can clear several minutes of accumulated delay in seconds once write volume drops — the same wall-clock lag means different things at different write rates, so they prefer measuring lag by log position (bytes of WAL outstanding) rather than by a wall-clock delta alone. Translated to the agent context: a freshness check that asks how old is this copy is weaker than one that asks how much change has this copy not yet applied.

Everything above compresses into four working rules for the tool layer — the place where the agent’s question meets a connection string.

Then make the pipeline prove itself, continuously. The reconciliation check is deliberately boring: pick a handful of sentinel values — row counts per recent day, the latest updated-at timestamp per synced table, one or two business totals — and re-derive them from the system of record on a schedule, comparing against the mirror’s answers. Alert on divergence, and alert on the apply worker itself: for Postgres logical replication that means checking via the subscription-monitoring view that the subscription’s worker exists and its position advances, not merely that the subscription object is present. A mirror that stops syncing fails every one of these checks within one cycle — which converts the silent failure mode into a paged one.

Provenance closes the loop. An agent’s answer should carry which copy it read and as of when, both to the human reading it and to the log line behind it — an audit trail that omits the read path cannot support the reconciliation this section describes, a design concern our agent audit-trail guide treats in full. The write side of this same boundary — what may change a value, and in which direction — is its own discipline, covered in our workflow state-guardrails pattern. And the read/write boundary has a rollout dimension too: our read-only-first rollout guide covers when a new system earns the right to write at all. Note, finally, that which copy an agent reads and which rows it may see are different controls — permissions scope the rows; the read path scopes their age.

If your agents answer from CRM or operational data today and nobody can say which copy each tool reads, that inventory is a one-afternoon exercise with outsized return — it’s where our CRM automation engagements usually begin, because the read-path map is the same artifact the sync monitoring hangs off.