Resolve the complaint. Control the refund.
A fictional food-delivery platform uses an assistant to resolve a missing order. A customer requests more than the eligible refund or asks for a different payment destination.
All use casesMake the boundary explicit.
Bind the action to the authenticated customer, order, refundable amount, approved destination and current policy. Allow routine eligible refunds, route exceptions to review and reject unauthorized destination changes.
Support can resolve ordinary complaints quickly without unrestricted payment-system access. Keep the actual result and reconcile any missing acknowledgement.
Follow the refund from request to effect.
Evidence to inspect
Requester, order, amount, destination, approval inputs, current policy and the provider's original effect identity.
Control to apply
Require approval when the material request needs it, re-evaluate changed inputs and reconcile an unknown outcome before retry.
Inspect the decision.
Refund an eligible amount to the original payment destination.
Ready to evaluate
No external action
Select a variation and inspect the local example. This demonstration does not call a model or connect to a business system.
This example uses synthetic orders and policy thresholds. The real provider must expose a controlled refund operation.
The controls behind the workflow.
Explore the capabilities that compose around this task, rather than treating each step as a separate product.
Related ways to use DriftGate.
Keep your support agent focused on support.
A shopping assistant is steered away from product and order questions toward unrelated coding or repeated expensive generation.
A timed-out refund should not become two refunds.
A payment provider receives a refund request, but the acknowledgement is lost. The agent wants to repeat it.