Vista interpretationGovernance controls are context-specific

AI agents & authority

Governed agent

An agent whose evidence, tools, permissions, state changes, validation rules, and escalation duties are explicit, and whose authority rises or falls with the consequence of the action.

Operator definition

Most discussions of agent governance start too late. They ask whether a human can stop the agent.

The better question is: what can the agent change before anyone has to stop it?

A governed agent is not simply an agent with a human nearby. It is an agent whose evidence, tools, permissions, state changes, validation rules, and escalation duties are explicit. Its authority rises or falls with the consequence of the action.

An agent may notice a supplier delay, gather records, identify affected demand, create a scenario, call a planning engine, compare options, explain the tradeoffs, and route a decision for approval.

But those are not equivalent acts.

Reading a plan is not changing it. Creating a scenario is not making it the baseline. Recommending a transfer is not reserving supply. Drafting a customer message is not making a customer promise.

The operating principle is simple: agents build the case. People, or explicitly delegated policies, make the consequential call.

Why this matters

Agents can compress hours of analytical work into minutes. They can search records, trace causes, test alternatives, and prepare a decision package before a planner enters the workflow.

That speed is useful. It also creates risk.

A single conversational interface may summarize evidence, estimate an outcome, call a calculation, and change a record. Because these acts appear in one place, they can look like one seamless capability. They are not. Each has a different evidence standard and a different level of authority.

A fluent explanation can sound like a verified conclusion. A recommendation can look like an approved decision. An inferred date can quietly become official supply.

Governance preserves the line between assistance and authority.

The authority ladder

Epistemic status: the exact controls will vary by context. The pattern is the same: the greater the consequence, the stronger the evidence, validation, and approval required.

A useful sequence is:

Observe -> Summarize -> Investigate -> Propose a scenario
-> Request a validated calculation -> Recommend
-> Route approval -> Execute a permitted change

Each step should earn the next level of authority.

Agent authority ladderstate matrix

Observe

Read the event without changing planning state.

May doWatch an event stream, open scoped records, and record that something changed.

RequiresRole-scoped access, source timestamp, actor identity, and a read log.

Must not doConclude, reserve, reallocate, release, or promise.

Action	Agent may do	Required control	Boundary
Observe read-only	Read an email, alert, exception, or commitment change.	Scoped access, source timestamp, actor identity, and read log.	No conclusion and no state change.
Summarize grounded text	Produce a grounded summary from named records.	Evidence links, confidence or abstention rule, and model version.	No calculation authority and no accepted planning state.
Investigate evidence	Retrieve the purchase order, supplier history, affected demand, policy, and time fence.	Allowed tools, freshness checks, and query trace.	No hidden priority and no selective evidence.
Propose a scenario what-if	Create a bounded what-if case with explicit assumptions.	Scenario ID, changed inputs, isolated baseline, and expiration rule.	The scenario is not the plan.
Request a calculation validated tool	Call an identified planning method to calculate consequences.	Run ID, method version, configuration, and inputs.	Generated prose is not numeric authority.
Recommend judgment package	Compare feasible options and explain the tradeoffs.	Alternatives, constraints, risks, and evidence bundle.	A recommendation is not a commitment.
Route approval authority	Send the case to the required person or delegated policy.	Named approver, consequence tier, threshold, and decision record.	The agent cannot approve its own high-impact action.
Execute a permitted change state change	Change a specific state under explicit authority.	Validation, duplicate-action protection, rollback, monitoring, and escalation.	Only the delegated action, object, quantity, and time window.

The numerical result should come from an identified method suited to the task: a rule engine, optimizer, statistical model, simulation, or validated learned policy.

The agent may call that method and explain its result. It should not blur the difference between the calculation and the explanation.

A supplier delay

Suppose a supplier sends an email saying that a critical receipt "may slip about a week."

An ungoverned agent may turn that sentence into an official receipt date. A governed agent turns it into a case for decision.

Governed handling of an uncertain receipt dateEvery step names the action and the boundary it must not cross.

Step	Agent action	Boundary
01	Extract the possible new date and label it unverified.	Do not treat it as official supply.
02	Retrieve the purchase order, supplier history, affected demand, and time fence.	Do not choose a priority or hide affected demand.
03	Create a scenario with the receipt seven days late.	Do not publish the scenario as the baseline plan.
04	Call the planning engine and identify affected commitments.	Do not let generated language become the calculation.
05	Compare options such as a partial transfer, approved substitute, or expedite.	Do not reserve supply or promise an alternative.
06	Draft the evidence package and route it to the planner.	Do not self-approve the decision.
07	Keep the official receipt, allocation, and promise unchanged until approval.	No state change without authority.

Each step should preserve its evidence: the supplier email, sender and timestamp, records retrieved, scenario inputs, engine run, constraints checked, approver, and final decision.

The central distinction is easy to miss:

The email is evidence of a possible change. It is not the change itself.

What fails without governance

Without clear boundaries:

An extracted date becomes official supply without validation.
The model invents a priority that was never stated or approved.
A recommendation cites no source record, plan run, or rule.
Two actions reserve the same supply from stale data.
A scenario is published as the baseline.
A model or prompt change alters behavior without review.
Users trust fluent language more than the evidence behind it.
No one can reconstruct which person, model, or tool changed the plan.

A useful failure test is:

Failure test: can a recommendation become a receipt date, allocation, reservation, release, or customer promise without a named evidence standard and a named authority? If so, the agent is operating beyond its governance.

High-consequence supply chains

The same pattern applies when an agent investigates a drug shortage, assembles a patient-specific manufacturing exception, compares allocation choices, or traces a delayed grid spare.

A read-only explanation may need ordinary access control. A recommendation that affects a patient, safety function, mission, or public service may require validated calculation, explicit evidence, a named approver, dual control, or a formal exception path.

The controls should attach to the action, not to the agent as a whole.

The same agent may be free to summarize, allowed to investigate with traceability, allowed to create an isolated scenario, and still barred from changing a commitment without approval.

Three common confusions

A human in the loop is not enough. A human is not governing the decision if the agent has already changed planning state before the human sees the recommendation. The human must enter before the consequential state change, not merely appear somewhere in the workflow.

Governed does not mean "AI cannot produce a number." Statistical and learned models may produce forecasts, rankings, parameters, or decisions. The problem is not machine learning. The problem is silent, untraceable authority.

Permission belongs to the action. Summarizing, estimating, calculating, proposing an override, approving a change, and committing that change are different acts. They should not receive the same permission merely because one agent performs all of them.

Vista interpretation

Vista's point of view

Agents should do the analytical legwork: notice, prioritize, investigate, draft, check, and stress-test. The planning platform should calculate consequences with identified methods and preserve the evidence behind them. People should govern policy, exceptions, and high-impact commitments.

That division does not make the human ceremonial. It makes the human faster and better informed.

The most useful question is not "Is a human in the loop?" It is: "What state can this agent change, using what evidence, after what validation, with whose approval, and with what audit and rollback?"

A governed planning agent should shorten investigations, expose hidden dependencies, compare options, and prepare better decisions. It should also preserve what the organization learns: which evidence was trusted, which recommendation was accepted, which assumption failed, and which policy should change.

The interface should make the agent's role visible. A planner should be able to tell whether the agent is summarizing, estimating, calling a validated calculation, proposing an override, or requesting a commitment change. Those are different acts of authority. A governed agent keeps them separate.

Good governance does not make the agent less useful. It makes the agent useful at higher stakes.

Sources Reviewed 14 July 2026

NIST AI RMF 1.0 frames AI risk management around Govern, Map, Measure, and Manage functions and trustworthy-AI characteristics such as validity, reliability, safety, security, accountability, transparency, explainability, privacy, and fairness: NIST AI RMF and AI RMF Core.
NIST's Generative AI Profile identifies risks and actions for generative AI under the AI RMF, supporting the entry's distinction between fluent generated explanation and validated, governed planning authority: NIST AI 600-1 Generative AI Profile.
ISO/IEC 42001 defines an AI management-system standard for establishing policies, objectives, and processes for responsible development, provision, or use of AI systems: ISO/IEC 42001.
OECD AI Principles support trustworthy AI through human-centred values, transparency and explainability, robustness, security and safety, and accountability: OECD AI Principles.
EU AI Act Regulation (EU) 2024/1689 is a legal example of risk-based AI governance; for high-risk AI systems it includes requirements such as risk management, technical documentation, record-keeping, transparency, human oversight, accuracy, robustness, and cybersecurity: European Commission AI Act overview and Regulation (EU) 2024/1689.
The authority ladder and "agents build the case" formulation are Vista editorial and product positions; control design remains implementation-, sector-, and jurisdiction-specific.