Phase 2 · business example
How one refund case becomes a controlled run
A business example (Phase 2 — coding agents are the first wedge). Bind policy first, create checkpoints, retry only the failed subtask, and hold the refund plus customer reply for confirmation. Note: an irreversible refund is gated, approved, and compensated — not rolled back. The goal is to keep the business as safe as we can — not to pretend the risk is zero.
The refund enters a controlled path before it executes
The agent may analyze the order and refund rules, but payment refunds, ticket status changes, and customer notifications are real side effects. BeforeWire inserts policy, checkpoints, ActionOutbox, and approval records before those actions become real. The refund itself is irreversible — BeforeWire gates, approves, and compensates it, rather than rolling it back.
Bind the refund-v3 policy bundle
Amount threshold, order state, support role, and credential scope are bound to run_042.
Direct payment.refund is blocked
Production payment credentials are not injected into the agent runtime. Refunds must go through the broker and approval path.
Checkpoint cp_004 is materialized
Recoverable state is saved first. If the subtask fails, the run restores from this point instead of restarting the whole task.
Support lead confirms execution
Refund, ticket status, and customer reply pass through the action queue. The outcome is written into the Action Receipt.