The nightly batch no longer cuts it: why your AI agents need data in motion

When an AI agent pilot fails to reach production, the conversation almost always turns to the model. Maybe the prompts need work. Maybe it is time to switch providers. Maybe the model should be fine-tuned on company data. In our experience implementing data platforms across Latin America, the cause usually sits somewhere else, and it is far less glamorous: the agent is looking at stale data.

The agent has no idea it is out of date

A language model has no way of telling whether the data you handed it is three seconds old or fourteen hours old. It will answer with the same confidence either way. That is exactly the property that makes it dangerous when context arrives late.

Take a customer service agent at a bank. You ask about the status of a transfer. The agent queries the data warehouse, which is fed by an overnight job, and reports that the transfer is in progress. In reality it was rejected two hours ago and the customer has already been notified. The agent did not lie: it answered correctly about a state that had stopped being true.

No amount of prompt engineering fixes that.

Why the batch architecture survived so long

Moving data by copying it worked for decades for a simple reason: decisions could wait. The daily sales report was there for the next morning’s meeting. Bank reconciliation closed overnight. Nobody needed to know the state of inventory at a precise second.

That assumption broke on two fronts at once.

The first is the business. Fraud is settled inside the transaction, not in the following day’s review. The customer abandoning a cart does it within the minute, not within the quarter. The network outage that will generate complaints is already happening while the dashboard refreshes.

The second is the agent. An autonomous agent does not query data to inform a person who will then apply judgment. It queries data in order to act. And acting on a state that has already changed is not a reporting error, it is a wrong decision actually carried out.

The trap of wiring the agent straight to the database

The natural reaction once someone sees this is obvious: if the warehouse is stale, let the agent query the transactional database directly.

That works with one agent and one use case. It stops working fast.

• Every new agent opens another connection against the system that keeps the business running. The core banking platform, the inventory system and the billing system were never designed to absorb analytical queries from agents that reason out loud.
• An agent’s queries are unpredictable in both shape and volume. A spike in conversations turns into a spike in load on a critical system.
• Every integration is point to point. With ten systems and ten agents you have a hundred possible paths, and all of them have to be maintained.
• There is no record of what the agent saw. When someone asks why it decided what it decided, there is no way to reconstruct it.

That last point is usually what stalls the project in banking and telecommunications. It is not enough for the agent to be right: you have to be able to explain it afterwards.

Putting events at the center

The alternative we implement differs on one point that looks small and changes everything: instead of every consumer going to fetch data where it lives, each system publishes what happens to it as an event, and whoever needs it consumes it from there.

An approved payment is an event. An address change is an event. A degraded network cell is an event. A product leaving the warehouse is an event.

Three things the previous architecture could not deliver are resolved on top of that stream:

Context is built while the data is moving. A customer’s behavioral profile is not recalculated every night: it stays current as their transactions arrive. By the time the agent asks, the answer is already there and already fresh.

Complexity stops growing with the square. A new system publishes its events once and any consumer picks them up. There is no integration to build for every pair.

Every decision is on the record. If the agent’s decision is also published as an event, the full record of what data existed and what was decided on it lives in the same place. It can be audited and it can be replayed.

Where this starts in practice

It does not start with buying a license. It starts by picking a use case where real time changes a measurable outcome, and bringing into the stream only the events that case needs.

We have seen projects that set out to publish the entire core as events and spend six months stuck in modeling. And we have seen projects that start with three event types, solve one concrete fraud case and grow from there on real demand rather than speculative planning.

The second path reaches production. The first usually ends up as a slide deck.

What to review before adding another agent

If you are weighing whether to take an agent to production, these questions separate the pilots that survive from the ones that do not:

1. Where does the data the agent will see come from, and how old is it when it arrives?
2. If that data changes while the agent is reasoning, what happens?
3. Can you reconstruct, six months later, what information it had available when it decided?
4. When you add the fifth agent, how many new integrations will be needed?

If any of the four lacks a clear answer, the problem is not the model.