Exception Queues for AI Workflows: Owner, Reason, Deadline

An exception queue is a shared list of every case an AI agent cannot finish alone, and each item on it has a named owner, a written reason for escalation, and a deadline for a decision. Without one, an agent tends to guess, stop quietly, or retry until something breaks, and the failure only shows up when a customer, invoice or delivery date is missed. This guide explains how to design that queue so every unfinished case lands with a person who knows it is theirs.

Key takeaways

• Every item in the queue needs an owner, a reason and a deadline. An item missing any of the three is a defect in the design, not a minor gap.
• Escalation should fire on named conditions the agent can check, not on a general sense of uncertainty.
• The agent should hand over the evidence it gathered so the person deciding does not start from zero.
• The age of the oldest open item tells you more about health than the total count.
• Each recurring exception should end in a recorded decision that becomes a rule, a memory update or a tool change.

Why silent failures are the real risk

A visible crash is the easy case. The agent throws an error, someone sees it, and the work is picked up. The harder failure is the one where the agent reports success, or simply drops the item, because nothing in the workflow asked it to say otherwise. That is what a silent failure looks like, and it is more common in multi-step workflows because each step can look fine on its own while the case as a whole stalls.

Consider an illustrative scenario. An agent processes supplier invoices. It reads an invoice, tries to match the vendor name to a record, and finds two candidate records with similar names. Rather than stopping, it picks the closer match and posts the invoice. Nothing is reported as wrong. Weeks later, a payment goes to the wrong account, and the team has no record that the match was uncertain. The fix is not a smarter model. The fix is a rule that says an ambiguous vendor match is an exception, that it goes to a named person with both candidates shown, and that it must be resolved before posting.

An exception queue turns that rule into an operating habit. The agent is allowed, and expected, to say that it cannot finish. The queue is where that statement goes.

Define what counts as an exception

Before you build anything, write down the conditions under which the agent must stop and hand the case over. Vague instructions such as "escalate when unsure" do not work, because the agent has no reliable way to measure unsureness and the people receiving the escalations cannot tell what triggered them. Useful conditions are concrete and checkable:

• A required field is missing or cannot be found in any approved source.
• Two sources the agent is allowed to use disagree on a fact that matters for the action.
• The requested action is above the approval limit written in the agent's permissions.
• A tool call fails again after the agent has retried it as the operating rules allow.
• The request falls outside the topics or customer segments the agent was assigned.
• A decision depends on a person's judgment about tone, exception policy or relationship history.

The last condition deserves attention. Agents are often built to be helpful, and they will try to be helpful about things that belong to a human. Naming these cases explicitly keeps the agent from filling the gap with plausible text.

Give every item an owner, a reason and a deadline

These three fields are what separate a queue from a pile. Each one has a specific job.

The owner is a role plus a named person, with a backup. A role alone, such as "finance," means nobody opens the item. A person alone means the item stalls the day that person is away. Connect the owner to the approval structure that already exists in your company. If you have not defined who can approve which kind of decision, the approval workflow comes first, and this guide on AI approval routing covers how to route each request to the right approver.

The reason is a short fixed vocabulary, such as missing data, source conflict, above limit, tool failure, out of scope and judgment required, plus a free-text line that explains the specific case. The fixed vocabulary lets you count reasons over time. The free text lets the owner understand the case without reopening every source.

The deadline should come from the business consequence of waiting, not from a default number. An unmatched payment that blocks a delivery has a different clock from a question about a customer's preferred meeting format. Set the deadline per exception type when you design the queue, then let the item inherit it automatically. An item without a deadline will be read, shrugged at, and left open.

An item without an owner, a reason and a deadline is not in a queue. It is in a hiding place.

A step-by-step plan to build the queue

You do not need special software to start. A shared table with the right columns, a clear list of exception types and an agreed review rhythm are enough to run a first version. The order matters, because each step makes the next one meaningful.

• Step one: list the work the agent will handle and the points in each task where it could fail to finish. Process mapping helps here, and this guide on mapping the work before the agent walks through the method.
• Step two: name the exception types from the conditions in the previous section, and keep the list short enough that people remember it.
• Step three: assign an owner and a backup to each type. If an owner cannot be named, stop and resolve that before going further, because the agent will otherwise create work for nobody.
• Step four: set a deadline for each type based on what waiting costs the business, and write it next to the owner.
• Step five: define the handoff format, which is covered in the next section, and test it with three or four realistic cases before live use.
• Step six: run the agent in a mode where it proposes handoffs but does not act on the held items. Shadow operation is a useful way to see which exceptions it raises and which it misses, and this guide on watching agents before granting autonomy describes that approach.
• Step seven: schedule a short weekly review of the queue with the owners, covering open items, overdue items and reasons that appeared more than once.

One caution on step six. If the agent raises very few exceptions during a trial, do not conclude that the work is easy. Check whether the agent is quietly handling cases it should have escalated. Sample a handful of its completed items and ask whether any of them should have gone to a person.

What the handoff must contain

A handoff is the message the agent writes when it passes a case to a person. A poor handoff says "could not complete, please review." That sends the owner back into every source to reconstruct what the agent already knew. A good handoff is short and complete:

• The task as the agent understood it, in one sentence, so a misread request is caught immediately.
• What the agent did and changed, including anything it started but did not finish.
• What it found in each source it checked, with links or identifiers that the owner can open.
• The specific fact or step that blocked completion, and why the agent could not resolve it within its permissions.
• The options the agent can see, stated without a recommendation unless the policy asks for one.
• What it did not do, such as whether it sent anything to a customer or posted to a ledger.

The last item matters most for trust. An owner who knows the case is frozen can act on it confidently. An owner who does not know whether a partial action went out will hesitate, and the case will age. Keeping an audit trail of each action helps here. The general principles of traceability and human oversight appear in the [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework), and the observability vocabulary in the [OpenTelemetry observability primer](https://opentelemetry.io/docs/concepts/observability-primer/) is useful when you decide what to log.

Watch the queue as a control, not an inbox

Most teams look at an exception queue the way they look at an inbox, by clearing items. That treats the queue as work to finish rather than a signal about the system. Three views are more useful.

Age of the oldest open item shows whether owners are actually responding. A queue where the oldest item is a week past its deadline has an ownership problem, regardless of how many items are open. Items past deadline, grouped by owner, show whether a backup is needed. Recurring reasons show where the system is weak. If "missing data" appears again and again for the same field, the problem is probably an absent source or a missing memory entry, not a lazy person. Repeated reasons are the input to improvement, which is why they should flow into a regular report. A short weekly business report can show coverage and decisions side by side, so that leaders see both what the agent handled and what people decided.

When a reason keeps recurring, record the decision that resolves it. Sometimes the right answer is a new rule the agent can apply. Sometimes it is a memory correction, and the process for resolving conflicting facts is described in this guide on which fact wins when agent memories conflict. Sometimes the answer is that the task should stay with a person. All three are valid outcomes. Leaving the same reason open week after week is not.

How Be Human runs exception queues

In a Be Human engagement, the exception queue is part of the first design rather than an add-on. The first project defines one useful role, the memory and tools that role needs, the approval boundaries, and an observable success criterion. The exception types, owners, deadlines and handoff format are defined with the client in that same scope, and they are written into the agent's operating context so the agent applies them consistently. In managed operations, recurring evaluations check whether the agent is escalating the right cases and missing none, permission reviews confirm that the approval boundaries still match how the business works, and incident response covers queue failures such as a tool that stops returning data. Recurring exception reasons are turned into controlled changes that go through the same review as any other agent change. The aim is that no case disappears, and that every unfinished case has a person responsible for it.

If you want to find the first task worth handing to an agent, and to see where exceptions would land in your current work, take the free Be Human AI diagnostic.

Frequently asked questions

Who should own the items in an exception queue? Each exception type should have a named owner from the team that already holds the decision, along with a named backup for absences. Avoid assigning the queue to a general mailbox, because nobody feels responsible for an item in a shared place. The owner should be the person who can approve or reject the action the agent could not complete.

How many exception types should a first queue have? Start with the smallest set that covers the real failure points you found when mapping the work, usually a handful. Too many types make the owners guess which one applies, and the reason field stops being useful. You can add types later when recurring reasons show that a category is hiding a different problem.

How do you set the deadline for an exception? Tie the deadline to the cost of waiting for that specific type of case, such as a delivery that cannot be scheduled or a customer reply that has a service commitment attached. Write the deadline next to the owner when you define the type, so it is applied automatically. Review it once a month, because the business consequence of delay can change.

Can an agent resolve some exceptions on its own? Yes, when the rule is explicit, the evidence is in an approved source, and the action sits inside the permissions the agent was given. A useful test is whether the owner would accept the same resolution if they had made it personally. Anything that depends on judgment, relationship history or an action above the approval limit should stay with a person.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.