By Andrew Tan
Fresh enough for an AI agent? The data freshness budget nobody defines
Most teams talk about AI context as a storage problem. The harder question is whether the data is fresh enough for the action the agent is about to take.
A lot of AI infrastructure conversations are still aimed at the wrong bottleneck.
Teams debate vector databases, prompt caching, long-term memory, MCP servers, and which model should sit behind the agent. All of that matters. None of it answers the question that actually determines whether an agent is safe to use in production.
How fresh is the data when the agent decides to do something?
That question sounds boring. It is not boring when the agent sends the wrong refund, approves the wrong order, escalates the wrong incident, or calls the wrong tool because it is looking at a customer record from twenty minutes ago.
Most data teams already understand quality, lineage, and schema drift. Freshness gets treated like a nice-to-have until agents enter the picture. Then freshness stops being a dashboard preference and turns into an operational boundary.
Context is not the same as permission
This is the part many teams skip.
An agent can have plenty of context and still have the wrong context for the action you want it to take. Ten million rows in a warehouse do not help if the one field that matters changed three minutes ago and your sync runs every hour.
That is the difference between informative data and actionable data.
Informative data helps an agent explain what happened last week. Actionable data lets it decide what should happen right now.
Those are not the same workload.
A support copilot summarizing the last five tickets can tolerate some lag. An agent that decides whether a refund already happened cannot.
A sales assistant drafting an account brief can work from nightly CRM syncs. An agent that routes a live lead based on current product usage probably needs data that is a few minutes old at most.
A finance bot preparing a monthly variance summary can stay batch. An agent that freezes a suspicious payout cannot.
The mistake is treating all AI context as one category called "AI-ready data."
It is not one category. It is a stack of decisions with different freshness requirements.
The freshness budget
The cleanest way to think about this is a freshness budget.
Every agent task has a maximum acceptable lag between what happened in the source system and what the agent sees when it acts.
That lag budget depends on the consequence of being wrong.
Here is a simple version:
| Agent task | Typical freshness budget | What happens if you miss it |
|---|---|---|
| Weekly account summary | 24 hours | Slightly stale narrative |
| Internal KPI Q&A | 1 to 4 hours | Confusing answers, low trust |
| Sales lead routing | 5 to 15 minutes | Bad prioritization, slower follow-up |
| Customer support refund decision | Under 5 minutes | Duplicate refunds, policy mistakes |
| Fraud or risk intervention | Seconds to 1 minute | Real money loss |
This is not a universal table. It is a forcing function.
Most teams never define these numbers at all. They just say they want "real-time AI" or "AI-ready pipelines" and hope the stack sorts itself out later.
It will not.
If you do not define a freshness budget, the default budget becomes "whatever the pipeline already does." That is usually an accident, not a design choice.
Batch is still fine for a lot of AI work
I do not think the answer is to push every workload into streaming.
That is expensive. It also creates a new class of operational problems if the team does not need it.
Some AI use cases are perfectly happy on batch:
- Writing internal summaries
- Preparing research briefs
- Tagging support conversations for trend analysis
- Drafting renewal prep notes
- Enriching planning docs
- Creating weekly executive recaps
These tasks benefit from completeness more than immediacy.
You usually want the full record, not the newest event from fifteen seconds ago.
This matters because a lot of AI messaging right now frames the future as one giant real-time system. That is a good way to overspend.
The better question is narrower: where does low-latency data actually change the quality of the action?
If the answer is nowhere, keep it batch.
If the answer is specific interfaces, move those interfaces first.
The dangerous middle
The real trouble is not clearly batch and not truly real-time.
It is the mushy middle where teams have pipelines that update every hour, or every thirty minutes, or whenever a connector feels like catching up, and then they hand that data to an agent with permission to act.
That is where mistakes get expensive.
Hourly freshness sounds decent until you map it to the workflow.
If a customer upgrades at 10:02 and the agent sees the old plan until 11:00, you have almost an hour where it can deny an entitlement the customer already paid for.
If an order is canceled at 2:11 and your inventory assistant does not learn that until 3:00, it can reorder stock you no longer need.
If a chargeback flag lands in one system before another, your risk agent may see a healthy account and approve the next transaction with full confidence.
Nothing is obviously broken in those examples. The jobs ran. The tables updated. The dashboard probably looks fine.
The problem is that the action window is tighter than the data window.
That gap is where agent failures live.
Approval gates are a freshness strategy too
There is another point that gets lost in the rush to automate.
Sometimes the right answer is not faster data. Sometimes the right answer is an approval gate.
If an agent works on stale or ambiguous context, you do not always need to block the use case forever. You may just need to change the last step.
Let the agent gather data. Let it draft the response. Let it recommend the action. Then require a human approval if the freshness budget is not met or if the decision touches money, compliance, access, or customer-facing risk.
This is not a failure of automation. It is part of the design.
Good AI systems do not just think about model quality. They think about when not to act alone.
That is especially true when the underlying data arrives through a mix of batch syncs, CDC pipelines, event streams, and external APIs that all move at different speeds.
You need freshness by interface, not by platform slogan
A lot of vendor positioning blurs this on purpose.
The promise usually sounds something like this: connect all your data, feed your agents, unlock real-time decisions.
Fine. But which decisions?
You do not need one giant freshness target for the whole company. You need freshness targets by interface.
Start with the places where an agent crosses from advice into action:
- approving or denying something
- sending a customer communication
- changing access or entitlements
- moving money
- opening or closing incidents
- triggering downstream systems automatically
Those interfaces deserve explicit lag limits, monitoring, fallback behavior, and ownership.
If the pipeline misses the budget, what should happen?
Maybe the action pauses.
Maybe the agent can still draft but not send.
Maybe it can operate on a narrow safe subset of tools.
Maybe it needs a human in the loop.
The point is to define this before the first incident teaches it to you.
What this means for the data stack
Once you define freshness budgets, the stack conversation gets easier.
You can stop arguing about batch versus streaming as ideology.
Some interfaces need event-driven processing. Some need CDC with tight SLAs. Some are fine with scheduled syncs. Some need a hybrid path where the same workflow handles both historical backfills and low-latency updates.
That last category is the one that gets painful fast if your architecture splits batch and streaming into separate systems.
Now you are maintaining two versions of the same business logic. One answers historical questions. One powers live actions. They drift. Your agent gets inconsistent state depending on which path it touched.
That is why I think the better long-term design is not "real-time everywhere." It is one runtime that can handle both batch and streaming, plus the orchestration around them, without forcing the team to rebuild the workflow every time a freshness requirement changes.
That is also where layline.io fits. The point is not to turn every pipeline into a stream. The point is to let teams tighten freshness where the action requires it, keep batch where it is enough, and manage both in one operational model.
The practical test
If your team is rolling out AI agents right now, ask one question for every agent action:
What is the maximum age of data we can tolerate before this action becomes unsafe, wrong, or embarrassing?
Write the number down.
If nobody can answer it, you do not have an AI problem yet. You have a requirements problem.
And if the answer is "it depends," that is fine. Break it down by interface until it stops depending.
The teams that do this well will not be the ones with the loudest AI stack. They will be the ones that know which decisions need seconds, which need minutes, which can wait until tomorrow, and where a human still belongs in the loop.
That sounds less exciting than the usual agent demos.
It is also the difference between a helpful system and one that creates a new kind of on-call rotation.
Andrew Tan is a serial entrepreneur and founder of layline.io, building enterprise data processing infrastructure that handles both batch and real-time workloads at scale.
