An AI agent can identify the right asset, calculate the best route and still have no authority to proceed.
Imagine a utility operator asking:
“Inspect Transformer T17 and arrange a follow-up if you detect an abnormal condition.”
An agent could locate the transformer, retrieve inspection history, analyze thermal imagery and prepare a maintenance recommendation.
But what does “arrange a follow-up” permit?
Create a draft work order? Dispatch a technician? Send a drone into the compound? Change an inspection schedule? Issue a command to connected equipment?
One sentence can conceal several levels of responsibility.
As GIS becomes more agentic, this distinction deserves as much attention as spatial reasoning itself.
Knowing where to act does not establish permission to act.
From spatial answers to operational consequences
Traditional GIS workflows usually leave an explicit human step between analysis and action.
An analyst identifies a risk. An engineer reviews the result. An authorized person decides what happens next.
Agentic workflows can bring those steps closer together. A system may interpret an objective, select spatial tools, retrieve evidence and initiate another workflow.
That creates useful possibilities: faster inspection planning, fewer manual handoffs and better coordination across assets, crews and operating conditions.
It also changes the governance problem.
A spatially correct result can trigger an inappropriate action if the agent misunderstands its mandate.
A route may cross a restricted work zone. A maintenance request may duplicate an active intervention. An inspection mission may rely on access permission that expired yesterday.
The question becomes:
Which actions may this agent take, on this asset, under these conditions, and who granted that authority?
Tool access is only the beginning
Giving an agent access to a routing engine establishes that it can calculate routes.
Giving it access to a work-order API establishes that it can technically submit a request.
Neither establishes that a particular request is authorized.
Physical authority needs a narrower scope.
An agent might be allowed to review inspection evidence across an entire facility, propose interventions for selected equipment and create draft work orders. Dispatching personnel could require approval from the operations supervisor. Equipment control could remain outside its mandate entirely.
These permissions should be explicit enough for software to enforce.
“Maintenance agent” is a role description. It is insufficient as an operational boundary.
A useful authority record would specify the agent, asset or area, permitted action, purpose, validity period, required approvals and conditions that suspend permission.
Consider Transformer T17
Here is an illustrative workflow.
An inspection agent receives permission to review T17’s condition and recommend whether another inspection is needed.
First, it establishes identity.
Does the thermal observation belong to T17? Is the asset tag consistent with the location and equipment record? Could the image show the adjacent transformer?
Next, it checks the evidence.
When was the observation captured? Was the sensor suitable for the task? Were operating conditions recorded? Is the apparent temperature difference meaningful under the observed load?
The agent then identifies a possible anomaly.
Its authority permits it to assemble an evidence package and draft an inspection request. Dispatch requires a supervisor’s approval.
The supervisor approves a defined inspection window, with site-access conditions and an assigned team.
Before dispatch, the system checks again. Is the approval still valid? Has another team opened a conflicting work permit? Has the site entered a restricted operating state?
If a condition has changed, the workflow pauses for review.
The original approval remains part of the record, but it no longer provides sufficient authority to proceed.
Approval must be evaluated against the conditions in which it will be used.
Authority needs an expiry mechanism
Physical conditions change faster than many administrative records.
A facility may approve an inspection in the morning and restrict access in the afternoon. An asset may enter maintenance. A contractor’s authorization may end. A new observation may undermine the evidence supporting an earlier decision.
An agent’s permission therefore needs both an expiry time and conditions for earlier suspension or revocation.
For longer tasks, checks should occur at meaningful execution boundaries. If authority is withdrawn during execution, the response should follow an engineered pause, abort or safe-state procedure appropriate to that task.
A token that remains technically valid should never override a withdrawn operational permission.
Four connected records make this practical
For an operational intelligence platform, I would organize this around four connected structures.
The Agent Registry records which agent is acting, its version, owner, capabilities and approved role.
The Asset Graph establishes which physical asset is involved, where it sits and what it depends on.
The Evidence Graph connects observations, inspection findings, timestamps, uncertainty and the reasoning supporting a proposed action.
The Authority Graph records who can approve which actions, within what scope, and under which conditions.
Together, these structures can answer a more useful question than “Can the agent call this tool?”
They can answer:
“May this agent use this tool to perform this action on T17 now?”
The enforcement should sit in the workflow and execution systems. An instruction inside the agent’s prompt is insufficient.
Human oversight needs a defined job
“Keep a human in the loop” sounds reassuring, but it leaves important questions unanswered.
Which human? Reviewing what evidence? Approving which action? For how long?
A meaningful approval should show the intended asset, proposed action, supporting evidence, unresolved uncertainty and expected consequence.
The reviewer should be able to approve a narrower scope, request more evidence or reject the proposal.
Otherwise, human oversight can become a confirmation button attached to an automated recommendation.
The objective is to place accountable judgement where the consequence requires it.
Record the outcome, including restraint
An audit trail should connect the original request to the evidence, policy checks, approval, execution and verified result.
It should also capture decisions to wait.
If an agent declines to dispatch because asset identity is uncertain, that is a useful operational outcome. If fresh evidence removes the need for intervention, the record should explain why the proposed action changed.
Successful automation includes justified restraint.
For infrastructure operators, the value of agentic GIS will depend on how reliably it connects spatial reasoning to accountable action.
That suggests a practical starting point: choose one asset class, one bounded workflow and one explicit authority model. Establish the evidence requirements, approval limits and stop conditions before expanding autonomy.
A map can show an agent where an asset is.
Operational evidence can help establish what needs attention.
Authority determines what the agent may do next.
