AI Workflow Exception Handling: Building a Human Queue

AI workflow exception handling breaks down when unresolved cases disappear into application logs or a shared inbox. The workflow may be running exactly as designed: it refused a risky action, found contradictory evidence, exhausted a retry budget, or produced an output the destination rejected. Yet the business task is still unfinished. Operations staff need the case, its evidence, a clear owner, and a small set of safe resolution actions. A human exception queue supplies that operating layer. It turns ambiguous failures into assigned work, lets reviewers resume from a known checkpoint, and converts repeated exceptions into tests that improve the workflow.

Why retries and alerts do not finish the work

A technical failure has a recognizable shape. An API times out, a process exits, or a database transaction rolls back. Workflow engines already provide controls for these events. AWS Step Functions documents named errors, retries, backoff, and catchers. Those controls can recover from temporary faults or route a terminal error to another state.

Many AI failures are valid execution outcomes rather than crashes. Consider an invoice workflow that extracts fields correctly but finds two possible purchase orders. A support workflow may classify a message but detect that the customer is asking for an account change outside its authority. A document assistant may retrieve two current policies with conflicting effective dates. Retrying the same model call does not resolve missing business context. An alert tells an engineer that something happened, but does not give an accounts payable clerk, support lead, or policy owner a safe way to finish the case.

Treat an exception as business work that the automated path could not complete under its current evidence and authority. That definition includes low confidence only when confidence has been calibrated for the task. It also includes policy denials, missing required data, contradictory sources, destination conflicts, exhausted technical recovery, and uncertainty about whether a side effect already occurred.

Keep the queue focused on cases with a defined reason, owner, review contract, and next state. Sending every unusual result there turns it into a second workflow engine. If the system cannot explain why human action is required, it has emitted an alert, not an operational exception.

Define exception classes before building the screen

Start with a short taxonomy based on what a reviewer can do. Avoid a long list of model-specific error names. Operators care about the resolution path.

Useful top-level classes include:

1. Evidence required. A required document, field, or authoritative source is missing.
2. Evidence conflict. Available records disagree and the workflow cannot apply a deterministic precedence rule.
3. Policy denied. The proposed action exceeds the actor's scope, amount limit, destination, or approval policy.
4. Output rejected. The downstream system rejected a structurally valid request because of current business state.
5. Execution uncertain. The system cannot prove whether an external side effect completed.
6. Recovery exhausted. Bounded retries for a transient technical failure have ended.
7. Quality threshold missed. A measured task-specific quality check failed.

Each class needs severity, business owner, service target, allowed resolutions, and escalation behavior. A policy denial for a high-value refund may require a finance approver within two hours. Missing optional metadata on an internal knowledge item may wait until the next business day. Do not assign severity from model confidence alone. Tie it to customer impact, financial exposure, compliance risk, and time sensitivity.

Keep the initial taxonomy small. Add a class only when existing classes cannot express a materially different owner or resolution. Use a free-text note for nuance, but require a machine-readable reason code for reporting and evaluation.

Store a review packet, not a log pointer

The reviewer should not reconstruct the case across tracing, database, and model consoles. Create an immutable review packet when the workflow enters the exception state. The packet should identify the business task and preserve enough evidence to understand what happened without granting broad production access.

A practical record can look like this:

{
  "exception_id": "exc_20260831_0142",
  "workflow_type": "invoice_match",
  "workflow_version": "17",
  "case_id": "invoice_8421",
  "class": "evidence_conflict",
  "severity": "medium",
  "owner_queue": "accounts_payable",
  "due_at": "2026-09-01T09:00:00Z",
  "checkpoint_id": "cp_0193",
  "input_snapshot_ref": "snapshot_8421",
  "evidence_refs": ["po_781", "po_799"],
  "proposed_action": null,
  "side_effect_state": "none_attempted",
  "allowed_resolutions": ["select_po", "request_information", "close_invalid"],
  "policy_decision_ref": "policy_551",
  "trace_ref": "trace_932",
  "created_at": "2026-08-31T14:20:00Z"
}

References should point to access-controlled snapshots, not mutable live records. Store the workflow and policy versions that made the decision. Include the exact evidence shown to the model when that evidence is permitted in the reviewer's role. Record tool results and validation failures in a compact timeline. Keep hidden chain-of-thought out of the packet. Reviewers need inputs, outputs, policy decisions, tool calls, and observable reasons, not private model reasoning.

The side-effect state deserves explicit values such as none_attempted, confirmed_applied, confirmed_rejected, and unknown. An unknown result must block a blind retry. Reconcile it against the destination using an idempotency key or provider record before offering another write action.

Apply the same data-minimization and retention rules used by the source workflow. A convenient review screen is not permission to copy sensitive data into another unrestricted store. Resolve every evidence reference under the reviewer's current identity and redact fields the role does not need.

Separate reviewer decisions from workflow execution

The queue interface should collect a bounded decision. It should not let a reviewer edit arbitrary workflow state or call tools directly. For each exception class, define a small command schema with validation and authorization.

For the invoice conflict above, the reviewer might select one purchase order, request more information, or close the invoice as invalid. The submitted command includes the exception identifier, chosen resolution, required fields, reviewer identity, and expected exception version. The backend checks that the exception is still open, the command is allowed for its class, the reviewer has the required role, and the evidence has not changed.

Use optimistic concurrency on the exception record. Two reviewers may open the same case. Only one should resolve the current version. The second should see that the case changed and reload it rather than overwrite the first decision.

Resume the workflow through a durable checkpoint, not by replaying the whole task from the beginning. LangGraph interrupts document checkpointed pauses and resumption with external input. The same pattern works with other orchestrators: persist a stable checkpoint before requesting review, validate the human command, and continue from a named state.

A resolution transaction should follow this order:

1. Authenticate the reviewer and load the current exception version.
2. Authorize the requested resolution for the reviewer, class, and business scope.
3. Revalidate mutable evidence or lock the relevant business record.
4. Reserve a single-use resolution identifier.
5. Persist the decision and audit data.
6. Resume, compensate, or close the workflow through the orchestrator.
7. Record the resulting state and release the case from the active queue.

If resume fails after the decision is stored, keep the case in a visible resolution_pending state. An operator can retry the orchestrator handoff with the same identifier. Do not ask the reviewer to decide again.

Route by business ownership and service target

Assign the case to the team that can resolve the business ambiguity. Engineering should own platform faults and broken adapters. Finance should own invoice matches and payment-policy exceptions. Security should own suspicious destinations or access denials that require investigation. Product may own new exception patterns until routing rules mature.

Routing rules should use trusted workflow metadata, not a model-generated team name. A model can suggest a reason code, but deterministic policy selects the queue from workflow type, tenant, region, exception class, amount, and severity. Unknown combinations go to a monitored triage queue with a short service target.

Track both age and blocked time. A reviewer may request information from another team, which changes the next action but does not erase the original age. Escalate cases before the service target expires. Reassign ownership explicitly when responsibility changes. Silent forwarding creates the same ambiguity as a shared inbox.

The reviewer screen should show what must happen next near the top: reason, due time, relevant evidence, proposed or blocked action, side-effect state, and allowed resolutions. Put traces and model details behind expandable sections. Operations staff should not need to interpret orchestration internals to make a business decision.

Turn resolutions into workflow improvements

A closed exception is both completed work and labeled evidence. Preserve the original reason, reviewer command, final outcome, and any corrected fields. Do not treat every human choice as ground truth. Reviewers can make mistakes, policies can change, and some resolutions depend on information that arrived later.

Sample resolved cases for quality review before adding them to an evaluation set. OpenAI's evaluation guidance describes repeatable criteria, test data, and iteration. Convert stable recurring cases into fixtures that test the complete decision boundary. An evidence-conflict fixture should confirm that the workflow routes the case with both records and does not choose one without authority. A policy-denied fixture should confirm that no side effect occurs before an approved resolution.

Use queue data to decide where engineering time pays off. Measure exception rate by workflow version and class, median and high-percentile resolution time, age by owner, reopen rate, resolution failure rate, and repeat frequency for the same root cause. Compare rates against total eligible workflow volume. A falling exception count means little if volume also fell or the workflow started completing risky cases without review.

Set a review threshold for automation changes. Ten reviewers choosing the same resolution may reveal a deterministic rule, but the rule still needs policy approval and tests. Automate only when the required evidence is available at decision time, the resolution is consistent, the downside is bounded, and a negative test proves that disallowed cases remain in review.

Handle the failure modes of the queue itself

The exception system is part of production and can fail. Design for these cases:

• Duplicate exceptions: reserve a key from workflow instance, checkpoint, and reason before creating a case.
• Stale evidence: display snapshot time and require revalidation before a state-changing resolution.
• Unknown side effects: reconcile with the external system before exposing retry.
• Unauthorized review: enforce role and business scope in the resolution API, not only in the interface.
• Queue outage: persist the exception in the workflow store and retry queue delivery without advancing the business task.
• Expired cases: escalate or close under an explicit policy; never let age silently convert denial into approval.
• Workflow upgrade: keep a compatibility handler for checkpoints created by supported older versions.
• Poisoned metrics: exclude test, duplicate, and canceled cases using explicit states rather than dashboard filters based on titles.

NIST's AI Risk Management Framework organizes AI risk work around ongoing mapping, measurement, management, and governance. The queue makes that lifecycle concrete for one workflow by preserving unresolved cases, accountable decisions, and evidence of whether controls worked.

Verify the complete exception path

Test the queue through the real workflow, identity system, evidence store, and destination. Unit tests for a reason-code function will not catch missing snapshots, stale authorizations, or duplicate resume commands.

Build a release suite with at least these cases:

1. Missing required evidence creates one assigned case with the correct due time.
2. Contradictory evidence preserves both snapshots and blocks automatic completion.
3. A reviewer outside the business scope cannot open sensitive evidence or submit a resolution.
4. Two reviewers resolving the same version produce one accepted command and one conflict.
5. An unknown external side effect removes blind retry from the allowed actions.
6. A valid resolution resumes from the saved checkpoint exactly once.
7. A failed resume leaves a visible pending state that can be retried safely.
8. An expired case escalates without changing the underlying business decision.
9. A workflow upgrade can read or deliberately quarantine an older checkpoint.
10. A sampled resolved case becomes an evaluation fixture without exposing restricted data.

Run the suite before every workflow or policy release. In production, alert on queue-delivery failures, unowned cases, service-target breaches, repeated resolution failures, and abrupt changes in exception rate. Review the top recurring reason codes with operations and engineering each week until the workflow stabilizes.

Start with one high-cost exception class from an existing workflow. Define its packet, owner, three or fewer allowed resolutions, and one safe resume path. Exercise the ten tests above before routing live cases into the queue.

References

1. LangGraph interrupts supports the checkpoint, pause, external-input, and resume pattern.
2. AWS Step Functions error handling supports named workflow errors, retry policies, backoff, and catchers.
3. OpenAI working with evals supports repeatable evaluation criteria, test data, and iterative improvement.
4. NIST AI Risk Management Framework supports lifecycle risk mapping, measurement, management, and governance.

---