The Data Was Right. The Decision Was Right. The Action Was Still Wrong.
I’ve been thinking about one slightly awkward part of Agentic AI.
Not hallucinations. Not prompts. Not whether the model is clever enough.
Timing.
We’ve spent a lot of time talking about how to give agents better enterprise context. Quite rightly too. If the data underneath the agent is stale, fragmented or misunderstood, a smarter model won’t save you.
I wrote about that recently in Most Agent Failures Won’t Look Like AI Failures. The basic point was that the AI can behave perfectly and still get the business wrong because the context underneath it is wrong. Most Agent Failures Won’t Look Like AI Failures
But there’s another version of the problem that I think gets even more interesting.
What if the context wasn’t wrong?
What if the data was completely correct when the agent saw it?
The agent reasoned properly.
It made the right decision.
And the action was still wrong.
Welcome to production.
The business doesn’t stop while the agent is thinking
Take a logistics operation.
A container is arriving late into a distribution hub. An agent checks the expected arrival time, dock availability, labour, onward transport, storage capacity and priority of the goods.
At 10:14, dock 6 is available.
The agent works through the options and decides dock 6 is the best place to send it.
Perfectly sensible.
At 10:15 another vehicle suffers a mechanical issue at the gate and operations assigns dock 6 manually.
Nothing went wrong with the AI.
Nothing went wrong with the data.
Nothing even went wrong with the original decision.
The world just changed.
If our agent now carries on and books dock 6 because that was the correct answer 60 seconds ago, we have a different kind of problem.
And it is not really an AI problem at all.
Data people have seen versions of this forever. State changes. Transactions happen. Events arrive late. Two processes try to update the same thing. A perfectly valid assumption stops being valid.
The difference is that we are now putting a reasoning step in the middle.
The architecture becomes:
business state → agent reads → agent reasons → agent acts.
And quite a lot can happen between the first and last step.
That little gap matters.
Read-only agents mostly hide this problem
This is partly why read-only agents are such a sensible starting point.
They can summarise something. Explain something. Find something. Recommend something.
If the world changes while they are doing it, the consequence is usually manageable.
Somebody reads the answer and makes the final call.
But we’re clearly moving past that.
Google is already describing this shift as moving from systems of record and intelligence towards systems of action — AI that does not just interpret the business but starts participating in it. Google Cloud on the Agentic Data Cloud and systems of action
That is where things change.
“Which shipment should we prioritise?” is one type of AI problem.
“Prioritise the shipment” is another.
“Which maintenance window should we use?” is one thing.
“Reschedule the equipment and notify the teams” is another.
You get the idea.
Once the agent can actually change production state, I think we need to be much more precise about the boundary between what the AI decides and what the enterprise commits.
I don’t particularly want the agent to own that last step
This is where my thinking has changed a bit.
We spend a lot of time discussing agent permissions.
Can it call this API?
Can it update this record?
Does it have access to this application?
All important.
But just because an agent is authorised to perform an action does not mean the action is still valid when it gets there.
There is a difference.
Say an agent is helping manage a portfolio of renewable energy assets.
It spots that a battery installation has spare capacity and recommends moving some load into it.
When it made the decision, everything checked out.
A few seconds later a monitoring event reports abnormal cell temperature.
Now the battery should not take the additional load.
The permission hasn’t changed.
The identity of the agent hasn’t changed.
The business state has.
That is why I think we need a small but quite important separation:
The agent proposes. The production layer commits.
The agent is still doing useful work. It is interpreting a lot of information, understanding the situation and deciding what should happen.
But before the actual change goes through, something deterministic gets one last look at reality.
Is the asset still available?
Is the capacity still there?
Is the record still on the version the agent saw?
Has another process already done this?
Do the business rules still pass?
Does this particular action need approval?
If yes, fine. Carry on.
If not, stop and re-evaluate.
No second AI model required.
No philosophical debate about whether the first model was “right”.
Just normal production engineering.
We already know how to solve quite a lot of this
That is the funny thing.
Agentic AI is introducing some very new possibilities, but a lot of the production problems underneath it are old friends.
Concurrency.
Retries.
State.
Idempotency.
Versioning.
Reconciliation.
Exception handling.
Audit.
AWS makes this point quite nicely in its recent work on Agentic Readiness. One of the examples is almost painfully ordinary: an agent calls a shipping service, gets a timeout and retries. The first call actually succeeded. Without idempotency, you now have two shipments. AWS Agentic Readiness
That isn’t the agent hallucinating.
It is just an integration that was never designed for an autonomous client that retries at machine speed.
AWS’s Well-Architected guidance now explicitly recommends idempotent execution for agent actions for exactly this reason. AWS guidance on idempotent agent actions
So perhaps we shouldn’t throw away decades of engineering discipline just because an LLM has appeared in the workflow.
Quite the opposite.
This is where I think the architecture gets interesting
The simple agent architecture often looks like this:
Enterprise data → AI → action.
Nice diagram.
Not enough.
I think the production version needs another step.
Enterprise state → governed context → agent reasoning → proposed action → validation against current state → production action.
The AI owns the uncertain bit.
The engineering owns the certain bit.
That distinction matters.
We have been working on something similar around IOblend for a while now. Initially the focus was on the context coming into the agent: keeping live operational data synchronised, resolving conflicting records, combining current and historical context and controlling what an agent is actually allowed to see.
That is the thinking behind our work on MCP, AI agents and live enterprise data.
But the reverse direction is becoming just as important.
What happens when the agent wants to do something?
I increasingly think that should be treated as another production dataflow.
Not:
AI → ERP.
More like:
AI proposes → current state is checked → deterministic rules run → approvals are applied where necessary → controlled write → reconcile what happened.
That is a much more comfortable architecture to me.
Human approval doesn’t completely solve it either
Here’s another wrinkle.
Let’s say the action is sensitive enough that we keep a human in the loop.
Good.
The agent makes a recommendation at 9am.
Somebody approves it at lunchtime.
Can we now execute it?
Maybe.
But three hours have passed.
The human approval proves somebody with the right authority agreed with the action.
It does not prove that the business conditions are still the same.
That state still needs checking.
This sounds obvious when you write it down.
I’m not convinced it is obvious in many of the architecture diagrams we are currently drawing.
Agent → approval → execute looks reassuring.
Sometimes it should be:
Agent → approval → check again → execute.
A human can approve the decision.
The systems still need to confirm the facts.
And this is going to happen faster than we are used to
There is another reason I think data teams need to pay attention to this.
Agents don’t behave like people.
One person may look at an application, check a couple of things and make one change.
An agent might make ten calls to establish context, retry two of them, invoke another tool, ask another agent something and then perform an action.
Now multiply that across hundreds of processes.
Google’s recent AI infrastructure work makes the same point: one prompt can fan out into multiple queries and actions across underlying systems, creating completely different load patterns from the human workflows many enterprise applications were originally designed for. Google Cloud State of AI Infrastructure 2026
That brings us straight back to production data engineering.
You probably don’t want hundreds of agents polling SAP every few seconds just to find out whether something has changed.
You probably don’t want every agent building its own interpretation of customer state.
And you definitely don’t want every AI project inventing its own method for retrying writes, resolving conflicts and deciding whether the data it saw five minutes ago is still safe to act upon.
This is where a production data layer starts to make sense.
Not because everything needs to move into another platform.
Actually, quite the opposite.
The systems can stay where they are.
The existing data platforms can stay where they are.
The agent can run wherever the organisation wants it to run.
What matters is having a consistent way of maintaining and validating the enterprise state between them.
That is where we are increasingly putting IOblend.
The existing architecture already gives us batch, CDC and streaming in the same production model, state handling, quality, entity resolution, lineage, exception management and controlled delivery. How the IOblend production data layer works
And the Agentic AI side is increasingly about combining that deterministic engineering with AI only where AI actually adds something useful. IOblend Agentic AI data pipelines
AI interprets.
AI reasons.
AI proposes.
The production layer still controls what becomes enterprise data or changes enterprise state.
I think that separation is going to matter quite a lot.
The last question before the write
We are going to keep making models better.
Agents will get better at planning.
MCP and other standards will make tools easier to connect.
Identity and permissions will improve.
All good.
But none of those things make the business stand still.
A supplier confirms something.
A machine fails.
A price moves.
An engineer overrides a schedule.
Another agent gets there first.
A payment clears.
A human changes their mind.
And suddenly the perfectly correct answer from 30 seconds ago is no longer correct.
That doesn’t mean autonomous agents are a bad idea.
Quite the opposite. I think this is exactly the kind of engineering that makes them much more practical.
We don’t need to give the AI responsibility for everything.
Let it do the bit it is good at.
Then, before its decision becomes a real change in the business, ask one boring but very useful question:
Is this still true?
That might turn out to be one of the more important AI guardrails we build.
