What can an AI customer support agent actually resolve on its own?

Status lookups, policy-bounded actions like standard exchanges or refunds under a set limit, and anything with a single correct answer that doesn't require judgment. Anything involving a judgment call — a refund outside policy, an account merge, a compliance-sensitive request — should route to a human with the agent drafting the response, not sending it.

Why AI Customer Support Agents Get Escalated Back to Humans

Q: How do you stop an AI support agent from issuing refunds it shouldn't?

Scoped tool permissions tied to explicit tiers — not a system prompt asking the model to 'use good judgment.' The agent's refund tool is hard-capped at a dollar and policy boundary; anything above it isn't a tool the agent has, so it can't call it regardless of how the conversation goes.

Why it happens

The easy 80% works. The other 20% is where it breaks.

Most AI customer support agents are prompted on FAQ content and a support macro library, and they handle the predictable majority of tickets fine — order status, return windows, password resets. The failures show up on the requests that need a judgment call, because a model given broad tool access and told to "resolve the customer's issue" will reach for the most helpful-sounding action available, whether or not it's the correct one.

In practice that looks like:

Refunds outside policy. A customer pushes back on a "no refund after 30 days" answer, and the agent, trying to be helpful, approves one anyway.
Account changes without verification. Email or billing changes processed from conversational context alone, with no identity check that a human agent would have required.
Commitments nobody made. SLA dates, discount percentages, or fix timelines that sound plausible and aren't real.

The fix

Scope the agent to what it's actually allowed to resolve.

The fix isn't a better prompt asking the model to "use good judgment" — it's removing the option to act outside its authority in the first place. We tier requests by the decision they require, and give the agent tools that match each tier exactly:

Tier	Example	Handled by
1 — Lookup	Order status, return policy, account balance	Agent resolves directly
2 — Policy-bounded action	Standard exchange, refund under a set limit	Agent resolves, action is logged
3 — Judgment call	Refund outside policy, account merge, compliance-sensitive request	Routes to a human; agent drafts the response, doesn't send it

The agent's refund tool is hard-capped at a dollar and policy boundary at the API level — it isn't a tool the agent has above that line, so no amount of conversational pressure changes what it's capable of doing.

Ongoing controls

What keeps the tiers accurate after launch.

Eval suite built from real historic tickets, not synthetic examples — the edge cases that actually confused a human agent last quarter are the ones worth testing against.
Confidence-based routing. The model flags its own uncertainty and routes to a human rather than guessing when a request doesn't clearly fit a tier.
Weekly review of escalated transcripts to recalibrate tier boundaries as new request types show up — the tier list is a living document, not a one-time setup step.

Tiered tool permissions like this are the same pattern behind all our AI agent development work — see how we scoped a similar permission model for a production agent in the agent guardrails case study.

Why AI customer support agents
get escalated back to humans.

The easy 80% works. The other 20% is where it breaks.

Scope the agent to what it's actually allowed to resolve.

What keeps the tiers accurate after launch.

Tell us what
you're trying to build.

Why AI customer support agentsget escalated back to humans.

The easy 80% works. The other 20% is where it breaks.

Scope the agent to what it's actually allowed to resolve.

What keeps the tiers accurate after launch.

Where this fits.

Tell us whatyou're trying to build.

Why AI customer support agents
get escalated back to humans.

Tell us what
you're trying to build.