The Exception Queue Is the Missing Layer for Production Agents

Most agent demos assume a person is standing next to the run. The agent asks for approval, the person clicks yes, and the workflow continues. That works in a video. It breaks in operations.

Real agent work crosses time, roles, systems, and accountability boundaries. A support agent may need a billing-policy exception. A coding agent may need permission to touch a risky migration. A healthcare workflow may need a human to verify that the requested action matches the patient context. A procurement agent may discover that the account, price, or authority it expected is missing. In each case, the agent should not keep improvising. It should stop cleanly.

That stop needs somewhere to go.

The next practical control surface for production agents is an exception queue: a durable, typed, auditable backlog of paused agent runs that need human judgment, missing data, policy clearance, or safe retry before they continue. It is less glamorous than a new model, but it is the difference between an agent that can be supervised and an agent that merely hopes someone is watching the chat window.

From approval prompts to operational queues

Most teams start with a simple pattern: before a dangerous tool call, ask a human. Modern agent frameworks already support pieces of this. OpenAI's Agents SDK documents guardrails that can validate inputs and outputs, and it notes that tools requiring approval can run input guardrails before a pending approval interruption and again before execution. Its run-result model also exposes interruptions as part of the state of a run. LangGraph documents interrupts that save graph state through persistence and wait until execution is resumed. MCP's elicitation capability gives servers a way to request structured user input through the client. Temporal's workflow model shows the older, battle-tested pattern behind all of this: durable execution, persisted state, and continuation after delays or failures.

Those primitives are useful, but they are not the whole operating model. A modal prompt is not enough when the approver is offline, when the answer requires another department, or when the pause itself must be reviewed later. The question is not simply, "Can the agent ask a human?" The production question is, "Can the organization manage the agent's unresolved work?"

An exception queue answers that question.

Each paused run becomes a work item. The item carries a reason code, the agent's evidence packet, the proposed next action, the allowed resolution choices, the resolver role, the expiry policy, and the checkpoint needed to resume safely. The queue can be searched, assigned, measured, escalated, and audited. It turns agent uncertainty into operational work instead of hidden risk.

What belongs in an agent exception record

A useful exception record is more than a transcript. At minimum, it should include five parts.

First, it needs a clear stop reason. "Needs approval" is too vague. Was a policy threshold exceeded? Was required data missing? Did a guardrail trip? Did a tool return an inconsistent result? Did the run reach a budget or latency boundary? Reason codes let teams measure where agent workflows actually fail.

Second, it needs the evidence the resolver should inspect. That means the relevant user request, tool outputs, policy checks, retrieved records, model rationale where appropriate, and the proposed continuation. The resolver should not have to reverse-engineer the run from a chat log.

Third, it needs typed resolution options. Free-form replies are tempting, but they are hard to validate. MCP elicitation points in the right direction: ask for structured input. The queue item should make the allowed actions explicit: approve, reject, request more information, edit a field, choose from a list, reroute to another role, or terminate the run.

Fourth, it needs resumability semantics. If the human approves, what exactly resumes? From which checkpoint? With which input? Is the next tool call idempotent? Could replay double-charge a customer, resend a message, or reopen a ticket? LangGraph-style interrupts and Temporal-style durable workflows are valuable because they make continuation a designed state, not a lucky side effect.

Fifth, it needs ownership and time. An exception without an owner is just another way for automation to stall. Each item should have a resolver role, an SLA, escalation rules, and a timeout behavior. If the deadline passes, the agent should not silently continue; it should follow a documented fallback such as canceling, escalating, or moving to manual processing.

The anti-patterns are already visible

The weakest version of human-in-the-loop is a screenshot in Slack: the agent posts context, someone reacts with a check mark, and the workflow moves on. That may be acceptable for a prototype, but it loses the chain of custody. The approval is not attached to the run state. The approver may not have seen the final tool input. The resolution may be impossible to audit later.

Another common anti-pattern is the invisible retry loop. The agent hits a missing precondition, retries with slightly different wording, and eventually either fails noisily or succeeds for the wrong reason. A queue forces the system to admit that the run is blocked and to preserve the evidence at the moment of blockage.

A third anti-pattern is treating every interruption as the same kind of human approval. Some pauses are risk decisions. Some are data-completion tasks. Some are policy escalations. Some are engineering bugs. Putting all of them behind one "approve" button collapses important operational distinctions.

How to build the first version

The first version does not need to be elaborate. Start by making every agent stop condition explicit. Guardrail tripwires, tool-approval interruptions, missing required fields, conflicting retrieved facts, max-budget limits, and failed idempotency checks should all produce structured exceptions.

Next, define the queue schema before designing the UI. Capture run ID, workflow name, tenant or customer scope, reason code, risk level, proposed action, evidence links, checkpoint pointer, resolver role, allowed outcomes, deadline, and audit fields. The UI can be simple if the schema is sound.

Then separate resolution from continuation. The human resolves the exception; the agent runtime resumes from a checkpoint using the structured resolution. That separation matters. It prevents the operator from accidentally becoming a prompt engineer in the middle of a regulated workflow.

Finally, measure the queue. Which workflows generate the most exceptions? Which reason codes dominate? Which exceptions are approved automatically after review and should become policy? Which ones repeatedly reveal bad retrieval, bad permissions, or poor tool contracts? NIST's AI Risk Management Framework emphasizes governance, mapping, measuring, and managing risk. An exception queue makes those verbs concrete for agents.

Autonomy needs a place to stop

Better agents will not eliminate exceptions. They will make exceptions more important, because the routine work will move faster and the remaining pauses will concentrate judgment, authority, and risk.

That is why the exception queue should be designed as first-class infrastructure. It is the place where autonomy hands off without losing context. It is where human judgment becomes structured input instead of a chat artifact. It is where paused work stays visible rather than disappearing into logs.

The safest production agents will not be the ones that never stop. They will be the ones that know exactly when to stop, what evidence to preserve, who should decide, and how to continue only after the exception has been resolved.