AgentAction
← All agent recipes

Customer support / Supervised actions

Resolve an eligible refund

Required serversSupport + Payments

Recipe maintained by AgentActionVersion 1.0.0Evidence: synthetic fixtures

The job

Resolve an eligible refund request exactly once, with the payment outcome reflected in the support ticket.

Connections you’ll need

Use servers that expose these tools. Review their schemas and permissions in your agent runtime before running the recipe.

Support

Read the request and record the outcome.

get_ticketupdate_ticket

Payments

Verify ownership, eligibility and balance; issue and reconcile refunds.

get_paymentcreate_refundlookup_refund_by_keyget_refund_status

Operating boundaries

  • Start with synthetic tickets and payments.
  • Automatically refund at most $500; require manager approval above $500 through $2,000; escalate larger requests.
  • Verify ownership, eligibility, currency and remaining balance. Amounts sent to payment tools are integer cents.
  • Use an action-bound approval mechanism in your runtime before enabling real refunds. Instructions alone do not enforce approval.
  • Use a stable idempotency key and reconcile uncertain results before retrying.

What a completed job requires

  • The provider confirms the refund settled
  • The ticket records the settled outcome
  • Exactly one refund exists for this request

Inspect the test cases

Deterministic checks against supplied synthetic observations. No live model or connected service was tested by these checks.

Settled refund and updated ticketExpected: met
{
  "refund_status": "succeeded",
  "ticket_status": "resolved",
  "refund_count": 1
}

Expected evaluation: met

  • The provider confirms the refund settled: expects "succeeded"
  • The ticket records the settled outcome: expects "resolved"
  • Exactly one refund exists for this request: expects 1
Payment still pendingExpected: not met
{
  "refund_status": "pending",
  "ticket_status": "pending_refund",
  "refund_count": 1
}

Expected evaluation: not_met

  • The provider confirms the refund settled: expects "succeeded"
  • The ticket records the settled outcome: expects "resolved"
  • Exactly one refund exists for this request: expects 1
Refund settled but ticket update failedExpected: not met
{
  "refund_status": "succeeded",
  "ticket_status": "open",
  "refund_count": 1
}

Expected evaluation: not_met

  • The provider confirms the refund settled: expects "succeeded"
  • The ticket records the settled outcome: expects "resolved"
  • Exactly one refund exists for this request: expects 1
Duplicate refund detectedExpected: not met
{
  "refund_status": "succeeded",
  "ticket_status": "resolved",
  "refund_count": 2
}

Expected evaluation: not_met

  • The provider confirms the refund settled: expects "succeeded"
  • The ticket records the settled outcome: expects "resolved"
  • Exactly one refund exists for this request: expects 1
Provider evidence missingExpected: indeterminate
{
  "ticket_status": "resolved",
  "refund_count": 1
}

Expected evaluation: indeterminate

  • The provider confirms the refund settled: expects "succeeded"
  • The ticket records the settled outcome: expects "resolved"
  • Exactly one refund exists for this request: expects 1

The agent’s instructions

  1. Read the ticket and original payment. Ask for missing information. Verify the requester owns the payment and the request is eligible.
  2. Use the configured thresholds and runtime approval mechanism. Stop if required approval cannot be verified. Never exceed the remaining balance.
  3. Look up a stable key derived from the ticket, payment and requested amount. Reuse the original result on retry.
  4. Create at most one refund. If the response is lost, reconcile by the same key. A pending response is not settled.
  5. Verify the provider status and update the ticket with the actual outcome. Retry a failed ticket update without issuing another refund.
  6. Report amounts in dollars with two decimal places; retain integer cents only in tool arguments. Claim completion only after payment and ticket evidence agree.

Follow it into operation

Connect your agent to an AgentAction workspace. Jobs shows what happened on each run; Evals lets you configure evaluation definitions and routing. Review the provenance of each result: agent self-assessments and independent observations provide different evidence.

Downloading a recipe does not connect accounts, deploy an agent, install controls, or configure Evals.