In 30 seconds

Decide in advance what the AI does when it is unsure, meets a case it cannot handle, or an action fails. The safe default is almost always to stop and hand the case to a person, not to guess or plough ahead.

Why this comes up

Most of the time a workflow runs on the happy path. The design work that matters is what happens on the unhappy path: uncertainty, exceptions and failures. If you do not design that, the AI improvises, and improvising on a hard case is where the worst mistakes happen.

Design for three different situations

When the AI is uncertain

Sometimes the AI can produce an answer but should not be trusted to. Design an explicit "I am not sure" path: below a confidence level, or when the input is unusual, the case goes to a person instead of proceeding. This is the confidence threshold idea. The AI declining to answer is a feature, not a failure.

When the case is an exception

Some cases are outside the AI's job entirely: an unusual request, a conflict, a missing prerequisite. These should route to a defined place, not be forced through. A visible exception queue with an owner is the usual answer.

When an action fails

Actions fail: a system is down, a write is rejected, a step half-completes. Design for it. The workflow should detect the failure, avoid leaving things half-done or duplicated, and hand off to a human fallback that works even when the target system does not.

Make "stop and ask" the safe default

Across all three situations, the reliable default is: when in doubt, stop and escalate to a person, safely. An AI that stops on uncertainty is far safer than one that pushes on. Design the workflow so stopping is easy, clear and does not lose the case.

Do not let failures hide

A failure that disappears silently is worse than one that stops the workflow loudly. Make sure failed and half-completed actions are detectable and logged, so a person knows to step in. See how to make a process auditable.

A small example

An agent created tickets from emails. Designed for failure, it did three things: uncertain classifications went to a review queue, emails it could not parse went to a person, and if the ticket system was down it saved the request and alerted a human rather than dropping it. The happy path was simple; the safety was all in the unhappy path.

What this does not solve

Good failure design contains the damage when things go wrong; it does not prevent every failure or replace monitoring after launch. You still have to review real failures and improve. It makes failures safe and visible, which is what lets you learn from them.

Good enough to move on when

  • There is an explicit path for AI uncertainty.
  • Exceptions route to a defined owner or queue.
  • Action failures are detected, not hidden.
  • A human fallback works even when a target system is unavailable.