The agent executes inside approved rules with receipts, bounded permissions, and measurable output.
Agent Managers Need Exception Queues Before Edge Cases Become Policy
If every weird case becomes an agent decision, your operating policy is being rewritten by exceptions.
Autonomy breaks at the edge.
Most machine workers perform well on the normal path. The trouble starts when the work stops being normal: missing CRM fields, a customer with two owners, a campaign rule that conflicts with a territory rule, a renewal account that looks like a prospect, a refund request that resembles fraud but is not fraud.
Without an exception queue, the agent has two bad options. It can guess and keep moving, which creates silent policy drift. Or it can escalate everything, which turns human review into a clogged inbox. Neither is management.
An exception queue is the middle layer. It catches cases where the machine worker has enough context to package the issue, but not enough authority to decide it. That keeps throughput high while preventing unusual cases from becoming unapproved precedent.
The agent packages ambiguity, recommends a path, and waits because the decision may change policy.
The agent freezes authority because customer exposure, data conflict, or operational damage crossed the stop line.
The mistake is treating ambiguity like backlog.
The worker improvises precedent
A RevOps agent sees conflicting account ownership, chooses the newest enrichment source, updates routing, and keeps processing. The decision looks small until sales disputes the forecast and marketing inherits the wrong audience logic.
The worker opens an exception
The agent records the conflict, names the source-of-truth options, estimates blast radius, recommends a winner, and parks the case for an owner. No write happens until authority is explicit.
This is where agent ops becomes management instead of prompt tuning. The question is not whether the model can produce a plausible answer. The question is whether the answer has the right to become company behavior.
A pricing agent should not invent discount policy.
Imagine a machine worker supporting expansion deals. It reviews usage, renewal date, product mix, support load, and prior discounting. On ordinary accounts, it drafts the next-best offer and routes it to the AE. That is useful labor.
Then it hits a customer with a legacy contract, a strategic logo flag, and a regional reseller clause. The data suggests a discount. The contract suggests caution. The AE wants speed. If the agent simply applies a generic pricing rule, it has created a precedent finance never approved.
The exception queue changes the behavior. The agent labels the case as policy-sensitive, lists the conflicting signals, calculates revenue exposure, shows which rule would win under current policy, and asks the pricing owner to decide. Once the owner decides, that ruling either becomes a new approved rule or remains a one-off. Either way, the agent did not smuggle policy into production.
Build the queue like a control plane, not a dumping ground.
Route cases to exception when source-of-truth conflicts, customer exposure, policy ambiguity, owner mismatch, or high-value records appear.
Every exception should include facts, options, recommended action, blast radius, confidence, and rollback path.
Exceptions need named decision rights. Otherwise the queue becomes a warehouse for anxiety.
Repeated decisions should become approved policy, updated guardrails, or a tighter stop condition.
The queue should shrink over time. If the same exception appears ten times, the organization has learned something. Either the agent needs a better rule, the process needs a cleaner source of truth, or the business needs to admit the edge case is now part of the normal path.
Concrete takeaway for this week
Pick one active agent and define the cases it is not allowed to decide alone.
- List five exception triggers: conflicts, high-value customers, unclear ownership, policy-sensitive changes, and customer-visible risk.
- Set the package standard: facts, options, recommendation, confidence, affected records, and rollback path.
- Name the owner: every exception class needs a person or role with decision rights.
- Close the loop: convert repeated exceptions into approved rules or explicit kill criteria.
The blunt rule: if a machine worker can decide edge cases without an exception queue, it is not just doing work. It is quietly writing policy.