From support ticket to refund: anatomy of one AI action

A customer messages: "my order arrived damaged, can I get a refund?" That single sentence sets off a short chain of steps most people never see, and walking through that chain end to end is the clearest way we've found to explain what an AI Agent's write actions actually look like underneath a simple-sounding request.

We picked this specific ticket because it's genuinely one of the more common ones across our deployments, and because every step in its resolution generalizes to other write actions we support.

The message

The sentence itself carries two pieces of information the Agent has to extract correctly before doing anything else: what happened (arrived damaged) and what's being requested (a refund, as opposed to a replacement, which is a meaningfully different resolution path with different eligibility rules). Getting this classification right at the start matters more than it might seem, because every subsequent step assumes the correct branch was picked.

Checking eligibility

First, the Agent checks the order against the refund policy in the Knowledge Base to confirm eligibility — a damaged-item claim inside the standard return window is treated differently from the same claim made well outside it, and the policy engine, not the model's judgment, is what actually enforces that distinction. Then it calls the order API to pull the actual order record and verify the purchase date and item, cross-referencing the claim against what was actually purchased and when, rather than trusting the customer's own account of the timeline alone.

This two-step check — policy first, then order-record verification — exists specifically because either one alone is insufficient. A policy check without the order record can be gamed by a customer misremembering or misstating a purchase date. An order-record check without policy can correctly confirm a purchase happened without ever actually validating whether it's eligible for the specific resolution being requested.

Issuing the refund

If everything checks out, it calls the refund action directly — the same endpoint a support agent would use — and logs the reasoning, sources, and API call in the conversation's trace so anyone reviewing it later can see exactly why the refund went through. That trace is doing real work beyond compliance box-checking: it's what turns "the Agent issued a refund" from an opaque outcome into a reviewable decision, with the specific policy clause and order data that justified it attached.

The refund call itself goes through the same idempotency and confirmation handling any write action needs — a retry on a flaky network call doesn't turn into a second refund, and the customer isn't told the refund succeeded until the system has actually confirmed it, not just accepted the request without erroring.

When it stops short

If anything is ambiguous, like a return window that expired three days ago, the Agent stops short of issuing the refund and hands the case to a human with the full context already attached — the order record, the policy clause that made the case borderline, and the reasoning trace up to the point where it decided this needed a person's judgment rather than a rule.

That handoff is deliberately designed to save the human time, not just to punt the decision. A human picking up this case doesn't start from the customer's original message; they start from a case that's already been fact-checked, with only the actual judgment call — should we make an exception here — left to decide.

Common questions

What happens if the order API is down when the customer messages? The Agent tells the customer it's still checking rather than guessing at an answer, and retries the lookup before giving up and escalating — the trace records this too, so a reviewer can see it wasn't a silent failure, it was a system outage handled gracefully.

Does the Agent ever issue a refund without a human ever reviewing it, even after the fact? Most eligible, in-policy refunds go through without a synchronous human review, but every action remains reviewable after the fact through the trace — nothing is invisible, even when nothing required a human to intervene in the moment.

Watching this play out on a harder case

The straightforward version of this ticket — a clearly damaged item, well within the return window, a customer account with no unusual history — resolves cleanly through the steps described above in well under a minute. The harder version, worth walking through separately, is the one where two of those conditions hold but the third doesn't.

Take a case where the item is genuinely damaged and the return window is fine, but the account has an unusual pattern: three damage claims in the past two months, each on a different order. None of those three claims individually looked suspicious enough to deny on its own, and denying a legitimate damage claim just because of an unlucky pattern would itself be a bad outcome for a genuine customer. But three in two months is enough of a pattern that treating this fourth claim identically to the first, without any additional scrutiny, would be its own kind of mistake.

This is exactly the kind of case the policy engine is built to catch and route correctly rather than resolve automatically. The eligibility check still passes — the claim is legitimate on its face, the order and timing check out — but a separate pattern-detection rule, checking claim frequency across a rolling window rather than eligibility on a single order, flags the account for review before the refund goes through automatically.

The Agent's response to the customer in this specific case matters as much as the underlying logic. It doesn't accuse the customer of anything or refuse the claim outright — both of which would be inappropriate given that nothing has actually been proven wrong here. It tells them the claim is being reviewed and that someone will follow up shortly, which is true, and hands the case to a human with the full pattern already surfaced: here are the three prior claims, here's this one, here's why it's flagged, make the call.

The human reviewing this case, in the instance we're describing, ultimately approved the fourth claim too — the pattern turned out to have an innocent explanation, a run of bad luck with a specific shipping carrier that had since been switched. But the review happening at all, rather than either an automatic approval or an automatic denial, is what let that judgment call actually get made by someone with the full picture, instead of a rule picking one of two blunt outcomes on its own.

This is the version of "anatomy of one AI action" that doesn't show up in a simple happy-path walkthrough, and it's the version that actually determines whether a team trusts the system with real money at real scale. The straightforward case proves the mechanism works. The harder case proves the mechanism knows its own limits.

We track cases like this specifically — not to celebrate that the system caught something, but to periodically ask whether the specific pattern-detection thresholds are still calibrated well, since a threshold that flags too aggressively creates unnecessary friction for genuine repeat-damage customers, and one that flags too rarely misses exactly the kind of pattern it exists to catch.

Common questions

How many separate systems does a typical write action like this actually touch, end to end? For the refund example described here, at minimum three: the Knowledge Base for policy, the order API for verification, and the payment or refund API for execution — plus a pattern-detection check in the harder cases described above, which makes four.

What happens if the policy check and the order-record check disagree — for instance, the policy says eligible but the order record shows something inconsistent with the claim? The Agent treats any inconsistency between what a customer claims and what the order record actually shows as a reason to stop and escalate rather than resolve the disagreement itself, since that kind of mismatch is exactly the sort of thing that benefits from a human's judgment.

Does every write action get the same level of trace detail, or does it vary by how risky the action is? Trace detail is consistent across action types, but the review process built on top of that trace is risk-weighted — higher-risk action types get sampled for review more heavily, even though every individual action, regardless of risk level, produces the same complete trace.

How do you decide which actions are eligible for full automation versus requiring a human, beyond the specific pattern-detection example described above? It's a combination of dollar risk, reversibility, and how well-documented the relevant policy is — an action that's low-dollar, easily reversible, and covered by clear, current documentation is the easiest case for full automation, and any one of those three factors being weak is reason to keep a human in the loop longer.

Is the pattern-detection check described above specific to damage claims, or does it generalize to other action types? The underlying mechanism generalizes — checking claim or request frequency across a rolling window rather than evaluating each request in isolation — and we apply a version of it to several other action types with a similar shape, like repeated address-change requests or repeated discount-code usage from the same account.

How do you decide where the line is between "clearly eligible" and "needs a human"? The line is set by the policy engine's rules, tuned by watching what a human reviewer actually overturns versus confirms over time — a rule that a human agrees with every time it fires can usually be automated with more confidence than one where human judgment regularly disagrees with the rule as written.

Can a customer dispute a refund decision the Agent already made? Yes, and this is exactly what the reasoning trace exists for — a disputed decision gets reviewed against the same trace a human would have used to make the call in the first place, rather than requiring anyone to reconstruct what happened from scratch.

Zooming back out from both the simple and the harder version of this ticket, what we'd want a reader to take away isn't a specific number of steps or a specific policy detail — it's the general shape: every write action worth trusting an Agent with should be decomposable into an eligibility check, a verification against ground truth, an execution step with proper idempotency handling, and an explicit boundary for when it stops and asks for a human instead. Different action types will fill in that shape differently, but the shape itself is what we'd recommend any team building something similar start from.

That shape is also, not coincidentally, close to the six-stage planning breakdown we've described in more depth elsewhere in this series — classify, check authority, gather context, propose, validate, execute — applied here to one concrete action rather than described abstractly. Seeing the abstract version and the concrete version side by side is, in our experience, what actually makes the abstract version click for a team building their first automated write action.

One last practical note for any team building a similar action from scratch: build the trace and the escalation handoff before optimizing for how many cases resolve automatically. Every team we've seen try to maximize the automated-resolution number first, and add proper tracing and handoff quality afterward as an afterthought, ended up needing to redo work that would have been straightforward to build correctly from the start — the same lesson the traceability piece elsewhere in this series describes in more depth, applied here to a single concrete action type.

None of the specific numbers or thresholds in this piece are meant to be copied directly into a different product's refund policy — they're meant to illustrate the shape of the decision, which every team implementing something similar will need to fill in with their own actual dollar limits, return windows, and risk tolerance, informed by their own history rather than borrowed wholesale from someone else's.