- In short
- Policy gap escalation design is the pattern for handling requests that fall outside documented policy. Because the agent cannot invent a rule, it escalates to a human and includes structured context: exactly what the customer requested and which policy boundary the request exceeds.
What policy gap escalation design solves
Policy gap escalation is the second of the three valid escalation triggers, and this knowledge point is about designing the handoff it produces. A policy gap arises whenever a customer asks for something that the documented policy does not clearly cover. It is neither plainly allowed nor plainly refused. The agent has run out of authority, not out of capability, and the design question is how to route the request to someone who does have authority, with enough context that they can act fast.
The applied skill here is twofold: recognising the gap, then shaping the escalation. Recognition means noticing that the request lives in the silence between policy rules rather than inside them. Shaping means packaging the situation so a human inherits a decision, not a mystery. Both halves matter, because a correctly recognised gap that is escalated with no context just moves the confusion to a busier person.
- Policy gap escalation
- The escalation pattern for requests that fall outside documented policy. The agent recognises it has no authority to decide the request, refuses to invent an exception, and hands off to a human with structured context: the specific request and the policy boundary it exceeds.
Why the agent must not invent an exception
The defining failure mode of this knowledge point is the helpful agent that fabricates policy. A customer asks for a competitor price match; the published policy covers only the store's own historical prices; and the agent, wanting to please, simply approves the match "as a one-time courtesy." It feels generous. It is also a commitment the company never authorised, made by a system with no standing to make it, and it sets a precedent the business now has to honour or awkwardly retract.
Anthropic's customer support guidance is explicit on this point: among the core guardrails for a support agent is to avoid making promises or entering into agreements it is not authorised to make. Inventing a policy exception is exactly such an unauthorised commitment. The agent's correct posture in a gap is humility about the limits of its authority. It can explain what policy does cover, but it routes anything beyond that to a human rather than improvising a new rule on the company's behalf.
Designing the handoff payload
Recognising the gap is only half the job; the other half is the structure of the escalation itself. A good policy-gap handoff is not "this one's tricky, can someone take it?" It is a compact, structured package the human can act on immediately. Two elements are mandatory: the specific request the customer made, in concrete terms, and the policy boundary it exceeds, named precisely. Useful additions include what the agent already verified and any relevant account context, so the human does not re-interview the customer from scratch.
This mirrors the broader Domain 5 principle that handoffs and error reports should carry structured context for meaningful downstream action, and it connects to the structured handoff to human agents pattern from Domain 1. The difference between a good and a bad policy-gap escalation is almost entirely in this payload. With it, a human approves or declines in seconds. Without it, the customer repeats their whole story to a second responder, and the escalation that was supposed to help instead adds friction.
Worked example
A returns agent meets a competitor price-match request that policy does not cover, and designs the escalation.
A customer writes: "Your competitor is selling the exact same blender for twenty percent less. Match their price and I'll buy from you." The agent calls its policy-lookup tool and finds a price-match policy that covers the store's own prices dropping within thirty days of purchase, but nothing about matching another retailer. The request is not forbidden; it is simply unaddressed. That silence is the policy gap.
A poorly designed agent reaches for goodwill: "Sure, I can match that for you this once." In one sentence it has committed the company to a discount no human approved, on terms invented on the spot. The correct agent instead recognises it has hit the edge of its authority. It tells the customer, honestly, that own-store price drops are covered but a competitor match is something it needs a colleague to decide, and it escalates.
The design payload is what makes the escalation worth anything. The agent hands the human a structured note: the customer requests a competitor price match of twenty percent on a specific blender SKU; the documented policy covers only own-store price drops within thirty days, so this request exceeds the policy boundary; the customer is ready to purchase if approved. The human reads three lines, makes a call, and replies, no re-interviewing required. The agent recognised the gap and shaped the handoff, which is the whole of this knowledge point applied end to end.
It is worth contrasting this with what a careless agent leaves on the table. Had it simply tagged the conversation "needs approval" and dropped it into a queue, the reviewer would open a cold transcript, scroll to reconstruct what was asked, look up the policy themselves, and quite possibly message the customer to confirm details the agent already had in hand. The same decision that took ten seconds with a structured payload now takes several minutes and an extra round-trip with the customer. The agent's recognition of the gap was correct in both versions; only the second one wasted it. That gap between a good and a bad handoff is entirely a design choice, and it is the choice this knowledge point is asking you to make well.
Policy gap versus a forbidden request
A subtlety worth getting straight is that a policy gap is not the same as a request policy explicitly forbids, and the two call for different responses. When policy clearly prohibits something, say, sharing another customer's details, the agent does not escalate; it simply declines and, where appropriate, explains why. There is no decision for a human to make, because the rule already made it. Escalating a plainly forbidden request just wastes a human's time on a foregone conclusion.
A gap is the genuinely undecided middle: policy neither grants the request nor refuses it. The competitor price match, the shipping refund on a late order, the goodwill credit for an outage. These are not prohibited, they are unaddressed. That undecidedness is precisely what makes them a human's call rather than the agent's. So the agent's first job after a policy lookup is to classify the result into one of three buckets: permitted (act), forbidden (decline and explain), or gap (escalate with context). Mislabelling a gap as forbidden frustrates a customer whose request might well have been approved; mislabelling it as permitted is the unauthorised-commitment failure.
Getting this classification right is most of the battle. Many exam distractors are built by collapsing the three buckets into two, treating every uncovered request as automatically refusable, or every reasonable-sounding one as automatically grantable. The disciplined agent keeps all three buckets distinct and routes a true gap to the only party with authority to fill it.
A checklist for the handoff payload
Since this knowledge point is pitched at the apply level, it helps to carry a concrete template for what a policy-gap escalation should contain, rather than a vague sense that context is good. A strong payload answers four questions a human reviewer will otherwise have to ask. What, specifically, did the customer request, in concrete terms and amounts? Which documented policy did the agent consult, and what does it actually cover? Where exactly does the request fall outside that coverage, the precise boundary it exceeds? And what has the agent already verified, such as the customer's identity and the relevant account state?
With those four elements present, the human inherits a decision rather than an investigation. They can read the note, weigh the request against the spirit of the policy, and respond in seconds, approve, decline, or counter, without re-contacting the customer. The agent has done everything short of the one thing it lacks authority to do. Compare that to a bare "this needs a human", which forces the reviewer to reconstruct the whole situation from a cold transcript and turns a thirty-second decision into a ten-minute one.
The same structured-context instinct runs through the rest of Domain 5, from error propagation to human review workflows: downstream actors act well only when they receive what they need to act. A policy-gap handoff is simply that principle applied to the boundary of the agent's authority. Recognise the gap, classify it correctly, and package the four elements. That is the knowledge point, applied from detection to delivery.
How this knowledge point is tested
Because the Bloom level is apply, the exam puts you in front of an out-of-policy request and asks how the agent should handle it, or what the escalation should contain. The distractors reward over-helpfulness: approve a sensible-sounding exception, promise the customer it will "probably be fine", or escalate but with a vague, contextless note. Each is a recognisable anti-pattern, inventing policy, making an unauthorised commitment, or designing a useless handoff.
The correct answer always refuses to fabricate policy and escalates with structured context: the request and the boundary it exceeds. Hold both halves together. Recognising the gap without designing the handoff leaves the human stranded; designing a handoff for a request the agent should simply have actioned within policy is over-escalation. Applied well, policy-gap escalation keeps the agent honest about its authority and makes the human's decision fast.
Misconception
If a request is reasonable and the customer is polite, the agent can grant a small one-time exception to a policy to keep them happy.
What's actually true
Misconception
Recognising a policy gap is enough; the agent can simply tell a human 'this one needs your help' and move on.
What's actually true
A customer asks an AI returns agent to refund shipping costs on a late delivery. The documented policy covers product refunds but is silent on shipping refunds. How should the agent be designed to respond?
People also ask
What is a policy gap?
Why can an AI agent not just make a sensible exception?
What context should a policy-gap escalation include?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
Human-in-the-Loop (HITL) for AI Agents: Patterns and Best Practices
Why watch: Covers designing escalation and approval flows for actions an agent is not authorised to take, directly mapping to building a handoff when a request falls outside documented policy.
More videos for this concept
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.