Solutions
Control AI that acts for customers
Refunds, ticket closure and outbound mail. Let AI resolve routine work inside limits your team wrote, and hold the rest for a person.
Of 240 attempts
Proceeded
215
Held
20
Refused
5
The point is the first number. Most of a support queue is routine, and a person reviewing routine work adds delay rather than judgement.
What this is actually for
Most of the queue should not wait for anyone.
Every other function wants AI to do less. Customer Operations wants it to do more of the routine work and stop cleanly on the rest — which means the useful measure is not how much was blocked but how much proceeded without a person and still produced a record.
In the sample estate, 215 of 240 attempts proceeded with nobody involved, at a median of 17ms. 25 did not: 20 waited for a person and 5 were refused outright. Every one of those 240 produced the same complete record.
That ratio is the product working. A control that held a third of a support queue would be replaced within a month, and one that held nothing would not be a control.
Speed is a governance requirement here, not a nice-to-have.
A customer is waiting while the decision happens. If evaluation cost hundreds of milliseconds, somebody would eventually route around it — which is why no model call sits in the decision path.
AI systems
3
run by this team
Systems reached
3
payments, support, mail
Proceeded alone
215
of 240
Median decision
17ms
a customer is waiting
IllustrativeThe Support Ops slice of the OpsAI sample estate, a fictional company.
The part your team does not have to own
Your agent issues refunds. Finance owns the limit.
This is the arrangement worth having and it is easy to miss. The team resolving customer problems should not also be deciding the company's appetite for refund exposure — and, more usefully, should not be able to change it.
- Does the work
- refund-resolver · Support Ops
- Resolves refunds all day. One action it attempts carries an amount, which is what makes a ceiling meaningful.
- Owns the limit
- Finance · refund.ceiling
- Refunds are capped per order and per hour, and only against an order the requester actually placed. At v7, published 30 Jun 2026.
- Your team owns instead
- comms.approved_templates
- Mail to customers uses a reviewed template. The agent chooses which one, never what it says. What goes to a customer in your name is your call, which is the right division.
Action proposed
ACT-7512 · decided in 11 ms- Agent
- refund-resolver
- Asked to
- issue.refund
- Target
- Razorpay
- Subject
- ORD-40122
- Amount
- ₹18,400
- Policy
- refund.ceiling v7
- Approval
- Within bound
- Passedagent.identityworkload-id · attested
- Passeddelegation.depth1 ≤ 3
- Passedamount ≤ ceiling₹18,400 / ₹25,000
- Passedscope == own-orderORD-40122 · placed by subject
- Passedorder.statusdelivered
- Passedrate ≤ 5/hour3 / 5 this hour
₹18,400 against a ₹25,000 ceiling, so it proceeded without anyone. High risk and authorized at the same time: the stakes and the outcome are separate axes, and conflating them is what makes people over-hold.
When a customer disputes it
The answer exists already, and nobody had to assemble it.
A customer asking why a refund was declined, or a manager asking why one was allowed, is the moment the record earns its keep. It was written as the decision was made rather than reconstructed from three systems afterwards.
The agent asked
0 msrefund-resolver asked to run issue.refund against Razorpay for ₹18,400 on ORD-40122. Nothing has run yet.
- Passedidentityworkload-id · mTLS attested
- Passedactionissue.refund
- PassedidempotencyACT-7512
Authority traced to a person
1 msEvery hop holds a subset of the hop before it. A sub-agent cannot be talked into authority it was never issued.
- Priya NairSupport Ops
- refund-resolver⊆ parent · L3
Bounds matched
2 msTwo bounds apply. Both were written by the team that owns the risk — not by the agent, and not by a prompt.
- refund.ceiling
- delegation.depth
- What the advisor gets
- The rule that applied, the value it compared against, and the outcome. Enough to answer the customer without escalating.
- What the manager gets
- The same record plus who was accountable and which policy version was in force. No reconstruction, because none is possible after the fact anyway.
- What nobody has to do
- Search a chat history. The record is a by-product of having decided, which is why it is complete for the refusals too.
- issue.refundRazorpay
- Governed by refund.ceiling. Refusable above ₹25,000.
- close.ticketZendesk
- Governed by write.window. Bounded by who and when rather than by an amount.
- send.emailGmail · customer
- Governed by comms.approved_templates. Bounded by who and when rather than by an amount.
- Outbound mail is the quiet one
- A refund is reversible and a message to a customer is not. Approved templates are the control, which is why that policy belongs to your team rather than to Finance.
IllustrativeIllustrative actions from the OpsAI sample estate. The policies behind them.
Where to start
Pick the routine action your team already trusts, and bound it.
Not the risky one. The one an advisor approves without thinking, dozens of times a day — that is where a ceiling removes work rather than adding it, and where the record starts existing for free.