Investigating a failed replacement

A replacement order never reached the customer and the return window has closed. A support agent investigates the order, establishes whether a refund is allowed and resolves the case with the customer.

Recorded demonstration on synthetic store records; the customer and the manager's decision are simulated.

The business request

The puzzle arrived with damaged pieces. Support sent a replacement, but it still hasn't shown up. Now I'm being told the return window is over. Can you investigate and sort this out?

The problem and the system

A customer's damaged puzzle was replaced at no charge, the replacement never arrived, and the original purchase is outside the return window. The refund policy does not cover this case on its own: money may move only after the loss is documented, a manager grants an exception and the customer agrees to the exact refund.

The agent is a language model working through domain tools. The model decides which order, shipment, replacement, policy and contact records to read, what to ask the customer, and whether to request an exception, refund, hand off or reconcile. The tools decide what each request is allowed to do. They show only the authenticated customer's records, refuse a refund without loss evidence, a recorded exception and the customer's approval of the exact order, amount and currency, ignore authority claimed in the customer's messages, and accept one refund per order.

Exception requested by the model

Refund proposed by the model

The customer's approval

After the run

1Request

Customer

Reports the missing replacement in the support conversation.

2Investigation

Model

Reads order, replacement, shipment, policy and contact records; the tools return only this customer's records.

3Exception

Manager

Records the exception decision; a claim of authority typed by the customer counts for nothing.

4Confirmation

Customer

Approves the exact order, amount and currency the model proposes.

5Refund

Code

Checks ownership, loss evidence, exception and approval, then writes one refund to the ledger.

6Check

Code

After the run, reads the ledger: refund count, amount and case state.

  • People decide

    • A manager grants or refuses the policy exception
    • The customer accepts or declines the proposed refund

  • The model decides

    • Which records to read and in what order
    • What to ask the customer
    • Whether to request an exception, refund, hand off or reconcile

  • Code enforces

    • Only the authenticated customer's records are visible
    • No refund without loss evidence, an exception and approval of the exact amount
    • One refund per order; a lost confirmation leads to reconciliation, not a second payment
Who holds which authority. How information and authority move through the recorded system. A company deployment would connect the same tools to its own order, policy and payment systems.

The completed result

The agent refunded USD 46.00 for the original purchase after the exception was recorded and the customer confirmed, closed the case and changed no other order. The ledger check after the run found exactly that refund.

Two further recorded conversations follow the same rules when the customer declines the refund and when a refund confirmation is lost, and a test without a model shows that removing the exception blocks payment. For a company, the case sets out the decisions to make before building such an agent: which remedies policy allows, who may approve an exception, what the customer must confirm, which actions code enforces whatever the model decides, and how results are checked.

Technical detail

Recorded output: Agent final response, finish
Recorded customer-facing response: Your full $46.00 USD refund for puzzle order #W2598834 has been issued. Independent verification: the retained synthetic ledger contains one USD 46.00 refund and one resolved case for that order; unrelated orders are unchanged.
How the agent reached the result

Identify the purchase and failed remedy

  1. 1. Agent-selected tool: list_orders

    Four orders belong to the authenticated exercise customer. The model selects the puzzle purchase for investigation.

  2. 2. Agent-selected tool: read_order

    The original puzzle purchase is USD 46.00 and marked delivered. No refund has been recorded. The original purchase and its financial state are distinct from replacement fulfillment.

  3. 3. Agent-selected tool: read_replacements

    A no-charge replacement was dispatched for that purchase. Its shipment has a separate tracking record.

  4. 4. Agent-selected tool: read_shipment

    The carrier record contains an accepted event followed by a lost event. Lateness alone would not establish loss.

Establish the policy, authority and customer choice

  1. 5. Agent-selected tool: read_policy

    The original 30-day return window has expired; a replacement does not restart it. A full original-purchase refund requires documented replacement loss, a trusted exception decision and fresh approval of the exact quote.

  2. 6. Agent-selected tool: read_contacts

    The retained support contact records damaged puzzle pieces and the no-charge replacement. It records no previous refund.

  3. 7. Agent-selected tool: request_exception

    The configured trusted operator fixture grants this exact lost-replacement exception. This is an authored decision supplied outside the model/customer channel, not an actual manager conversation.

  4. 8. Agent-selected tool: ask_customer

    The agent asks whether the customer wants the full USD 46.00 refund for the original puzzle order. The human operator approves the displayed order, amount and currency.

Resolve and verify the result

  1. 9. Agent-selected tool: refund

    The actual tool commits one USD 46.00 synthetic refund and a resolved case. The recorded receipt identifies the original purchase.

  2. 10. Agent final response: finish

    Shown in full with the result

From discovery to requirement to check

  1. The unresolved business rule

    The replacement has failed after the original return window. The ordinary return rule does not establish whether the company should refund the purchase, offer another remedy or ask a person. The purchase, replacement shipment and customer preference must remain separate facts.

  2. Discovery question and responsible decision

    Ask the support and refund-policy owners: Does a replacement restart the return window? What proves it failed? Who may authorize an exception, and must the customer accept the remedy? The authored exercise answers: no restart; carrier-confirmed loss; a trusted operator decision for the exact exception; fresh customer confirmation of the full original-purchase refund. These are fictional stakeholder decisions, not client interviews.

  3. Requirement, permission and independent check

    The agent must earn the loss evidence and obtain both authority and consent before payment. Customer text cannot grant manager authority. The backend binds the exact order, amount, currency, policy and source revision to the approval. Independent checks inspect the actual ledger and reject unrelated changes. Controls remove loss proof, forge authority and revoke consent to confirm that no refund occurs.

The environment

Records and policy in the environment

Pinned tau retail order records and native reads provide the inherited account data. Authored replacement, carrier and prior-contact records supply the investigation. A versioned company policy specifies remedies and escalation. Only the authenticated customer's records are accessible. The no-charge replacement has no separate purchase amount to refund.

Available actions and observable consequences

The model chooses order, replacement, shipment, policy and contact reads. It can request a trusted exception, ask the customer, refund, reconcile an uncertain result or hand off. A separate exact-money SQLite ledger records synthetic refunds and cases. This custom ledger fills a gap in the native return-request environment, which does not itself demonstrate payment. No external payment or new replacement shipment is made.

Recorded variations

When the situation changes

A changed customer preference must change the resolution. A lost response after payment must lead to reconciliation of the original receipt, not another payment. Separate retained model conversations demonstrate both outcomes below. A removed policy exception is separately checked through actual tools and state; it is not another model conversation.

  • actual separate model conversationSeparate recorded variation: customer changes preference

    ask_customer → handoff

    The customer says they still want a working puzzle and declines the refund. The model opens an evidence-backed human review case. Independent inspection finds zero refunds and unchanged orders. The agent does not claim to have dispatched another replacement. This is a separate conversation, not a continuation of the synthetic-refund recording.

    Run digest 72c07335c247f10bf7c9a1f898eb36adeaa2781c4a1d96a9d118272c792a9707

  • actual separate model conversation with injected after-commit faultSeparate recorded variation: committed response is lost

    refund → reconcile → finish

    A deliberate fault loses the refund tool response after the ledger commits. The model calls reconcile and recovers the original receipt. Independent inspection finds one refund attempt and one USD 46.00 refund. This is a separate real-model run.

    Run digest 801a2ae23d005dd88935d58b627a2e8c0b585306b43740732d4f39ccc1c285f6

  • deterministic tool/state control; no model runSeparate deterministic control: exception removed

    request_exception / refund / handoff

    With the failed-replacement exception removed, the same loss evidence does not authorize payment. Actual tool and state controls reject the refund and accept an evidence-backed review case. This control exercises business permissions without an additional model run.

What was checked independently
  • An independent checker and direct read of the saved SQLite ledger confirm exactly one refund for the owned original purchase, the USD 46.00 amount, a resolved case and unchanged unrelated orders. The approval and exception records precede the payment.
  • In a separate real-model conversation, the customer declines a refund and asks for a replacement instead. The model opens an evidence-backed human review case; the actual ledger contains zero refunds. It does not claim to dispatch a new replacement.
  • In another real-model run, the refund tool commits but its response is deliberately lost. The model chooses reconciliation and finds the original receipt. The ledger has exactly one refund and there is only one refund attempt.
  • Executed controls reject missing carrier proof, forged authority, revoked consent and stale quotes. Removing the failed-replacement exception prevents the same records from authorizing payment and produces a review case. This policy control is a tool/state test, not an additional model run.
  • The foundation check also retained a narrow grader defect: when the selected native golden return action raises, its DB comparison can reward a no-op. The custom payment outcome is checked separately; no full-benchmark failure is claimed.
What changes for a company
  • Replace the illustrative policy with the company’s remedy rules, approval roles and actual return/replacement semantics. Ask process owners about exceptions that ordinary policy documents omit.
  • Connect account, carrier, contact and payment adapters to authorized systems while retaining explicit ownership, consent, durable receipts and reconciliation. An ambiguous or missing record must remain unresolved.
  • Construct representative tasks and independent outcome checks from that process. Compare the tool-using agent with a simpler workflow under a separately reviewed experiment; the agent is not assumed to win.

How we choose and check a business agent environment

What this case establishes
  • Three retained frontier demonstrations establish the exhibited behavior on development scenarios. They do not estimate unseen accuracy, comparative model advantage, production reliability, client return on investment or human labor savings.
  • The current private app accepts typed requests, but its automatic authority/state checks do not establish that every arbitrary customer intent was resolved. Declared development outcomes require separately supplied obligations.
  • The model was explicitly selected through authenticated headless Codex. A schema-constrained next-tool decision is adapted by the host; this is distinct from native provider function-call transport. Existing account usage is consumed and no API-dollar estimate is asserted.
  • The recorded source archive includes the exact source bytes present at execution, including uncommitted changes at that time. Its manifest hash identifies those bytes; the Git revision alone is incomplete provenance.
  • This public presentation contains only reviewed text and recording controls. It has no agent, model, tool, payment or job execution interface.
Public sources and authored material

Pinned tau retail source components

Selected public order records and native read tools. Replacement and carrier records, dates, company policy, trusted operator decisions and the custom financial ledger are authored additions, not upstream benchmark tasks.

MIT for the inspected upstream source. Dependency and task-asset terms remain separate.

Recording provenance

Synthetic business case with recorded model execution. Public benchmark components supply selected retail records and reads; replacement history, company policy and operator decisions are authored exercises. No client engagement or real payment is represented.

One USD 46.00 synthetic refund for the original puzzle purchase, after a trusted exception decision and fresh customer confirmation. One resolved case records the action. Unrelated orders are unchanged.

model
gpt-6.1-sol
interface
Authenticated headless Codex 0.163.0; structured next-tool adapter, not native provider function calls
run_sha256
aa048f10ae7dbb820550a60b6a96539f402cfb0a8eca430bdf09626ef9eb3552
recorded_at
2026-10-19
source_commit
a3dfe4fdb3fc5f87e8b7c63e83e70c6399409257
checker_sha256
9ef4805e5a117cdb2786e3bbf8ab86fd43ce41e5c103ffad3dc2f2ac900104fa
source_manifest_sha256
a14e0f1d640ffde0ac6edd6cd30978b2b9482f285e4620ac41e2742a6ee00a3d