The refund screen froze. Did the money move?

A missing confirmation is not a failed payment. Check the refund already submitted before deciding what to tell the customer.

The payment record now confirms that the original refund succeeded for the correct order and amount. The customer has not received an email and asks you to send the refund again. You have the receipt and the payment service's expected bank arrival window.

What does the customer need now?

• Keep waiting without replying until an email arrives
  Why this choice?

  You now know the refund succeeded, so you can help without moving more money. Waiting silently leaves the customer unsure about an outcome you can explain.

• Send the receipt through the shop's approved customer channel
  Why this choice?

  Confirm the original refund and share its reference and expected bank arrival window with this customer. Missing email does not call for another refund. If the money does not arrive within that window, ask the payments team to trace it.

• Create another refund so a fresh email gets sent
  Why this choice?

  The original refund succeeded. Creating another would move money twice to solve an email problem. Use the existing receipt instead.

Check what happened to the money, not just what happened to the screen.

What would you want to see before telling someone their refund had failed?

Transaction state is the recorded status of a payment. A screen can lose its reply while the payment succeeds. Software needs a reliable way to check the original payment; an AI guess cannot replace that record.

Separate conversation, authorization and transaction state before deciding whether an agent may execute a refund.

Transactions and customer operations · 9 minutes

The problem

Synthetic practice scenario: all quantities and evaluation outcomes are illustrative, not reported research. A retailer wants to reduce refund handling effort while preserving customer consent, refund policy and an auditable payment ledger.

Your initial decision

What authority should the pilot agent receive?

• Staff must approve each refund under the current policy; conversational requests do not bypass that requirement.
• The legacy refund adapter has no stable operation identifier or reliable status reconciliation.
• A payment can complete while its response is lost; duplicate refunds create financial and customer harm.
• The agent may read only records for the authenticated customer and must not retain payment credentials in context.

Compare the alternatives

• Build a guarded transaction gateway before any write pilot

  Durable operation IDs, approval binding and reconciliation could support later execution, but implementation and failure testing delay that release.

• Automate console entry with staff confirmation

  An isolated UI agent can enter an approved refund and stop after submission, but screen changes and ambiguous receipts complicate verification and recovery.

• Draft proposals for staff console execution

  The model gathers eligibility evidence while staff use the established payment console; manual re-entry remains a cost and a potential error, so staff compare the proposal with the confirmation.

Mechanism, trade-offs, and evidence

• Separate interpreting the request from authorizing the amount and executing the payment; these are different trust boundaries.
• An MCP tool schema can standardize access but does not fix transaction semantics or grant refund authority.
• The immediate safe baseline is a proposal plus established staff execution, while engineering repairs the write path.
• Version rollback cannot undo money already moved; recovery needs reconciliation and an authorized financial process.

Reconsider after a change

The backend now has durable operation records and a tested reconciliation path; a narrowly scoped execution pilot is proposed, still requiring staff approval.

Does the new evidence justify any agent-initiated execution?

• In an illustrative independent suite of 240 sandbox transactions, duplicate delivery, concurrent requests and lost responses produced no duplicate ledger effects; this is finite test evidence, not a guarantee.
• Approval is server-bound to the customer, order, amount and expiry, and every write rechecks current policy.
• The synthetic pilot permits refunds up to $25 after staff approval, with a daily cap of 10 and an immediate disable switch.
• Unknown outcomes enter reconciliation without a new operation ID; exceptions and expired approvals return to staff.

Compare the alternatives

• Canary the guarded refund API

  The agent submits an approved proposal through scoped credentials and durable idempotency controls, reducing console re-entry while adding operational monitoring.

• Keep staff execution until operational coverage is available

  Manual execution preserves the established recovery workflow but forgoes the demonstrated reduction in re-entry work.

• Keep the supervised console automation path

  Reusing a UI adapter avoids migrating its callers and retains staff confirmation, but duplicates integration work now that the API exposes authoritative operation status.

Mechanism, trade-offs, and evidence

• The recommendation changes because the missing engineering controls now exist and have task-specific evidence, not because a model became newer.
• Check provider-specific idempotency retention and error semantics rather than assuming the same key prevents duplicates forever.
• A scoped canary limits exposure while measuring correct refunds, review burden and unresolved outcomes against staff execution.
• If a refund is wrong, disabling the agent prevents future actions but does not reverse the payment; use the authorized remediation procedure.

Related technical concepts

Follow-up lessons retain their existing sign-in and plan requirements.

• transactional agent workflows
• human in the loop patterns
• agent identity delegation
• tool use function calling
• agentic workflow control
• memory state
• agent integration
• agent security
• human agent delegation

Technical sources

• Idempotent requests — Stripe

  Documents stable retry keys, stored outcomes and retention limits; these provider-specific semantics are not a universal exactly-once guarantee.

• MCP Security Best Practices — Model Context Protocol

  Describes consent and authorization boundaries for tool integrations; adopting a protocol does not grant access to customer data or actions.

• Demystifying evals for AI agents — Anthropic Engineering

  Explains tasks, graders, repeated trials and outcome evaluation for agents; use task-specific tests rather than importing reported scores.

Explore the technical decision