A workflow handles ordinary requests quickly. Then a customer supplies two different dates, a required record disappears, and the sending tool times out. The system reports three exceptions and considers its job complete.
Somebody still has to resolve them. If that person receives only a warning and a long conversation history, the workflow has moved the difficult work without making it easier.
The principle “automate normality, escalate exceptions” is useful only when both halves have an operating definition. Normal cases need a supported scope and an observable result. Exceptions need an owner, a decision packet, a time expectation, and a recovery path.
The question is which routine cases can be automated and which exceptions require a person. The answer should follow evidence, consequences, and the capacity of the entire process. A familiar-looking request is not automatically safe. A human handoff is not automatically effective.
This chapter proposes a routing design. Its examples are hypothetical, and no Salars private workflow or customer system was tested. The Age of AI Leverage series treats exception handling as part of productive capability rather than an inconvenient cost outside it.
Normal means supported, not merely common
A common request can still require judgment. A rare request can sometimes be handled by a clear rule. Frequency and routineness are different properties.
Consider a request for a copy of a publicly available instruction sheet. If the item is identified and the current approved sheet is available, the case may follow a simple supported path. A frequently received demand for a refund could require identity checks, order facts, and discretion under a policy.
A normal case should satisfy explicit conditions. The required inputs are present, the sources agree where agreement matters, the action is permitted, the policy applies, and the expected result can be checked. Those conditions define the operating envelope.
The envelope should be narrow enough to evaluate. “Handle customer service” is a broad ambition. “Prepare a draft answer to this public product-information question using the verified instruction sheet” is a concrete job.
A system can expand its envelope when evidence supports the new case type. It should not infer that a success on one task grants authority over adjacent tasks. Explaining an instruction does not establish readiness to make a warranty decision.
The existing reviewed-workflow guide supplies background on a complete case. This chapter focuses on how the ordinary path and the exception path remain useful together.
Write the entry conditions before the happy path
A workflow often begins with the steps for a perfect input. The entry conditions deserve equal attention because they determine whether the perfect path applies.
For a proposed document-renewal reminder, entry conditions might include a verified document identifier, a recorded expiry date, a current responsible person, and no reminder already recorded for that renewal period. The allowed action may be a private reminder, with renewal itself left to the person.
If a date is missing, the system cannot calculate the reminder window. If the owner is unclear, it cannot choose a recipient by guessing. If the document has already been renewed, a reminder based on the old date may be misleading.
Each condition should produce an understandable result. Missing date becomes an evidence request. Conflicting dates become a discrepancy for review. An already-issued reminder becomes no action with a recorded reason. A verified ordinary case proceeds.
This makes the routing rule inspectable. A person can ask why the case qualified or why it stopped. The answer should point to the controlling condition, not merely a model’s confidence score.
The reality inbox helps establish event identity and reconcile updates before routing. The normal path should use those accepted facts rather than repeat the intake problem inside every workflow.
Divide exceptions by the decision they require
Not all exceptions need the same recipient or response. A useful taxonomy is based on what must happen next.
A missing-evidence case needs someone to obtain or verify a fact. An interpretation case needs someone to resolve ambiguity. An authority case needs an authorized decision. A technical failure needs investigation of actual system state. An urgent consequence may need an immediate operational response.
These categories can overlap. A changed deadline might involve both conflicting evidence and a customer commitment. The packet should identify the primary next decision while preserving the relevant context.
A generic “needs review” category hides the distinction. The recipient must first determine the problem before they can solve it. A more useful message says, “Two expiry dates conflict; verify the source document before the reminder can be issued.”
The taxonomy should remain small enough to use consistently. A hundred labels can create another classification task without improving routing. Start with the few decision types the process actually produces, and revise when a new type changes the destination or response.
The point is to make the next action clearer. The category is a tool for that purpose, not a score of how unusual the request appears.
A confidence score cannot replace the boundary
An AI system may assign high confidence to a routine classification. That score does not establish that the source is current, the requester is authorized, or the action has occurred.
Confidence can help prioritize review if its meaning has been evaluated for the task. It should not override hard conditions. A missing required date remains missing even when the model is confident about what the person probably meant.
The consequence also matters. A tentative internal label can tolerate a different error profile from an external promise or a change to a financial record. The routing design should state which facts must be verified regardless of the score.
This avoids a common failure: treating all uncertainty as something the model can average into one number. Several kinds of uncertainty require different remedies. Missing evidence requires acquisition. Conflicting authority requires a decision. An unknown tool result requires state inspection.
The permission architecture develops enforcement of action limits. Here the routing rule should preserve the reason a case cannot proceed, so the receiver knows what would resolve it.
Give the person a decision packet
An exception should arrive with enough evidence to make the decision and little enough irrelevant material to keep the review manageable.
A useful packet states the case identifier, intended result, last verified state, controlling exception, supporting sources, actions already attempted, remaining time constraint, and available options. It also identifies what the system has not done.
For the reminder example, the packet could show the two recorded dates, links to their sources, the current owner, and whether any reminder was issued. It asks which date should become authoritative. It does not bury that question beneath a complete transcript.
A proposed response can help, but it should remain visibly proposed. The receiver should be able to change or reject it without reconstructing the evidence. A suggested action unsupported by the packet adds pressure rather than assistance.
Handoffs also need receipts. The originating workflow should know whether the exception reached the intended queue and whether someone accepted responsibility. Sending a notification is not the same as establishing an owner.
The packet should update when the situation changes. If new evidence arrives, connect it to the existing case rather than generate a second disconnected exception. Otherwise the reviewer may solve an outdated version of the problem.
Receiver capacity is part of the architecture
A workflow that produces exceptions faster than people can handle them creates a growing backlog. The average routine case may become faster while the most consequential cases wait longer.
Estimate the receiving burden before expanding volume. How many cases are expected? How long does each review take? Which require specialized help? How quickly must the answer return? The estimates can begin as explicit assumptions and then be checked against actual operation.
Google’s SRE guidance describes overload protection using resource limits and request criticality, and warns that retries can add load. Its computing context is different from human review, but it illustrates why routing needs capacity and priority controls. Google SRE
For a human queue, the proposed response may be to limit new work, batch nonurgent questions, or assign a backup owner. Do not copy technical thresholds into a staffing rule without evidence. The general lesson is that a receiving system has finite capacity.
A critical exception should not be lost among low-value requests. Conversely, marking everything critical defeats priority. Define urgency according to consequence and time, not according to how insistent the incoming text sounds.
The personal chief of staff can help surface the conflicts this creates. It cannot make a person available merely by adding another item to their day.
Work through a queue calculation
Suppose a hypothetical workflow receives one hundred cases per week. Eighty satisfy its supported routine conditions. Twenty require human review. If each review takes fifteen minutes, the receiving burden is five hours.
Now imagine a narrower design classifies thirty cases for review because it refuses to guess at missing information. The burden becomes seven and a half hours under the same assumed review time. That does not automatically make the narrower design worse; it may prevent costly unsupported actions. It does reveal a capacity decision.
A better packet could reduce review to ten minutes per case. Thirty reviews would then require five hours. Those numbers are illustrative, not measured gains. The business would need to check that shorter review preserves the accepted result.
If the available reviewer has four hours, even the five-hour queue is unsustainable under these assumptions. The response might be to reduce intake, obtain another qualified reviewer, repair the missing source fields, or narrow the service promise. Faster ordinary processing does not resolve that gap.
The example also exposes an incentive problem. A system could reduce the visible exception count by hiding uncertainty. The evaluation should therefore inspect routine completions, not merely celebrate a smaller queue.
Check whether the action happened before retrying
Technical exceptions can be especially misleading. A sending tool times out. The workflow does not know whether the message was sent. Retrying immediately might send it twice.
The correct response depends on the tool’s documented behavior and the available action receipt. A process should check the authoritative state or use a supported duplicate-prevention mechanism before repeating a consequential action.
An unknown result is different from a confirmed failure. The case record should preserve that distinction. “No confirmation received” is more accurate than “message not sent” when the system lacks evidence either way.
Retries need limits and a reason. Repeating an action that cannot succeed because permission is absent does not create useful recovery. Repeating requests into an unavailable service can increase load and delay other work.
For a first version, keep consequential action separate from drafting and make uncertain results a human review case. As the implementation becomes clearer, specific recovery paths can be automated when the service supports them and tests establish the relevant behavior.
A workflow is not complete simply because it tries until something reports success. It must be able to explain the actual result and the obligations that result created.
Design the fallback for a real person
An outage can require a manual process. The fallback should identify where the person finds the records, what must be checked, and how completed work is recorded so the automated system does not repeat it later.
For the renewal reminder, a fallback might use the same accepted document list and a manual log of reminders issued. When automation returns, it reconciles that log before proceeding. A separate emergency spreadsheet nobody merges back can create duplicate or missed work.
Some source failures should stop a workflow entirely. If the required fact cannot be verified, a manual person may also be unable to proceed responsibly. “Fallback” does not mean authorizing a guess that software was forbidden to make.
Keep current obligations visible while the routine action step is paused. A person should be able to distinguish pending cases, completed cases, and unknown outcomes. Those states help determine which work is safe to resume.
The fallback should be tested on representative cases before the system is needed under pressure. A readable checklist and retrievable evidence may be more valuable than an elaborate recovery plan nobody can execute.
Learn from exceptions without normalizing every one
Repeated exceptions can reveal a missing field, a confusing rule, or an unsupported part of the service. The right improvement may remove the cause rather than make the model more willing to proceed.
If many renewal records lack an owner, repair ownership. If dates conflict because old records are never retired, repair version handling. If unusual cases require professional judgment, retain that boundary instead of trying to force them into a routine category.
A resolved exception should have a scope. A decision for one customer or document does not automatically establish a general rule. The learning ledger can preserve the decision, evidence, and conditions under which it applies.
Before expanding normality, test the proposed rule on fresh cases and relevant counterexamples. The expansion should demonstrate correct completion, appropriate no-action decisions, and useful escalation. A smaller exception count alone is insufficient.
It is also legitimate to stop expanding. Some workflows reach a point where additional automation produces little benefit or requires excessive authority. A dependable boundary can be a better result than universal coverage.
Audit the routine path as well
An exception queue shows what the system recognized as difficult. It says little about the exceptions the system failed to recognize.
Sample routine completions and compare them with the authoritative inputs and accepted rule. Look for unsupported promises, stale records, incorrect matching, and actions that were reported but not verified. The sample should include different sources and case types within the claimed scope.
Keep protected evaluation cases separate from routine tuning. When a case is used to revise the system, it becomes part of development. Fresh cases are needed to support a later claim about unfamiliar work.
Track the cost of correction and delayed consequences. A routine case that requires expensive repair next week belongs in the evaluation of today’s process. Otherwise the workflow can appear efficient by moving its failure cost outside the reporting window.
Use the AI leverage equation to compare complete work. The relevant result is accepted routine work plus manageable exceptions, maintenance, and recovery—not the speed of the automatic step alone.
AI Leverage in Practice
Choose one repeated task with clear sources and a low-consequence starting action. Write the routine entry conditions, accepted result, no-action cases, exception categories, receiving owner, and fallback.
Begin with drafts or internal preparation. Test an ordinary case, missing evidence, conflicting records, absent authority, duplicate trigger, and unknown action outcome. Define expected behavior independently of the system’s answer.
Today, existing tools can apply rules, retrieve records, prepare packets, and assist classification within configured access. Flexible interpretation still requires evaluation, and broad autonomous completion should not be assumed. Future systems may handle more case types, but each expansion needs evidence about the specific work and consequences.
Measure both sides of the design. Inspect routine completions, time the review packets, observe backlog age, and count correction and maintenance. Pause intake or action when the receiving capacity or source quality cannot support the current promise.
Retain the smallest useful scope. A workflow that reliably handles ordinary cases and gives people clear exceptions can create more value than one that claims universal completion while concealing unfinished work.
Normality with a visible boundary
Automation works best when normality means supported conditions and an accepted result. Escalation works best when a person receives a clear decision, relevant evidence, and the capacity to respond.
The two paths belong to one process. Neither should be evaluated as though the other were free. A useful system makes the boundary inspectable and preserves the ability to stop, recover, and revise it.
Continue through the series hub, or browse the wider AI section. The next chapter examines the permissions that enforce these boundaries when a system can actually act.
Sources
- Google SRE: Handling Overload, chapter 21, Alejandro Forero Cuervo. Technical guidance on capacity, criticality, and retry budgets; the human-review comparison here is a proposed analogy, not a measured staffing result.
- Salars.net: Put Knowledge Into a Reviewed Workflow. Existing workflow background; this chapter emphasizes routing, receiving capacity, and recovery.
Loading comments…