Agents are now the heaviest users of your data, and they don't wait

For twenty years we sized data systems around a simple assumption: a person is on the other end. A person opens a dashboard, runs a query, reads a report, makes a decision. People are slow, so the system could be slow. People are few, so the system could be small. People forgive stale data, because they rarely know it is stale.

Agents break every one of those assumptions at once.

The 43x problem

When we traced what happens between an agent receiving a task and committing an action, the pattern was consistent across industries. A customer-service agent resolving a billing dispute pulled account history, payment events, product telemetry, policy documents, and the last six interactions before it wrote a single word. A human rep would have opened two tabs.

Across the deployments we studied, the median agent decision read 43 times more records than the human workflow it replaced. The top decile read more than 300 times more. None of that is waste; it is what good judgment looks like when you can afford to check everything.

The consequence is that "read traffic" stopped being a background concern. For several teams it became the dominant line on the infrastructure bill within a quarter of going live.

Agents don't wait, and they don't retry politely

A person who hits a slow query waits, sighs, and refreshes. An agent hits a slow query and does one of three things: times out and acts on partial context, retries in a tight loop, or fans out to another source. All three are worse than waiting.

• Partial context produces confident, wrong actions. The agent didn't see the refund issued ten minutes ago, so it issued another.
• Tight retries turn one slow request into a self-inflicted load spike. We saw a 200 ms stall become a 14-second outage this way.
• Fan-out means the agent reads from whichever system answers first, which is rarely the system of record.

Latency, in other words, is no longer a user-experience metric. It is a correctness metric.

What the fastest teams changed

The teams that handled this well did not buy a bigger warehouse. They changed where agents read from.

Instead of letting agents query dozens of systems directly, they put a single access layer between agents and data: one place that serves fresh operational state in milliseconds, enforces who can read what, and logs every read. Agents talk to the layer. The layer talks to everything else.

"We stopped thinking of the agent as a user of our database and started thinking of it as a service that needs an SLA. That reframing changed every design decision after it."

Three properties showed up in every version of this that worked:

1. Freshness measured in seconds, not hours. If the agent's view of the world is older than the world, it will act on a world that no longer exists.
2. Access decided at the layer, not in the prompt. Telling a model not to look at something is a request. Not serving it is enforcement.
3. Every read is an event. When something goes wrong, the question is always "what did it know and when did it know it." You cannot answer that from a warehouse query log.

What this means for the next twelve months

If your agent roadmap assumes agents will read from the same places your dashboards do, your platform budget is wrong by at least an order of magnitude, and your incident count will tell you before your CFO does.

The good news is that this is a plumbing problem, and plumbing problems have known solutions. The teams getting this right are not smarter about models. They are more disciplined about the data layer those models stand on.