An AI system can fail while producing a fluent, plausible answer. It can also fail after correctly identifying that it needs help, if the product gives that uncertainty nowhere useful to go. A message saying “Please contact support” is not a human handoff when support cannot see the task, the evidence or the work already completed.

The design problem is therefore larger than asking for human approval. A product needs to decide when automated work should stop, what can safely continue, who should receive the exception and how the user can understand the state of the task while waiting.

This article focuses on that operational boundary. My earlier work covers trust and interaction patterns for agentic products. Here, the question is how to preserve responsibility and task continuity when the automated path cannot proceed. The framework and examples are illustrative, not claims about a deployed client system or a guarantee of safety.

The running example is a hypothetical AI-assisted document review tool. It extracts information, compares it with a policy and prepares a recommendation. It does not make legal or clinical determinations. Its value depends as much on handling ambiguous cases as on processing straightforward ones.

NASA photograph S69-39601: flight controllers during Apollo 11’s lunar module descent, July 1969. Historical analogy for observable state, specialist roles and accountable intervention. Credit: NASA / NASA History Office and JSC Media Services Center.

Stopping is a designed outcome

Teams often define success as automatic completion and treat every escalation as a defect. That creates pressure to continue even when the product lacks the authority, evidence or technical capability required for the next action.

A better outcome model distinguishes completed, safely paused, handed to an accountable person and unable to continue with a clear explanation. These outcomes are not interchangeable, but all can represent appropriate behavior in a particular situation. The interface should communicate which one occurred.

For the document tool, missing evidence may justify pausing the recommendation. A revoked permission may require stopping access immediately. A temporary dependency failure may allow a safe retry. An apparent policy conflict may require domain review. One generic fallback would obscure these materially different conditions.

Start by identifying the consequence of continuing incorrectly. Could the action change a record, send information, commit money or influence another person’s decision? The more consequential the action, the more explicitly the product needs to define the boundary before automation is enabled.

Do not ask confidence to do the work of policy

A confidence indicator can be useful only when the team understands what it represents and how it behaves in the relevant context. A model’s self-reported certainty should not automatically determine whether an action is allowed. Fluent uncertainty and fluent confidence can both be misleading.

Separate evidence sufficiency, authorization and execution readiness. The system may have enough evidence to draft a recommendation but lack permission to submit it. It may be authorized to act but unable to verify the source. It may satisfy both conditions while an external service is unavailable.

For a consequential workflow, write explicit stop conditions in terms of observable requirements. Examples include a required source being absent, conflicting authoritative records, an expired approval or a change outside the permitted action scope. Domain experts and engineers should determine which conditions can be enforced deterministically and which need review.

If a probabilistic signal is used, validate it against the intended task and document its limitations. The threshold is a product and risk decision informed by evidence, not a number a designer should invent to make a flow diagram look complete. The UI can explain uncertainty without pretending that it measures safety directly.

A published Fin configuration example makes the inactivity handoff explicit. The forum example illustrates a setting, not a reliability guarantee. Credit: Intercom Community / Fin.

Build an exception taxonomy before a fallback screen

I would group exceptions by what must happen next: missing information, conflicting information, insufficient authority, technical failure and out-of-scope work. The categories are a starting point and should be adjusted to the domain.

Missing information may be resolved by the current user. Conflicting information may need an authorized reviewer. Insufficient authority may require a different role or renewed approval. Technical failure may require a retry or operations intervention. Out-of-scope work may need a different service entirely.

The taxonomy should drive routing and content. It should not exist only in an internal spreadsheet while every user sees “Something went wrong.” Explain the known condition, its consequence for the task and the next available action. Avoid revealing restricted information in the explanation.

Also distinguish expected exceptions from defects. A tool declining to summarize an unsupported file type may be following its declared scope. A tool losing a valid file during processing is a defect. Both need recovery, but the ownership, measurement and corrective work differ.

Decide what stops and what remains available

Stopping one action does not always mean freezing the entire experience. The document tool might pause a final recommendation while preserving extracted fields, source links and the user’s notes. This can help a human reviewer continue without repeating completed work.

But preserved work needs a visible status. An extracted field that has not been verified should not appear identical to an approved value. A draft recommendation should not enter the authoritative record while waiting for review. Define which artifacts remain advisory and which state changes are prohibited.

Cancellation needs the same precision. Can the user stop queued work? Has any external action already occurred? Can completed effects be reversed? The interface must not promise a clean undo when the underlying system only supports a compensating action or manual review.

Write these boundaries as acceptance criteria. “When a required source conflicts with the current record, the tool does not submit an update; it preserves the draft and routes the conflict for review.” This is more actionable than “Keep a human in the loop,” which leaves both the loop and the human undefined.

A generic error hides the reason a task stopped. This conceptual route names a different next actor for each condition. Credit: Original editorial visual prepared for Andrea Mabellini.

The handoff packet is part of the product

An escalation is useful only if the recipient can understand and act on it. I would define a minimum packet containing the user’s objective, relevant task state, source references, completed actions, unresolved condition, permitted next actions and task identifier.

Include the evidence needed to evaluate the exception, within access and retention policy. Do not forward every document or internal trace indiscriminately. A concise packet should explain the reason for escalation and link to the authorized source of detail.

Avoid treating hidden model reasoning as an audit record. What a reviewer needs is a grounded account of inputs, outputs, system events and the condition that blocked progress. A confident narrative about how the model thought may be less useful than a simple statement that two source dates disagree.

For the hypothetical document case, the packet could state that extraction completed, the source references show different effective dates, no update was submitted and an authorized policy reviewer must determine which date applies. The recipient should be able to verify each statement without trusting the AI’s prose alone.

A handoff reaches a real person with a task to complete. External customer-support photograph, not a screenshot of the hypothetical AI service. Credit: Vagaro / Unsplash.

Name the recipient and the responsibility

“Human review” is not an operating model. Who receives the exception? Do they have the relevant authority? Are they available? Can they return the work to the user, request more evidence or stop the process permanently?

Define routing by exception type and domain, not merely by the team that built the AI feature. A technical outage may belong to operations. A policy conflict may belong to a domain owner. A missing user-provided document may return to the requester. A support team cannot resolve every category simply because it is the most visible human service.

Show users an honest account of the handoff. If a case is in a queue, say that. Do not say a reviewer is working on it before assignment or activity is confirmed. Any time expectation should come from the actual service commitment rather than invented reassurance.

Plan for no recipient accepting the task. Ownership gaps, unavailable specialists and overloaded queues are normal operational possibilities. The product needs a visible unresolved state, an escalation route and a responsible service owner. Otherwise stopping automation merely transfers uncertainty into an invisible queue.

Design the review interface for independent judgment

A reviewer needs enough context to challenge the automated recommendation. Present relevant sources, missing information, current state and the consequences of possible actions. Avoid making acceptance the visually effortless default while rejection requires unexplained extra work.

The reviewer should be able to edit, reject, request information or choose an alternative where policy permits. Capture the decision at the level needed for accountability. A mandatory free-text reason for every minor correction may create meaningless entries; consequential overrides may warrant a more structured record.

Separate recommendation from authority. If the tool suggests one interpretation, make clear that the reviewer owns the final decision within their role. A prominent recommendation can anchor judgment, so consider whether the review task benefits from seeing source evidence before the proposed answer.

The Microsoft human-AI interaction guidelines provide a useful reference for communicating capability and supporting correction. The operational packet and routing model here are additional design recommendations, intended to connect those interaction principles to a complete service.

Resuming requires a new state check

After review, do not assume the original conditions still apply. Sources may have changed, permissions may have expired and another person may have completed the task. Resumption should check the relevant version and authorization before executing the next action.

For the document tool, a reviewer resolving the conflicting date should not trigger an update against an older record without verification. If a new version exists, the product may need another comparison or explicit confirmation. The right behavior depends on the domain, but the stale-state possibility must be designed.

Make resumption understandable to the user. Explain what was resolved, what remains and whether they need to act. If the task cannot resume, preserve the permitted work and give a clear reason. An escalation should not return the user to the beginning without accounting for the effort already spent.

Zendesk’s published routing example names both a condition and the receiving group. Credit: Zendesk.

Test the complete exception journey

Testing only successful automation leaves the service boundary unexamined. Build scenarios where evidence is absent, sources disagree, permissions change, a dependency times out and no reviewer is available. Use safe test environments and representative cases approved for the exercise.

Follow the task across roles. Does the user understand that automation stopped? Does the reviewer receive the right information? Can the reviewer make an authorized decision? Does the product resume against the correct state? Can operations identify an abandoned case?

Test the review interface with people who have the actual responsibility, not only designers simulating a reviewer. Domain ambiguity often appears in what evidence is needed, not in how many clicks the interface requires. Include accessibility checks across both the requesting and reviewing experiences.

For consequential submissions, the W3C error-prevention guidance is relevant to review, correction and reversal. It is not a complete AI governance framework. The product still needs domain-specific controls, technical verification and operational ownership.

Measure the quality of stopping

An escalation rate alone is ambiguous. A lower rate may mean better evidence, weaker safeguards or a changed case mix. A higher rate may indicate appropriate caution, a poor extraction feature or missing information upstream. Investigate the reason before optimizing the number.

Track exception categories, task disposition, time awaiting assignment, missing packet information and whether a task resumed successfully. Distinguish unresolved cases from completed human review. Where appropriate, review samples for cases that should have escalated but did not.

Do not treat human approval as proof that the system was correct. Reviewers can make mistakes or accept recommendations without sufficient scrutiny. Look at whether the process supports informed judgment and whether independent checks reveal important misses.

Use the findings to improve the whole workflow. If most exceptions come from a missing source field, changing intake may be more valuable than adjusting the model. If reviewers repeatedly request the same context, improve the packet. If no role can resolve a common conflict, the product has an ownership problem.

A practical boundary review before release

Before the review, establish queue capacity as an operating constraint. If the automated feature can create exceptions faster than the review team can resolve them, an apparently successful launch may accumulate unfinished work. Agree which cases take priority, who can redistribute them and when the service should limit new automated requests. The interface should reflect the actual service state rather than letting a backlog remain invisible.

Define retry ownership too. An automatic retry and a reviewer pressing a retry button must not create competing executions. Engineering should provide an operation identifier and a way to verify the result of an uncertain request. The handoff packet should distinguish a confirmed failure from an unknown outcome. In the latter case, checking whether the action already occurred may be the necessary next step; retrying immediately may be unsafe.

Finally, establish an abandonment rule. A requester may leave the organization or stop responding while a case waits for evidence. Determine who can close the case, which artifacts remain available and how the closure is communicated. Closure should not imply that the original work completed. A durable “Closed without action” state can be more accurate than allowing an exception to disappear from the queue.

These details deliberately extend the general handoff principle in my article on trust in agentic products. They make the receiving service, not just the requesting interface, part of the design scope.

Bring design, engineering, product, operations and the relevant domain owner together around one consequential task. Identify the actions automation may take, the prerequisites for each and the conditions that require stopping. Map the recipient and the resumption rule for each exception.

Then walk through a case that cannot be completed automatically. Follow the evidence and task state until a named person can make the next decision. If the team reaches “someone will handle this,” the review has found an unfinished part of the product.

Document the contract beside the interaction specification and technical implementation. The same state meanings must be visible to the interface, routing service and operational dashboards. An attractive fallback screen cannot compensate for contradictory states across those systems.

A receiving person needs usable context. This hypothetical packet lists observable evidence and state. Credit: Original editorial visual prepared for Andrea Mabellini.

Dependable automation includes a dependable exit

AI features become more useful when they can complete appropriate work and recognize the limits of that work. But recognizing a limit is only the beginning. The product has to preserve context, assign responsibility and support a safe continuation or a clear end.

That boundary complements the design-system and code context discussed in my design-to-code guide. Shared components can render states consistently; teams still need to define the operational meaning of those states.

The question I would ask before release is not merely whether a human can approve the output. It is whether every important exception has somewhere accountable to go, and whether the person receiving it has what they need to decide. When that answer is clear, stopping becomes part of a dependable experience rather than the moment the product disappears.