Four questions for architects designing consequential AI actions.
By Ric Muro
An AI procurement agent prepares a $42,000 supplier payment. The invoice matches the purchase order. The supplier is approved, the payment account is verified, and the amount falls within delegated authority. The proposed action passes the organization’s policy controls and receives ALLOW.
Three minutes later, the supplier is placed under fraud review.
Two minutes after that, the queued payment reaches execution.
Nothing was necessarily wrong with the original decision. The conditions supporting it were valid when the decision was made.
The architectural question is different:
What must still be true for that ALLOW to remain usable?
Enterprise architectures are increasingly defining what agents may do and placing policy checks before consequential actions. A&G’s recent discussion of agent decision rights, for example, describes an external policy gate through which consequential actions pass before reaching a tool or system.
But even a correctly designed runtime gate leaves another question:
What conditions must it establish before relying on an earlier ALLOW?
The Decision Was Correct—Then Something Changed
Enterprise state changes constantly.
A supplier changes its mailing address. An exchange rate moves. A server is renamed. An employee changes departments. A customer record receives an additional note.
It would make little sense to reconsider every previous decision whenever anything changes.
But some changes clearly matter.
A supplier enters fraud review. A production environment develops a critical fault before an approved deployment. A position is placed under a hiring freeze after an offer has been prepared but before it is sent.
The difficult question is therefore not:
Did something change?
It is:
Did something change that the earlier decision depended on?
Consider the supplier again. The company might change its headquarters, replace its CEO, redesign its website, and adopt a new brand while its legal entity, contract, verified payment account, invoice, and compliance status remain unchanged.
Those are substantial changes to the supplier. They may nevertheless be irrelevant to the approved payment.
By contrast, one small data change—
FraudHold: False → True
—could be enough to require reconsideration.
The significance of a change is not how much changed, but whether the earlier decision depended on it.
This Is Not an AI-Only Problem
Safety-critical industries have long treated permission to proceed as conditional rather than sufficient by itself.
The UK’s Health and Safety Executive describes permit-to-work systems as formal controls for specified work and emphasizes that issuing a permit does not, by itself, make a job safe. Its guidance connects the permit to hazards, precautions, responsibilities, and the work being performed.
Some HSE guidance goes further: where relevant conditions change, a permit may need to be withdrawn, the situation reviewed, and a new or amended permit issued.
The point is not that AI systems should copy industrial permit systems.
It is that permission to proceed does not necessarily mean permission to proceed regardless of subsequent conditions.
Agentic AI brings a related architectural question into software operating at machine speed and enterprise scale.
Figure 1. What Must Still Be True?
Four Questions Before Execution
Authorization determines whether an action may proceed under a set of conditions. Architecture still has to determine which of those conditions remain relevant until the action takes effect.
Four questions can make that problem explicit.
- Basis — What had to be true for this action to receive ALLOW?
A consequential decision rarely depends on one fact.
For a supplier payment, relevant conditions might include an active contract, matched invoice, delegated authority, verified payment destination, transaction limits, and compliance status.
For consequential actions, architecture should be able to identify the conditions that materially supported the decision.
This matters even when policy enforcement happens immediately before execution.
A runtime policy check is only as useful as the conditions it knows it needs to check.
- Continuity — Which conditions must still be true when execution occurs?
Not every supporting condition has the same lifetime.
Some facts may only need to be valid when the decision is made. Others may be required to remain true until the action takes effect.
A purchase order, for example, may have been validly approved earlier. Fraud status, a transaction ceiling, or a production-health condition may be required by organizational policy to remain valid until execution.
Those continuity requirements should be deliberate architectural and policy choices rather than assumptions made after something goes wrong.
- Change Relevance — Which changes require reconsideration?
Once decision dependencies are understood, architecture can distinguish ordinary state change from decision-relevant change.
For a production deployment, renaming a server may have no effect on the approved action. A critical database replication failure may matter considerably if healthy replication was one of the conditions supporting deployment.
For an HR agent, a candidate changing a telephone number may be irrelevant. A hiring freeze affecting the approved position may not be.
The question is not whether a change appears important in isolation.
It is whether it changes something the organization relied upon when permitting this specific action.
- Disposition — What happens when a required condition is false—or unknown?
The harder case may not be a known change.
It may be uncertainty.
Suppose the supplier payment was approved while fraud status was clear, but the authoritative fraud-status service cannot be reached when the transaction is about to execute.
The system cannot establish whether a condition required for execution still holds.
That outcome should not be left to the agent to improvise.
Depending on the action, consequence, and organizational policy, the defined response might be to proceed, re-evaluate, hold, refuse, or escalate to a human.
The important point is that the disposition is designed before the uncertainty appears.
What Must Still Be True?
Observability helps organizations reconstruct what agents, integrations, policies, and people did across an end-to-end process. Recent A&G coverage illustrates how traces, decision records, policy results, tool invocations, and workflow history can help explain what happened.
Architects also need to decide what matters before the effect occurs.
As AI shortens the distance between decision and action, a correct ALLOW may not be the end of the governance question.
For every consequential autonomous action, architects should be able to answer:
What made this action allowable?
What must remain true?
What changes require reconsideration?
And what happens when the current condition can no longer be established?
The hardest part may not be deciding whether an agent may act.
It may be deciding what must still be true when it does.
References / Further Reading
Lavanya Subbarayalu. “Designing Decision Rights for Agentic AI.” Architecture & Governance, August 24, 2026.
National Institute of Standards and Technology, National Cybersecurity Center of Excellence. Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization, Initial Public Draft, February 5, 2026. NIST’s project specifically identifies agent identification, authorization, auditing, and non-repudiation as areas requiring attention as software agents gain access to enterprise data, tools, and applications.
Sadia Tahseen. “Observability in the Oracle Agentic Enterprise.” Architecture & Governance, August 21, 2026.
UK Health and Safety Executive. Permit to Work Systems and Guidance on Permit-to-Work Systems (HSG250).
Ric Muro is an enterprise technology and governance practitioner with experience spanning enterprise systems, technology operations, architecture, compliance, and large-scale IT environments. His work focuses on practical governance and architecture questions that emerge as autonomous systems move from recommendation toward consequential enterprise action.