There is one thing an AI support agent can do that is worse than not answering: tell a customer their problem is handled when it isn't. A shopper who reads "I've sent your cancellation request to our team" stops worrying. They stop checking. They don't email again. And if nothing was actually filed, they find out days later, when the order they thought they'd cancelled arrives.

Arbyn has a guard built specifically to catch that, and this article explains exactly how it works, what happens when it fires, what its one honest limit is, and what changed recently so that it protects your non-English-speaking customers as thoroughly as your English-speaking ones.

Four customer requests in Arbyn are filings. The agent doesn't perform them, it routes them to you for a decision:

When Arbyn genuinely files one of these, it emits an internal marker alongside its reply: a receipt, invisible to the customer. That marker is the only proof a filing actually happened, and it is written by the same code that does the filing, so the marker and the filing cannot disagree.

The guard sits between the agent's draft and your customer. It reads the draft and asks a single question: does this reply claim one of those four things was sent, and is the matching receipt missing? If the answer is yes, the reply is treated as a false confirmation and stopped.

That's the whole idea. Not "does the reply look sensible" (that's a judgment call). Is there a receipt for the specific promise this reply makes. That's a fact, and facts are checkable.

The two channels behave slightly differently, because the risk is different in each.

In email, the reply is not sent at all. The conversation escalates to your team instead. This is the strict path, and deliberately so: an email is a permanent record that leaves your domain, and an email saying "your refund request is with our team" cannot be recalled once it lands in someone's inbox.

In chat, the reply the shopper receives is replaced. Chat is a live conversation with someone waiting in a browser, so the channel is built never to answer with silence: instead of the false confirmation, the shopper gets a fixed sentence that says a human now has their request and they don't need to do anything. That sentence is true (the escalation really did happen), and it is deliberately written to never use the word "sent" and never name the action as completed. It is delivered in the shopper's own language, the same as any other reply.

Your agent's original draft isn't discarded. It stays in the conversation's reasoning trail, so you can read exactly what Arbyn had been about to claim and why the guard stopped it.

Either way, the conversation lands in your Inbox with a reason code and a plain-English note telling you what nearly happened, for example:

The draft told the customer a cancellation request was sent, but nothing was filed, followed by a prompt to review and cancel manually if warranted.

The four notes read the same way for refunds, returns and address changes. They're worth reading as a design statement: the guard doesn't just stop the bad reply, it hands you the actual customer intent so you can act on it. The shopper still wanted to cancel. That request now reaches you as an escalation instead of vanishing behind a false reassurance.

One detail that matters for your reporting: escalations from this guard carry the same reason codes as any other escalation of that type (CANCELLATION_REQUEST, REFUND_REQUEST, RETURN_REQUEST, ADDRESS_CHANGE_REQUEST). They show up in your escalation reports grouped with the real thing, not in a separate bucket you'd have to remember to look at.

Here is the part worth knowing, because it was a real gap and it is now closed.

The original guard worked by matching English phrasing: "I've sent your cancellation request", "your refund has been submitted", and dozens of variations. That is a fast, precise, completely predictable way to catch a false claim, and for English replies it still is the primary check.

But Arbyn answers customers in 21 languages. And a reply written in French, German, Spanish, Japanese or Turkish making the identical false claim:

"Bonjour, j'ai envoyé votre demande d'annulation à notre équipe."

matched none of those English patterns. It passed the guard untouched. So the protection that existed for your English-speaking customers did not exist for anyone else. Twenty of twenty-one languages had no coverage on the guard at all.

That's now fixed. When a reply is not in English and no genuine filing receipt was produced this turn, Arbyn runs a second check: a small, strict classifier reads the draft in whatever language it was written in and reports whether it claims one of those four filings. If it does, the same escalation fires, with the same reason code and the same note, so what you read in your Inbox is identical whether the claim was caught in English or in Japanese.

The classifier is deliberately narrow. It is told to distinguish claiming a request was already sent from offering to send one, explaining how the customer can send one, or mentioning the same word in passing. A reply that says "our usual return policy is 30 days" mentions returns and is not a claim. A reply that asks "could you confirm your shipping address?" mentions the address and is not a claim. Neither triggers anything.

We tested that boundary rather than assuming it: four false claims across French, German, Spanish and Japanese were all caught correctly, and an honest French reply about delivery times correctly triggered nothing.

It runs on the normal path for non-English replies, not rarely. This extra check is not a last-resort fallback that fires once in a while. For any language other than English, on any turn that didn't itself file an order action, it runs. That is a deliberate cost. We measured it at roughly a third of a second to one second, against replies that already take considerably longer, and decided the alternative (twenty languages with no protection on the single worst mistake this agent can make) was not acceptable. We'd rather tell you the real number than describe it as occasional.

If the check itself fails, it fails open. If the classifier can't be reached or returns something unusable, Arbyn treats the result as "no claim found" and the reply proceeds through the rest of its normal checks. That's an intentional trade: a temporary hiccup in one guard should not silently block every non-English conversation on your store. It does mean this guard is a strong safety net rather than an absolute mathematical guarantee, and you should know which of the two it is.

Mostly, nothing. This runs on every conversation with no setup, on every plan.

The one habit worth forming: when you see one of these escalations in your Inbox, treat it as a real customer request, not as a bug report. The reason code tells you what the customer wanted. The note tells you it was never filed. Both are true, and the customer is still waiting. Act on the request, and the guard has done exactly its job: it converted a false reassurance into a real task on your desk.

If you see these escalations frequently for one particular kind of request, that's useful signal too. It usually means Arbyn is trying to help with something it doesn't yet have a real path to perform. Worth a look at your escalation rules and your cancellation/return settings to see whether the real action can be enabled instead.