An AI agent can interpret information, identify a likely next step, and prepare work without having permission to carry that work into the business.
That distinction matters. A recommendation is not authorization. A drafted customer response is not a sent response. A proposed account update is not an approved change. Even a well-supported conclusion does not grant the authority to act on it.
At the same time, requiring a person to approve every AI-assisted step creates a different problem. Routine work becomes trapped in a review queue, and the operator spends time approving actions whose consequences are limited and easy to reverse. The control exists, but it is attached to everything rather than focused where it matters.
Human approval for AI agents should therefore be assigned according to the consequence of an action—not simply because AI was involved. The practical threshold depends on six questions: Can the action be reversed? Does it affect someone outside the business? Is it an exception to normal rules? How certain is the basis for acting? Does the approver have the right authority? When does the approval expire?
Those questions turn approval from a vague safety instruction into an operating decision.
Approval Begins Where Recommendation Ends
Interpretation and recommendation belong on one side of the boundary. Providing an AI with the right business context defines the scope of interpretation without expanding the scope of action.
Permission to act belongs on the other.
An AI might examine allowed business information and conclude that a customer response is needed. It might draft that response, identify missing details, or recommend that the matter be escalated. None of those steps necessarily authorizes it to contact the customer.
The same separation applies internally. An AI might propose changing a record, assigning a task, or updating a status. The proposal can be useful while still requiring a person to decide whether the change should occur.
This boundary prevents a common category mistake: treating reasoning as authority. The quality of a recommendation may affect whether a person accepts it, but confidence in the recommendation does not create permission. Authority has to come from the business.
Operators should make that boundary visible in the workflow. Ask:
- Is the AI interpreting information?
- Is it preparing a possible action?
- Is it recommending that an action occur?
- Or is it being permitted to change something, communicate something, or commit the business?
Approval becomes relevant when the workflow crosses into action with meaningful consequences. Before that point, review may still be useful, but it is not the same as granting authority.
Use Consequence, Not a Blanket Rule, to Set the Approval Threshold
A blanket rule sounds simple: require human approval before the AI does anything. In practice, that rule fails to distinguish between preparing a reversible internal update and making an external commitment.
The opposite rule—allowing action whenever the AI is sufficiently confident—has its own flaw. Confidence concerns the basis for a decision. It does not determine whether the AI is entitled to make that decision.
A consequence-based threshold separates these issues. It asks what could change if the action proceeds and what would be required to recover if it is wrong.
Consider two proposed actions:
1. Prepare a draft internal note that a person can discard.
2. Send a final answer to a customer about an exception.
Both may begin with the same information. Both may use similar reasoning. But their operational consequences differ.
The draft is contained, visible, and easily replaced. The customer answer crosses the business boundary, could be interpreted as an official position, and involves an exception. The second action deserves a higher approval threshold even if the underlying analysis appears equally strong.
This is the point of a consequence map. It does not label AI as universally safe or unsafe. It assigns control according to the effect of a specific action under specific conditions.
The Six Questions to Ask Before an AI Acts
A useful approval decision can be made with six questions. A clear view of operational AI readiness sets the context for those six questions.
They should be answered for the action itself, not for the AI system in general.
1. Is the action reversible?
Reversibility is not merely whether a button exists to undo a change. The operator should consider whether reversal would restore the prior condition without creating additional confusion or work.
An unsaved internal draft is highly reversible. A status change may also be reversible if it remains internal and its history is clear. An external message is harder to reverse because a correction cannot make the recipient unread the original. A commitment made on behalf of the business may be harder still.
As reversibility decreases, the case for action-specific approval becomes stronger.
2. Does it affect an external party?
Actions that remain inside a controlled workspace generally have a different consequence profile from actions that reach customers, vendors, applicants, or other outside parties.
External impact does not automatically mean that every action requires individual review. A business may decide that a narrow class of low-consequence communications can be pre-approved. But that permission should be explicit and bounded. “Communicate externally” is too broad to serve as a useful approval rule.
The operator needs to name the allowed action, the conditions under which it is allowed, and the point at which the action must return to a person.
3. Is this an exception?
A normal process may support a stable approval boundary. An exception changes the basis on which that boundary was set.
Suppose a business has defined a standard response for a standard condition. The action might qualify for pre-approval when all required conditions are present. If the request falls outside those conditions, the existing permission should not stretch to cover it.
Exceptions should trigger review or escalation. Otherwise, a narrow authorization quietly becomes a broad one.
4. How certain is the basis for acting?
Uncertainty may come from missing information, conflicting information, unclear instructions, or an ambiguous operating condition. The relevant question is not whether the AI can produce an answer anyway. It is whether the business has enough reliable basis to permit the proposed action.
A low-consequence internal proposal can tolerate more uncertainty because a person can inspect and revise it. An irreversible or outward-facing action should require a stronger basis.
Uncertainty should also interact with the other triggers. Moderate uncertainty may be acceptable for a draft but unacceptable for an exception communicated externally.
5. Does the approver have authority?
A person in the loop is not necessarily an authorized approver.
The person reviewing the action must have the business authority to permit it. Someone may understand the situation and still lack authority to approve a commitment, exception, record change, or external response.
Naming “a human” as the approver leaves the central question unanswered. The workflow should identify the role or person permitted to approve that type of action and provide an escalation route when the first reviewer cannot decide.
6. How long should approval remain valid?
Approval is given under a set of conditions. Those conditions can change.
A proposed response approved this morning may no longer be appropriate after a customer supplies new information. Permission to perform a bounded set of actions this week should not silently become permanent authority. Approval tied to one action should not be reused for a different action because the wording looks similar.
Every meaningful approval needs an expiry condition. That could be a time, a completed action, a change in the underlying facts, or departure from the approved scope.
Map Actions Into Approval Levels
The six questions can be used to place candidate actions into four practical levels.
Proposal only: The AI may interpret, draft, organize, or recommend, but it cannot perform the consequential action. This level fits situations in which the operating basis is still being established or the proposed action carries consequences the business has not authorized.
Pre-approved, low-consequence action: The AI may perform a specifically defined action when stated conditions are met. The action should be bounded, sufficiently reversible, and outside known exception conditions. Pre-approval is permission for a class of actions, not unlimited discretion.
Action-specific approval: A person with the required authority reviews the exact proposal and grants permission for that action. This level fits actions with external effects, limited reversibility, material uncertainty, or consequences that deserve direct judgment.
Escalation: The AI does not act, and the immediate reviewer does not expand the permission. The matter moves to someone with the appropriate authority. Exceptions, conflicting information, expired approval, or a proposed action outside the defined scope can all create an escalation point.
These levels are illustrative operating categories, not claims about what any particular product currently performs. Their value lies in forcing an explicit decision. If an action cannot be placed confidently, it should remain proposal-only until its boundaries are defined.
Make Approval Meaningful: Name the Approver, the Scope, and the Expiry
“Human approval required” is incomplete unless the business records three things.
First, who can approve? The answer should point to a person or role with authority over that decision.
Second, what is being approved? Permission might apply to one proposed action or to a tightly bounded class of actions. It should identify relevant conditions, limits, and exception triggers.
Third, when does permission end? Approval might expire after one use, at a stated time, when new information arrives, or when any approved condition is no longer true.
Clear rules for what the AI remembers should determine whether expired approvals, exceptions, and context are retained, updated, or removed.
The workflow should also preserve the state of the work. A useful sequence distinguishes:
- Proposed: An action has been prepared.
- Authorized: A valid approver has permitted it within a defined scope.
- Attempted: The workflow tried to carry it out.
- Completed: The action appears to have occurred.
- Verified: The result has been checked against the intended outcome.
These states are not interchangeable. Authorization does not prove execution. An attempt does not prove completion. Completion does not necessarily prove that the intended result occurred.
If a workflow collapses all five into “done,” the operator loses the ability to see where responsibility passed, where execution failed, or whether the result was ever confirmed.
A Hypothetical Small-Business Approval Map
Consider a hypothetical service business using AI-assisted workflows. The AI can prepare several proposed actions from allowed business information. The example does not assume that TMMN or any other specific product executes these actions.
The first proposal is an internal update summarizing an open request. It does not alter the source record, contact anyone outside the business, or create a commitment. A person can revise or discard it. The business might classify this as proposal-only during initial use, then consider a narrow pre-approval if the update remains internal and reversible.
The second proposal is a customer response prepared for review. Drafting remains separate from sending. Because transmission affects an external party and a mistaken message cannot be fully withdrawn, the business requires action-specific approval before it is sent. The approver must be authorized to communicate that answer.
The third proposal concerns a request outside the normal policy. Even if the AI finds a similar previous situation, similarity does not grant permission to make an exception. The action is escalated to the person authorized to decide exceptions.
Now add uncertainty. Suppose the customer provides new information after the response is approved but before it is sent. The original approval expires because the factual basis has changed. The response returns to proposed status and must be reviewed again.
The same AI can contribute to all three situations, but its involvement does not determine the approval level. Reversibility, external impact, exception status, uncertainty, approver authority, and expiry do.
Start With the Actions That Could Create the Most Regret
Do not begin by writing one approval policy for “AI actions.” Begin with an inventory of candidate actions.
Name each action precisely: draft an internal update, change a record, prepare an external response, send a response, apply a standard rule, or decide an exception. Broad labels hide consequence differences.
Then mark the triggers that should stop or raise the action: difficult reversal, external impact, exception conditions, weak or conflicting information, missing approver authority, and expired permission. Assign an authorized approver and an escalation destination. Record whether approval applies once, for a limited period, or only while specific facts remain true.
The first test should focus on the actions that would create the most regret if they were wrong. Pick one and trace it from proposal through authorization, attempt, completion, and verification. At every handoff, ask one concrete question: What evidence shows that this action had valid permission at the moment it crossed the boundary?
Use clear conversation ownership and tracking to keep permission evidence attached to each handoff from assignment through closure.
If that answer is unclear, the action is not ready for broader authority. A 14-day free trial can help you evaluate how these ideas fit your workflow.
Keep it at proposal-only until the approver, scope, consequence triggers, and expiry are explicit.
.svg){kind=icon}
