Accuracy Improves; Exceptions Scale Anyway

A workflow at 90% accuracy handling 1,000 requests produces 100 exceptions. That same workflow at 95% accuracy handling 10,000 requests produces 500 exceptions. Accuracy went up by 5 percentage points. Exception volume went up by 5x.

This is the bottleneck most teams do not plan for. Organizations track adoption metrics (tokens consumed, prompts per day, workers using the tool) instead of operational health metrics (exceptions per day, resolution time per case, operational cost). The measurement framework hides the problem. Production doesn’t stall because the AI stops working. It stalls because the operation was never sized for the exceptions that will actually arrive.

The Measurement Problem

Most organizations know how many people are using AI and how often. Few know how many exceptions they are producing per day or what it takes to resolve them.

OpCo Intelligence’s 2026 State of AI Transformation survey found that 77% of senior operators reported moving beyond experimentation with AI. Nearly 70% had no metrics to measure its impact. The remainder defaulted largely to adoption proxies: who is using the tool and how often. These metrics confirm that people are active. They reveal nothing about whether the operation is healthy. The activity is widespread. The accountability infrastructure is not.

This gap reflects a deeper assumption: that if the AI is accurate enough, the operation takes care of itself. That assumption breaks at scale. A pilot at narrow scope with curated inputs and extra attention can absorb exceptions through effort. A production workflow with variable inputs, live handoffs, and volume cannot. Once the workflow moves to production, the exceptions do not disappear. They queue up, get triaged manually, route through email and Slack, and the visibility into how the operation actually runs becomes opaque. The team discovers the bottleneck only when resolution time stretches and costs climb.

Continuous monitoring becomes non-negotiable the moment a workflow goes live. Not as a future-state improvement, but as an operational default. Kieran Snyder, former CEO of Textio and now VP of AI Transformation at Microsoft, frames the correction simply: “The right metrics to assess the impact of AI are the same metrics that boards cared about in the first place.” Speed, delivery, execution. Can the organization ship faster? Respond to customers more quickly? Those are the outcomes boards have always measured. The gap is that most organizations have not connected those outcomes to what is happening inside the operation: how many exceptions are queuing, how long resolution takes, and what each case costs.

Two Lenses for Exception Routing

Exceptions are not a single category. Each type requires different handling and different expertise. Treating them as one undifferentiated queue is how operations lose control.

Exceptions originate from five sources: outputs below confidence thresholds, missing or conflicting context, formal approval gates, cases that fall outside defined parameters, and process variance (the output is technically correct given the inputs, but the business outcome is wrong because the process design did not account for this scenario). Understanding where exceptions originate is the first lens.

Understanding how to resolve them is the second. Resolution depends on what went wrong: accuracy (the AI output was factually wrong), judgment (the situation requires human context, institutional knowledge, or discretion the AI does not have), data (the input was missing, malformed, or untrustworthy), process (the workflow encountered a scenario it was not designed for), or trust (the business is not yet willing to accept automation for this decision type). Without this lens, the team treats every exception the same way. With it, routing becomes precise, escalation paths become clear, and resolution time drops because the right expertise handles the right case type.

When exception source and resolution type align, the operation becomes manageable. When they do not, the queue grows faster than the team’s capacity to clear it. Email threads and spreadsheets become the system of record. The workflow that “works” in the demo becomes the one no one wants to touch in production.

The Design Implication

The exception math, the measurement gap, and the taxonomy share a common implication: exception flow is not an edge case to handle after the workflow ships. It is the architecture the operation should be designed around from the start.

Most teams treat exception handling as a support function, something bolted onto the edge of a workflow after go-live. At pilot scale, that works. The team absorbs exceptions through effort: longer hours, experienced people covering gaps, workarounds routed through email. Production breaks that model. Volume does not wait for the team to catch up.

Designing around exception flow means sizing triage capacity before volume arrives, mapping resolution paths before exceptions land in the queue, and building continuous monitoring into the workflow from day one rather than adding it after the first crisis. It also means choosing which exception types the organization will invest in resolving systematically and which it will accept as the cost of operating at scale. Those choices are strategic, not operational, and they shape the economics of every workflow the organization runs.