When should an AI system’s authority expire?

The gap between approval and action

An approval records a decision made under particular conditions. A workflow may execute that decision later, after some of those conditions have changed. For an AI system authorized to act, that gap deserves deliberate design.

Consider an illustrative service-scheduling assistant. It may offer a customer an appointment only when a qualified technician, the required equipment, and an eligible service window are available. A manager approves the proposed booking. Before the assistant confirms it, the technician is reassigned. The manager’s approval is real, but the appointment no longer meets the conditions behind it.

My starting point is to make authority conditional. Specify what the system can do, why that permission holds, and what would make it stop holding. This is an operating-design proposal, not a claim that every organization needs the same approval mechanism.

Separate four different rights

A role labelled “AI assistant” tells us little about its authority. I would separate the right to propose an option, approve it, execute it, and revoke permission. Those rights may belong to different people or systems.

For the scheduling example, the assistant might explore alternatives without approval. A service manager could authorize an offer within a defined scope. A booking service could commit the appointment only after checking availability again. An operations owner could suspend further bookings if the underlying information becomes unreliable.

The distinction matters when a task crosses boundaries. Permission to prepare an appointment should not silently become permission to promise one. Permission for one customer should not extend to every similar customer. A later step needs the authority appropriate to its consequence.

Write permission as a small operating specification

For one consequential action, write down the following before deciding how much autonomy to allow. The goal is a boundary that an operator can understand and the workflow can enforce.

• Action and scope: exactly what may happen, for which case, resources, and people.
• Decision owner: who grants the permission and who can withdraw it.
• Required conditions: the business facts that must remain true.
• Invalidation events: the changes that require the system to stop or seek a new decision.
• Validity window: when the permission expires even if no change has been detected.
• Commitment check: which conditions must be checked immediately before execution.
• Blocked path: where the work goes when permission is no longer valid.

Expiry needs more than a timer

Time limits are useful when information becomes less dependable with age. They do not describe every meaningful change. A reassignment can invalidate a booking within seconds; an unchanged low-consequence task may remain valid much longer.

Tie expiry to events the organization can actually observe. If authority depends on equipment availability, identify the source that reports it and what happens when that source is unavailable. An uncheckable condition creates the appearance of a boundary without a dependable way to apply it.

There is also a trade-off. Rechecking everything continuously adds coordination and delay. Checking too little permits decisions based on conditions that no longer hold. Start with facts that could materially change the commitment, then choose the timing and fallback appropriate to the consequence. For high-consequence actions, “we received no change notification” may be insufficient evidence that the original conditions still hold.

If conditions can change during execution, a last-minute check may still be insufficient. Decide whether the workflow can reserve the relevant resource, make the commitment conditional on an expected state, or defer the action. The control needs to protect the actual commitment, not merely document an earlier check.

Design the interruption as carefully as the action

When permission expires, preserve the useful work. Explain what changed, which action is now blocked, and what remains possible. The scheduling assistant could retain the customer’s preferences and offer newly eligible slots rather than restarting the entire conversation.

Renewal should be a fresh decision about the changed conditions. Avoid an approval screen that merely asks someone to endorse the same stale recommendation. Give the decision owner the difference that matters and a clear choice about scope.

Finally, test the awkward sequence: approval succeeds, conditions change, execution is attempted, and a person must recover the task. Confirm that the system can recognize the change and that the next owner can resolve it. Record what was approved separately from what was actually completed.

A leadership review question

Ask the team to identify one event that would invalidate a consequential action, then demonstrate what happens if that event occurs after approval but before execution. If the answer relies on someone noticing by chance, the authority design needs more work.

The ambition is to make useful autonomy more precise: enough freedom to progress the work, with permission that remains connected to the circumstances in which it was granted.