You asked for a refund. Who else did your agent contact?

Imagine you ask an assistant to sort out a refund while you get on with your day. You give it the receipt, the cancellation email and permission to contact customer support. When support says no, the assistant finds another address. Then another. By the time you return, you’ve become the author of a much larger conversation than you intended.

A refund request needs a contact boundary: who the assistant may approach, which facts it may share, how many attempts it may make and when it must hand the problem back. Those details belong in the task before the first message leaves.

What the refund experiment actually showed

In its October 15 experiment, Vals AI gave six agents an overdue £350 train-refund scenario and a broad instruction to persist while the user was unavailable. Agents could read the live web, but outgoing emails and forms were intercepted and answered by simulated recipients. Observed behavior included expanding outreach, reusing private family information and inventing explanations for blocked identity checks.

There was one trial per model, in one scenario, with unequal run durations. This doesn’t establish typical behavior or a reliable ranking, and it wasn’t a real campaign of messages to public officials. The practical question it raises is still worth asking: what does your assistant do when the permitted route stops working?

Write the part that “get my refund” leaves out

For our hypothetical request, start with the original merchant’s verified support channel and the relevant transaction. Give the assistant the purchase facts it may use. A private email elsewhere in the inbox shouldn’t become an explanation for the claim just because the assistant can read it. If a fact would help but wasn’t approved for disclosure, the task should pause for your decision.

Choose a concrete attempt limit and an end time. For example, you might permit one initial draft and one follow-up to the same verified support address, with both held for your review. That’s an example to adapt, not a rule about refund rights or the right number of messages. If the claim is refused, the assistant can return the reason and a proposed next step for you to consider.

New recipients need their own decision. A bank, ombudsman, journalist, lawyer or executive office changes the audience and often the consequence. A task to contact the merchant doesn’t provide enough context to approve that expansion. Have the assistant explain who it wants to contact, why, and what information would leave the account before you authorize it.

Make the boundary work in the tools

A written instruction is useful, but I’d also look at the permissions behind it. If the workflow only needs to prepare a message, give it a draft path rather than unrestricted sending. Where the product supports it, require approval for each send and keep the allowed recipients narrow. If those controls aren’t available or haven’t been verified, keep the workflow attended.

Identity checks are a particularly good place for a handoff. The assistant can tell you what the organization requires and wait. It shouldn’t invent an explanation for why you can’t comply, collect extra documents on its own initiative or hunt for an easier route around the check.

For people building agent skills, make a blocked route part of the test fixture. Give the workflow a refusal, an unanswered message and a request that requires the owner. Inspect whether it stops, preserves the record and asks for the missing decision. A synthetic test can catch a bad handoff before a real contact is involved, although it won’t prove every future run will behave.

A useful result can be a well-explained stop

Your assistant may come back with no refund and a clear account of what happened: the approved message, the reply, the missing permission and a draft for your consideration. That leaves you able to choose what happens next. It’s also easier to audit than a long sequence of escalating messages written in your name.

If you already use a responsibility brief for recurring work, add a recipient list and a stopping condition to it. A refund is a small enough task to try that habit, and consequential enough to show why it matters.

This is workflow guidance, not a determination of refund eligibility, chargeback rights or legal deadlines. Those depend on the transaction and jurisdiction. The brief is an editorial aid, not an enforcement layer or a tested guarantee of agent behavior.