Exception Queues: When Marketing Agents Must Escalate to Humans

In Eric Siu’s September 19 Leveling Up episode, the speed-to-lead qualify bot gets a classifier layer. The operational question lands in Alfredo’s Slack queue: what should happen when the classifier cannot confidently qualify a lead? Sending every uncertain result into the sales motion wastes attention. Dropping those results leaves unresolved work invisible.

The same tape names a concrete failure to catch earlier: a student or job seeker entering a workflow that could burn a dial. The classifier can identify that risk without talking to the lead or transferring anyone. That boundary gives Single Grain’s exception-queue design its starting point: classify the work, preserve the evidence, and route uncertainty to someone who can resolve it.

Quick Overview

A marketing-agent exception queue is a typed backlog of decisions the agent cannot safely finish. Each item needs a trigger, evidence packet, owner, and allowed disposition. Runtime controls still matter, but they do not explain how an unresolved lead becomes a completed decision. Build that resolution path before expanding the agent’s permissions.

• Route uncertainty to a named owner rather than a generic alert channel.
• Separate suspected disqualification from confirmed disqualification.
• Include the evidence needed to decide without reconstructing the run.
• Fix missing escalation paths before buying a stronger model.

Why kill switches alone are not an exception queue

A kill switch stops execution. An exception queue retains unfinished work and makes its next decision explicit. The distinction matters when a healthy system encounters an ambiguous lead: there may be no reason to stop the entire workflow, but there is a reason to hold that lead’s next action.

Single Grain’s guide to SLAs and kill switches covers runtime limits and hard stops. This page covers the record left behind when a particular job cannot proceed: why it stopped, what evidence exists, who owns it, and how it returns to the workflow. A Slack notification without those fields is only a notification.

Anthropic’s guidance on building effective agents favors simple, composable workflows over unnecessary complexity. Apply that principle here: a classifier, typed exception record, and explicit routing rule can be sufficient. Do not add an autonomous coordinator just to compensate for undefined ownership.

Worked scene: low-confidence qualify stays in a high-signal human queue

In “Jev Is Unfair For Work,” Eric describes upgrading the qualify bot with classification while keeping Alfredo’s Slack queue high-signal when confidence is low. The sequence matters: the bot receives a lead, the classification layer evaluates it, and uncertain classification needs a human path. The layer itself does not conduct the sales conversation or transfer the lead.

That changes the job scope. Give the classifier responsibility for a proposed class and its supporting evidence. Keep outreach and transfer outside that job. For the implementation, create a low-confidence exception containing the original inquiry, relevant qualification fields, proposed class, conflicting signals, and the pending action. Alfredo is the named decision owner in this scene, not an implied audience for a channel-wide mention.

High-signal routing requires more than hiding low-confidence results. Collapse duplicate notifications into the same open record. Distinguish a qualification ambiguity from missing contact data. Send the owner a specific question, such as whether the inquiry satisfies the documented buyer criteria, rather than a transcript with “please review” attached.

Success means an uncertain lead remains retrievable, has an accountable owner, and exits with a recorded decision. It does not mean the classifier always produces a confident label. Keep this boundary explicit when designing speed-to-lead agent workflows: response speed cannot resolve missing qualification evidence.

Worked scene: DQ classes escalate before you burn a dial or send

The second decision in Eric’s classifier discussion is catching a student or job seeker before spending a dial. That recommendation moves disqualification detection upstream of the costly side effect. It also requires separating what the lead actually said from what the classifier inferred.

For this implementation, define student inquiry and job-seeking inquiry as distinct DQ classes, each with documented evidence requirements. A suspected class holds the pending dial or send and creates an exception. A confirmed class can follow an explicitly authorized suppression rule. Do not let an unsupported label overwrite the CRM’s qualification status.

The evidence packet should carry the inquiry text, the matching DQ criterion, any contradictory buyer signal, and the action being withheld. The resolver can then uphold the class, correct it, or request missing information. That is materially different from receiving a Slack message saying “bad lead.”

Eric’s point that classification alone is helpful changes the purchase decision, too. Buy or build the narrow classification layer if that resolves the current bottleneck. Do not require it to become a voice agent, lead-transfer system, and CRM operator before it delivers value. Those are separate jobs with separate permissions.

Exception queue contract (triggers, evidence packet, owners, dispositions)

Eric’s instruction to define evaluation criteria before the agent acts means escalation belongs in the job card, not in a cleanup checklist. Specify low confidence, missing required evidence, and policy conflict as distinct triggers. Confidence must be tested against labeled examples; a model’s confident wording is not a qualification criterion.

• Trigger: Store a stable exception type and the criterion that fired. Preserve multiple triggers when they coexist.
• Evidence packet: Include the source record, relevant excerpts, proposed classification, uncertainty, rule version, and held action.
• Owner: Assign a person or staffed role, plus a fallback owner. A channel name alone cannot own a decision.
• Dispositions: Allow accept, edit, reject, or requeue. Require a reason and define what each choice permits downstream.
• Closure: Retain the decision history and prevent retries from duplicating the held action.

This is the human approval boundary. Eric’s discussion of people reviewing output and managing workflows supports keeping judgment with the resolver: valid JSON does not settle an ambiguous business decision. Accept confirms the proposed resolution; edit corrects it; reject refuses it; requeue identifies missing evidence and its next owner. Only the applicable disposition releases the held action.

The NIST AI Risk Management Framework organizes its Core into four functions: Govern, Map, Measure, and Manage. That is a useful accountability structure, not a promised escalation rate. The chart counts framework functions only.

Measure unresolved inventory by exception type, evidence completeness, and whether dispositions produce the intended downstream state. Establish your own baseline before setting targets. Use Single Grain’s marketing-agent pipeline RACI to distinguish the workflow owner, resolver, and technical maintainer.

The walk-away rule is straightforward: do not automate consequential qualification when nobody can define the classes, supply the evidence, or staff the exceptions. Eric’s observation that a better model still needs a better workflow rules out buying a stronger model to conceal those gaps. Ship the schema first; then evaluate whether model quality remains the bottleneck.

Single Brain installs the system; Single Grain runs it when you need the team

Single Brain is the AI implementation OS for job-specific agents, evaluations, and kill switches. For this job, the installation also needs a classification contract, typed exception records, evidence capture, routing, and disposition handling. Those artifacts connect the agent’s output to an accountable operating process.

Keep Alfredo’s queue from the tape as the design test: can the assigned resolver see why a lead landed there and finish the decision without rebuilding its history? If not, the implementation is incomplete, regardless of model capability.

Hire Single Grain to install and run that system when you do not want to staff it internally. The engagement should identify the workflow owner and human ship gate by name, with representative qualification and DQ cases defining acceptance. Talk to Single Grain about the pipeline job, the actions it must hold, and the exceptions your team needs resolved.