A support team spends a few weeks teaching an AI agent to handle refunds before it ever talks to a live customer. The first case they run it through is the easiest one they can find.

I was charged twice this month. Please refund one of the charges.

The agent reads the ticket, pulls the billing record, and finds two identical charges four minutes apart on the same card. It checks the refund policy: exact match, no exception required. The pattern is one the team has seen thousands of times before. The agent refunds the charge and tells the customer it's done. No one on the support team even sees the ticket.

The team's first question was simple: can the agent handle this reliably? Watching it work, the answer is yes. Confidence is high, the policy match is exact, and the pattern repeats often enough that a human in this particular loop wouldn't catch anything the agent doesn't already catch. So they don't put one there.

But a second question was sitting behind the first one, and passing the test didn't answer it. Now that the agent can do this, what else should it be trusted to decide on its own?

The next ticket that comes in looks almost the same on the surface.

I've been a customer for 8 years. I know your policy says no refunds after 30 days, but I'd like an exception.

The refund amount here might be smaller than the first one. The agent is arguably more confident about this customer's history than it was about the duplicate charge. What's different isn't how well the agent understands the situation — it's what kind of decision this actually is.

The first ticket asked the agent to apply a rule. This one asks it to decide whether the rule should bend. Grant the exception, and the company hasn't just resolved one ticket. It's set a precedent the next 8-year customer, and the one after that, will eventually test.

This is the actual product decision hiding inside the ticket: not whether the agent understands the situation, but whether the product is willing to delegate this particular kind of call to it. Those are different questions, and the second one doesn't get easier just because the first one keeps getting answered yes.

The agent can review this case just as capably as it reviewed the first one. It can weigh the history and land on an answer it's confident in. What it doesn't have is the authority to make that answer final — because making it final isn't really a judgment about this one customer. It's a judgment about every customer like them going forward, and that's not a call the product has agreed to hand it.

For a while, capability did most of this filtering without anyone having to think about it. An agent that couldn't reliably read an invoice was never going to be trusted with a policy exception — it would fail the easy question before the harder one ever came up. This agent didn't fail. It got the duplicate charge right, and it reasons clearly about the exception too. Once capability stops ruling decisions out on its own, whatever's left has to be decided on its own terms. That's authority: not can it get this right, but is this a call we've agreed it gets to make.

So far every case has had a fairly clean answer once you check the policy and the billing history. The next two don't.

Take two refund requests that land the same week, both involving real money.

The first is ₹85,000, on an account that's been active for 6 years, matching a billing error the finance team had already flagged internally. Clean history, exact match, nothing unusual about it. The agent checks it against the same kind of pattern that let the ₹500 duplicate charge through earlier, and lets it go. The number is large. The decision isn't hard.

The second is smaller.

This charge doesn't look right - please refund ₹2,000 immediately.

The account is 2 days old. There have been three chargebacks on it in the last month. Nothing about the request matches a documented policy. This is the one that stops.

A flat threshold — anything under some number executes automatically — would have gotten both of these backwards: letting the large one through only by luck, and stalling the small one only because of its size.

What the product is actually weighing isn't the number on the ticket. It's how exposed the company is if the call is wrong, whether the action can be undone, how ambiguous the policy is, whether saying yes here creates an expectation somewhere else, how much this looks like fraud, and what it costs to put a human in the loop for something this uncertain versus something this routine.

None of that tracks cleanly with the amount. The ₹85,000 case carries almost none of that risk despite its size. The ₹2,000 case carries most of it despite being smaller than the first refund the agent ever handled alone. Size was never the variable doing the work.

Once you see these cases side by side, the usual way people talk about agent autonomy stops making sense. Teams describe it as a dial - the agent is 20% autonomous today, maybe 60% next quarter. But this agent doesn't have one autonomy level. It has a different authority for the duplicate charge than for the exception, and a different one again for the ₹2,000 case than for the ₹85,000 one. That isn't inconsistency. It's the product doing its job.

Building a list like that isn't really a technical exercise. For each action, someone had to ask what happens if this goes wrong, how bad that would actually be, and who ends up cleaning it up. Those are ordinary product questions, the same ones a team asks about any feature — they just don't usually get asked about a decision the product is about to hand to a model instead of a person.

Run the ₹2,000 case through two different configurations of the same agent, and you can see exactly where the risk was always sitting. Give it authority to execute anything under a flat number — a completely reasonable-sounding rule on paper — and it clears this one instantly, because ₹2,000 falls comfortably under whatever threshold someone set.

Give it the authority the team actually built, where a refund gets checked against account signals rather than a number, and the same request stops for review. Same model. Same customer. Same request. What changed was never the AI. It was which decision the product had agreed to hand it.

The same logic holds outside support. A coding agent can technically open and merge both of these: a one-line fix to a typo in a comment, and a change to how payments get calculated. The capability is identical — it can write and submit either pull request with equal confidence, run the same tests, pass the same checks. The authority shouldn't be. What's different is blast radius: one mistake is a comment nobody reads, the other is a production incident. Blast radius was never a property of what the model can do. It's a property of what happens if it's wrong.

Get the boundary wrong in one direction and the agent turns into a faster way to generate approval requests — every refund, every account change lands in a queue for someone to click through, and the bottleneck the team was trying to remove just gets a faster feeder, spread across more tickets instead of fewer.

Get it wrong in the other direction and the agent runs correctly for a long stretch, then makes one call — a fraud-flagged refund waved through, an exception granted where it shouldn't have been — that costs more than the thousands of correct calls saved. The fix that follows is rarely a better model. It's usually the check that was missing the whole time. Neither failure is really about capability. Both come down to where the authority line got drawn, or whether anyone drew it on purpose.

Deciding where that line sits isn't a call any single function should make alone. Finance has a real stake in how much exposure the agent can carry unsupervised. Support has a stake in which customer-facing exceptions it can grant. Whoever handles fraud has a stake in what counts as suspicious enough to stop for. None of them need to write the prompts or tune the model. They need a seat at the table when the boundary gets drawn. The product's job isn't to hold all of that expertise itself — it's to bring those perspectives together and turn them into an actual, working boundary: this decision, this authority, this reason.

The question the team kept asking was whether the agent was capable enough to act. The more capable it got, the less that question actually told them.

What was left, every time, was a narrower one: what were they willing to let it decide?

/a