Quick answerNot every request that falls outside an AI agent's normal policy should be refused. Some are legitimate edge cases where the rule was written for the common case and the customer in front of the agent is a real exception to it. The decision framework is: if breaking the rule creates safety, legal, or brand risk with no upside, hard code a refusal. If breaking the rule is plausible, reversible, and a human with context could reasonably approve it, route it to a bounded exception workflow instead of either auto-approving or flatly refusing. The workflow needs a narrow request format, a named approver, a time limit, and a record of what was approved and why, so it does not quietly become a second, undocumented policy.
A refusal and an exception are solving two different problems
A hard coded refusal exists because some requests should never be honored, regardless of the specific customer or context. An AI agent refusing to share another customer's account details, override a safety check, or promise something the company cannot deliver is not being unhelpful, it is doing its job correctly. That design problem, how to build a refusal that is firm without sounding robotic or adversarial, is its own discipline covered in designing a refusal boundary for business rules.
An exception process solves a different problem: what happens when the rule itself is generally correct but this particular case has context the rule did not anticipate. A refund policy that excludes items past 30 days exists for good reasons, but a customer who was hospitalized and could not return the item in time is not trying to game the system, they are the exact kind of case a human reviewer would approve in five seconds. Treating that request the same way as a fraud attempt, with a flat refusal, creates real brand damage for no real protection.
How to decide which bucket a policy area belongs in
Sort policy areas into three groups before you write a single line of agent behavior:
- Never override. Legal requirements, safety checks, data access boundaries, anything where an incorrect exception creates liability or harm regardless of the specific circumstances. These get hard coded refusals with no exception path at all.
- Exception eligible, human approved. Business rules with legitimate edge cases: refund windows, eligibility cutoffs, discretionary discounts, deadline extensions. These get routed to a human, not auto-approved by the agent and not flatly refused.
- Agent discretion within a range. Cases with low downside where you are comfortable letting the agent decide within pre-approved bounds, without a human in the loop at all.
Most teams only build the first and third categories and force everything else into one of them, which either makes the agent too rigid (frustrated customers who had a legitimate case) or too permissive (a slippery slope where the agent starts approving things nobody signed off on).
Designing the exception request itself
When a request lands in the "exception eligible" bucket, the agent should not just forward the raw conversation to a human and wait. A well designed exception request includes:
- What rule is being requested to bend, stated plainly, not buried in transcript.
- The specific facts that make this case different, pulled from the conversation, not the agent's own judgment about whether they are compelling.
- What the agent is not deciding. The agent should never present its own recommendation as if it were the decision; it surfaces the case and lets the approver decide, similar in spirit to the pattern in designing human-in-the-loop without a bottleneck, where the goal is fast, structured escalation rather than an approval queue that stalls everything.
- A time limit. If no human responds within a defined window, the default outcome should be the safe one, which is usually the standard refusal, not a silent auto-approval by timeout.
Keep the exception process from becoming a second, undocumented policy
The failure mode to watch for is not a bad first design, it is drift. Once a human approver starts granting the same exception repeatedly, that is a signal the policy itself needs to change, not that the exception process is working well. Review exception approvals on a regular cadence and ask, for each recurring pattern, whether it should graduate into the actual policy (making the agent's job simpler) or whether the exceptions are inconsistent enough that the approving humans need clearer guidance. Left unreviewed, an exception workflow quietly becomes a shadow policy that nobody wrote down, which is a worse version of the problem covered in refusal boundary design for medical and legal contexts, where undocumented judgment calls are exactly what creates inconsistent, hard to defend outcomes.
FAQ
How is a policy exception different from the agent just being wrong? A policy exception is a deliberate, documented decision by a human to deviate from a written rule for a specific case. An agent being wrong is an error. If exceptions are not tracked and reviewed, the two become indistinguishable over time, which is the core risk of skipping the record-keeping step.
Should the agent ever be allowed to auto-approve an exception? Only within a pre-approved range that you would be comfortable seeing that agent grant to anyone, at any time, with no oversight. If the exception has meaningful downside or inconsistency risk, keep a human in the loop.
What happens if no human responds in time? Default to the safe outcome, almost always the standard refusal. A silent timeout that defaults to approval turns the exception process into an easy way to route around policy entirely.
Does every business rule need an exception path? No. Rules with real safety, legal, or fraud implications should stay hard refusals with no exception path. Reserve exception workflows for rules where a reasonable human, given the full context, could genuinely go either way.