Most AI workflow demos are choreographed around the normal case. A clean invoice arrives, the model extracts the fields, a record appears, and everyone admires the missing keystrokes. Real operations begin five minutes later, when a supplier changes its layout, a purchase order is split across subsidiaries, and the tax total is technically valid but commercially suspicious.
Teams often treat these exceptions as residue to be eliminated with a better prompt. That is a category error. Exceptions are where business rules collide, where information is incomplete, and where responsibility matters. The quality of an AI system is revealed not by how confidently it handles the easy majority, but by how precisely it recognizes that the next decision belongs to someone else.
Human review is not a single feature
A button labeled send to human is not an operating model. A useful handoff must answer several questions: Which person has the authority and context to decide? What evidence should the system preserve? Which actions have already occurred? What deadline applies? Can work continue on safe branches while one issue waits? What will the AI learn from the resolution?
Without those answers, escalation merely relocates confusion. The operator receives a transcript, reconstructs the state, repeats searches, and worries that the system has already changed something. Automation saves keystrokes upstream while creating forensic work downstream.
The NIST AI Risk Management Framework treats governance, measurement, and management as connected activities. That framing is especially useful for applied AI. Oversight cannot be bolted on after a model has been given broad tools. Roles, permissions, evidence, and intervention points belong in the workflow's original design.
Design an exception contract
Every automated workflow should define an exception contract alongside its success criteria. The contract specifies what the system may do alone, what requires approval, and what must stop immediately. It also defines the package delivered to the reviewer.
A strong exception package contains the original request, relevant source material, actions already taken, the rule or uncertainty that triggered escalation, the model's proposed next step, and the smallest decision needed from the human. It should distinguish facts from model inferences. It should make irreversible actions conspicuous. Most importantly, it should let the reviewer act without replaying the entire run.
That design changes the human's job. The person is no longer a universal fallback asked to check everything. They become an exception specialist handling bounded decisions. This is how automation produces leverage without creating ceremonial oversight, where people approve so many low-information alerts that approval loses meaning.
Confidence scores are not enough
Many systems route work according to a model's self-reported confidence. That can be one signal, but it is a weak foundation for authority. A model may be linguistically confident when the underlying data is stale, permissions are ambiguous, or consequences are asymmetric.
Escalation should also depend on observable conditions: missing fields, contradictory sources, policy boundaries, unusual transaction values, novel document layouts, unavailable tools, repeated retries, and actions that affect external parties. A low-risk classification can proceed under uncertainty; a moderately uncertain bank transfer should not. Risk is the combination of uncertainty, consequence, and reversibility.
This is why the distinction between workflows and open-ended agents in Anthropic's agent engineering guidance matters. Predetermined paths are not less advanced when the business process is well understood. They are often the correct container for model judgment. Autonomy should expand only where flexible planning provides measurable value and the system can recover safely.
The interface should show commitments, not thoughts
There is a temptation to expose long reasoning traces in the name of transparency. Operators rarely need a stream of internal narration. They need a compact account of commitments: what the system believes, which evidence supports that belief, what it changed, what it proposes to change, and what remains uncertain.
Good operational interfaces therefore resemble control rooms more than chat windows. They show queues, deadlines, dependencies, permissions, and state transitions. Conversation may help gather instructions, but the durable object is the work item. If the only record of an exception is buried in chat, the organization has built a conversational prototype rather than an accountable process.
Security reinforces this point. Agents that read untrusted documents or web pages can encounter instructions embedded by an attacker. Human approval is not a sufficient defense if the reviewer cannot see the provenance of the proposed action. Tool permissions, source labeling, and isolated execution matter before the approval screen appears. Guidance on trustworthy agent design increasingly emphasizes meaningful control, including the ability to restrict tools and require approval for consequential actions; Anthropic's discussion of trustworthy agents offers one concrete formulation.
Exceptions are product data
The exception queue is also the richest source of improvement. Each resolved case can reveal a missing rule, a poor tool description, a retrieval gap, or a genuinely irreducible judgment. Teams should classify those resolutions and feed them into evaluation suites. The goal is not to drive escalation to zero. It is to automate recurring, well-understood cases while preserving fast access to human judgment for the rest.
This creates a healthier success metric than automation rate alone. Measure correct straight-through processing, harmful actions avoided, time to resolve exceptions, reviewer effort, and recurrence of known failure classes. A workflow that automates slightly less but hands off cleanly can outperform a seemingly autonomous system that leaves operators cleaning up invisible damage.
The final ten percent of a workflow is not an embarrassing gap awaiting a smarter model. It is where an organization encodes authority, accountability, and care. Build that part first, and the automation around it becomes easier to trust.
Advertisement
