The difficult part starts when an agent stops describing the business and starts changing it
Enterprise AI has become very good at telling us what it thinks should happen next.
It can investigate an incident, review a supplier, classify a service request, prepare an employee onboarding plan or recommend a configuration change. In many cases the answer is good enough that the obvious next question is: if the agent already knows what should happen, why not let it do it?
That is where the architecture changes.
A recommendation can be wrong without immediately changing the state of the business. An action cannot. Once an agent can deploy, update, provision, approve, close, delete or trigger something downstream, the quality of the context underneath the decision starts to matter in a very different way.
This is one reason I think so many enterprise AI programmes eventually encounter what looks like a read-only ceiling.
The model may be capable of more. The organisation simply becomes much less comfortable with what happens next.
This is not just enterprise caution
There is a temptation to interpret this as organisations being conservative about AI.
I am not sure that is the right explanation.
NIST’s current work on software and AI-agent identity explicitly describes the transition from generating content to taking actions such as deploying code into production. Its focus is increasingly on how agents should be identified, authorised and audited when they can interact with multiple datasets, applications and tools. NIST: Software and AI Agent Identity and Authorization
The same concern is visible in practitioner discussions. In one recent DevOps conversation, an engineer described deliberately wanting AI coding agents to use a separate read-only AWS role even though the human developer already had write permissions. The concern was not whether the developer was trusted. It was how to reduce the agent’s blast radius. Practitioner discussion: managing AWS access for AI agents
That distinction matters.
We already know how to give software credentials.
The harder question is what happens when software starts deciding when to use them.
Consider an infrastructure agent
Imagine an AI operations agent monitoring an application environment.
It has access to deployment history, observability data, infrastructure configuration, recent incidents and a service catalogue. A latency spike appears after a release. The agent identifies the most likely cause and recommends rolling back a configuration change.
As a read-only system, that can be extremely useful. An engineer can inspect the recommendation, look at the dependencies and decide whether the rollback makes sense.
Now give the agent permission to perform the rollback itself.
Nothing about the model’s reasoning has necessarily changed. But the evidence supporting that reasoning suddenly matters much more.
Was the dependency map current? Did another team change a feature flag five minutes earlier? Is the service still using the configuration version shown in the deployment log? Has traffic already been rerouted? Is there a maintenance operation taking place that is not represented in the monitoring data?
The agent can be completely authorised to make the change and still be operating from the wrong state.
That is the point I think matters.
Permission to perform an action and confidence in the state behind that action are different problems.
We need both.
The same problem appears in much less technical workflows
Take employee onboarding.
This is exactly the sort of multi-step workflow that vendors are beginning to expose through enterprise agent platforms. Google’s current Gemini Enterprise documentation, for example, uses employee onboarding as one of its examples of workflows that can span multiple applications and combine automated steps with human intervention. Google Cloud: Gemini Enterprise workflows
At first, the use case sounds straightforward.
A new employee joins. The agent reads the HR record and prepares the tasks: create accounts, arrange meetings, request equipment, grant application access and notify the relevant teams.
Then we allow it to execute those tasks.
Now imagine that the employee’s role changed after the original onboarding record was created. Or the person has moved from employee to contractor. Perhaps their location changed and that affects which systems or datasets they may access. Perhaps a manager amendment exists in one HR workflow but has not yet propagated into the downstream directory.
The agent may have done exactly what it was asked to do.
It may have correctly authenticated.
Every API call may have succeeded.
The failure happened before any of those things.
The agent was acting on a version of the employee that was no longer true.
For years, organisations could tolerate these inconsistencies because a person often sat between the systems. Someone noticed the title looked wrong. Someone questioned the requested access. Someone knew that the contractor conversion happened yesterday.
Automation removes some of those informal correction mechanisms.
That is valuable.
It also exposes how much operational integrity previously depended on people noticing that systems disagreed.
AI is turning old data debt into execution risk
We have discussed this before from the reasoning side.
In Most Agent Failures Won’t Look Like AI Failures, the important point was that an agent can reason perfectly over context that is incomplete, stale or assembled from different moments in time.
The read-only ceiling takes the same problem one step further.
When an agent only explains something, weak context becomes an information-quality problem.
When the agent acts, weak context becomes an operational problem.
That is a significant shift for data teams.
A duplicate supplier record used to create reporting noise.
A write-enabled procurement agent might update the wrong supplier.
A delayed employee-status feed used to create an inconsistent dashboard.
An onboarding agent might provision inappropriate access.
A stale infrastructure inventory used to frustrate an engineer.
An operations agent might modify a service that is no longer configured the way its context suggests.
None of these are particularly exotic AI failures.
They are familiar enterprise data problems with a new consumer.
The difference is that this consumer can now act.
Supplier data is a good example
Consider a procurement agent helping onboard or maintain suppliers.
The information it needs may be spread across a procurement platform, ERP, compliance systems, document repositories and perhaps a supplier portal. Several records may describe the same organisation. Corporate ownership may have changed. A compliance review may still be pending. A supplier may be approved for one category or legal entity but not another.
A human buyer navigating this process will often know that the systems do not quite agree.
An agent sees records.
If we ask it to summarise the supplier, we can tolerate some uncertainty.
If we allow it to update the supplier master, activate a vendor or move the workflow forward automatically, uncertainty becomes much more consequential.
This is where the phrase “good data” starts to feel too vague.
The issue is not simply whether each field passes a quality check.
The organisation needs confidence that the state being presented to the agent is actionable.
That is a higher bar.
This is where deterministic controls still matter
There is understandable excitement around giving agents more reasoning capability.
But not every enterprise decision benefits from probabilistic reasoning.
If a mandatory compliance source is unavailable, the model does not need to decide whether that probably matters.
If two active employee records resolve to the same person, the agent does not need to choose the one that looks most plausible.
If the service configuration changed after the agent collected its context, it should not simply reason harder about the old version.
These are conditions we can detect.
And where a condition can be expressed deterministically, it probably should be.
The agent can still do the interesting work around it. It can interpret, investigate, plan, explain and choose between permitted options.
But the boundary between usable state and questionable state does not have to live entirely inside the model.
That becomes especially important as agents gain access to more tools.
OWASP’s guidance on excessive agency makes this point from the security side. It recommends minimising available functionality and permissions, enforcing authorisation in downstream systems and using explicit approval for high-impact actions rather than trusting the model itself to decide what it should be allowed to do. OWASP: Excessive Agency
I think there is a parallel principle for data:
Do not make the model decide whether the business state is valid if the architecture already knows how to establish that deterministically.
Human approval is useful, but only if the human sees something trustworthy
The obvious response is to keep a person in the loop.
That makes sense for many consequential actions.
But human approval does not automatically make an agent workflow safe.
AWS makes an interesting observation in its guidance for agentic systems: sending every action for review can create approval fatigue, while asking humans to approve an action without giving them sufficient context can turn the approval into a formality. AWS: Human-in-the-loop for critical decisions
That is important for data teams.
Suppose an infrastructure agent tells an engineer:
“The deployment introduced the fault. Roll back version 7.42?”
The engineer clicks approve.
What exactly have they approved?
If the evidence includes current deployment state, dependency status, the relevant change events and the data sources behind the conclusion, the approval is meaningful.
If the agent simply produced a convincing summary from incomplete operational data, the human approval button has not repaired anything.
The human has simply endorsed the agent’s context.
We should probably stop treating human-in-the-loop as a substitute for production integrity.
It is another control.
A useful one.
But it still depends on the information underneath it.
Read-only and write-enabled agents should not necessarily see the same architecture
This leads to another interesting question.
Why do we assume that the architecture used to answer a question should automatically be the architecture used to execute an action?
A read-only research agent may reasonably explore several sources and present what it finds.
A consequential agent may need something more constrained.
Instead of allowing the agent to query five systems independently, perhaps the organisation first establishes the relevant operational state outside the model. The agent reasons against that state. Identity and policy determine which operations are permitted. The target application still remains responsible for enforcing the final transaction.
That creates clearer responsibilities.
The AI does not become the integration layer.
The identity platform does not become the data-quality engine.
The operational application does not need to explain the entire enterprise context.
And the data layer does not decide whether a particular human or agent has authority to perform the final action.
Those boundaries matter.
We explored a similar idea from the data-access side in MCP, AI Agents and Live Enterprise Data. MCP can make systems and tools available to an agent, but connectivity alone does not establish whether the information behind those tools is current, consistent or appropriate for the task.
Write access makes that distinction harder to ignore.
The agent probably should not become responsible for understanding the whole enterprise
Modern agent frameworks make it increasingly easy to give AI access to a large number of systems.
An agent can have tools for ServiceNow, Salesforce, cloud infrastructure, ERP, databases, document stores and internal APIs. Technically, that is a remarkable improvement over building bespoke interfaces for every use case.
Architecturally, though, it introduces an interesting risk.
We can gradually make the agent responsible for resolving the enterprise.
Which employee record is authoritative? Which supplier status wins? Which deployment state is current? Which compliance rule applies? Which system owns this attribute? What does this code mean in this business process? Did something change between the first and fourth tool call?
These are not necessarily reasoning problems.
Many are integration, state-management and governance problems.
If the organisation already knows how those questions should be answered, there is little benefit in asking every individual agent to rediscover the answer.
That is also one of the broader themes behind Copilot Agents Need More Than Connectors: connecting another system does not automatically make the context behind it agent-ready.
At some point, the stitching itself becomes the architecture.
The production data layer becomes part of the safety model
This is where the role of the data layer becomes more interesting.
Traditionally, a production data pipeline exists to move information reliably from one system to another, or into an analytical environment.
Agentic AI gives it another possible responsibility.
It can help establish whether the operational context presented to an agent is complete enough, current enough and internally consistent enough to support the next step.
That may involve CDC and streaming to maintain current state, entity resolution to reconcile records, schema and quality checks, deterministic business rules, lineage, historical state and explicit exception handling.
IOblend already operates in this part of the architecture. Its production model supports batch, CDC and streaming alongside state, quality, lineage, data contracts and exception handling. IOblend for Data Engineers
That does not make IOblend an agent authorisation system.
Nor should it.
Identity platforms should still establish who or what is acting. Downstream applications should still enforce permissions. Approval systems should still determine when a human decision is required.
The data-side responsibility is different.
It is to make sure the state presented to those processes is worth acting upon.
That separation feels important.
Not every action needs the same level of control
There is also a danger of treating every write as equally risky.
An agent creating a draft service ticket is not the same as an agent disabling a production account.
Adding a proposed classification to a record is not the same as approving a new supplier.
Preparing a configuration change is not the same as deploying it.
The sensible architecture is unlikely to be “everything autonomous” or “everything requires approval”.
It will probably be graduated.
Some actions can be performed automatically because they are reversible, low impact and tightly constrained.
Others may require stronger data validation.
Some may require explicit approval.
A smaller number may remain outside the agent’s authority entirely.
This is why the discussion about agent autonomy ultimately becomes an architecture discussion.
The organisation needs to understand not only what the agent is capable of doing, but what has to be true before the system should allow it to do it.
That second question reaches much deeper into the data estate.
Read-only may actually be a useful test phase
Perhaps the read-only ceiling is not merely a limitation.
It can also be diagnostic.
Before giving an agent authority to change an operational system, watch what happens while it is still recommending actions.
Can we reproduce the operational state behind its recommendation? Can we tell which source contributed which fact? Can we identify when one source becomes stale? Can conflicting records be surfaced rather than silently reconciled by the model? Can we preserve the history necessary to understand what the agent knew at that moment?
If the answer is no, autonomy will not fix those problems.
It will simply remove one of the people currently compensating for them.
That is why I suspect some of the most useful lessons from early enterprise agents will have very little to do with prompt engineering.
They will tell organisations where their operational state is poorly assembled.
Where identity is unresolved.
Where history disappears.
Where important business rules only exist in people’s heads.
Where systems disagree and humans quietly make the judgement call.
AI makes those weaknesses visible because it does not inherit the informal knowledge that has allowed the organisation to live with them.
The interesting boundary is not really read versus write
Read-only is a useful shorthand, but it may not ultimately be the right dividing line.
The better distinction may be between informational and consequential AI.
Some read operations can be highly consequential. A recommendation can influence a major decision even if the agent never touches a production system.
Some writes are relatively harmless and easily reversible.
What matters is whether the agent’s interpretation of enterprise state can create a meaningful consequence.
Once it can, the supporting architecture needs a different level of confidence.
Identity matters.
Authorisation matters.
Least privilege matters.
Human approval matters.
But underneath all of them sits another, less fashionable question:
What version of the business is the agent acting on?
That is where data engineering comes back into the centre of the AI discussion.
The model may already be capable of taking the next step.
The more interesting question is whether the enterprise underneath it is ready for the consequences.
If you are working through this same boundary, moving from agents that inform to agents that can safely act, it is worth looking closely at the data architecture underneath them.
That is the part of the problem we spend a lot of time cracking at IOblend, and we are always interested in having a chat with you to hear your experience and see if we can help.
IOblend: See more. Do more. Deliver better.
