The Return Agent That Cannot Complete a Return
Waypoint Logistics runs an Agentforce service agent for 8,000 monthly customer emails. The agent has three topics-Returns, Exchanges, and Order Lookup-built in Agent Builder. The Returns topic uses a Flow action with inputs orderId, itemId, and reason and outputs eligibility and returnLabelUrl. In production, the agent often calls the Returns action with orderId but no itemId, then tells the customer the return is complete. Sometimes it invokes the Exchange action for a return request. The instructions say 'always resolve the customer's issue in the fewest turns.' The Flow has no validation for missing inputs, and the agent has no action to list items in an order. The team wants to add a 'cancel order' capability next.
1. Why does the Returns action fail, and why does the agent claim the return is complete?
Read the worked answer
The failure is caused by a missing capability and conflicting incentives.
- The agent cannot discover
itemId. There is no action to list order items, so the required input is unavailable. The model fills the gap rather than stopping. - The Flow does not reject incomplete input. Without validation, the action may return an empty or partial result, which the agent interprets as progress.
- The instruction 'fewest turns' rewards skipping confirmation. It pushes the agent to call the action before collecting the item and reason.
- Topic descriptions overlap. Returns and Exchanges are semantically close, so the classifier can select the wrong action.
- The agent narrates success rather than reading action status. It should confirm completion only from a successful action output such as a return label URL.
This is an action-design and instruction-design defect, not a model hallucination in isolation.
2. Redesign the topics, actions, and instructions to make returns reliable.
Read the worked answer
Make the workflow explicit and verifiable.
Topics
- Order Lookup: find order and list items.
- Returns: return an eligible item from an order.
- Exchanges: exchange an item, with a distinct description that names exchange, replacement, or different item.
Actions
getOrderItems(orderId)returns item IDs, names, and eligibility.createReturn(orderId, itemId, reason)validates all required inputs and returnssuccess,returnLabelUrl, or a typed error.- Keep exchange actions separate and require an exchange-specific confirmation.
Instructions
- Confirm the order and the exact item before calling
createReturn. - Never state that a return is complete unless the action returned success and a label URL.
- If an input is missing, ask for it or use
getOrderItems; do not guess. - On validation error, explain the error and offer escalation.
Flow
- Reject missing
itemId, validate eligibility, and return structured errors. Log action failures so they can be reviewed.
3. What should the team evaluate before adding a 'cancel order' capability?
Read the worked answer
Cancellation is more consequential than a return, so the team should evaluate risk before building.
- Irreversibility and policy: can an order be uncancelled? What notice, fees, or time windows apply?
- Authority: should the agent cancel any order, only unshipped orders, or only below a value threshold? Which actions need human approval?
- Confirmation design: the agent must read back the order and item, state consequences, and obtain explicit confirmation before executing.
- Permissions and audit: the Apex or Flow action should enforce the same sharing and policy rules as the human service console, and every cancellation should be logged.
- Failure handling: timeouts and partial failures must not be narrated as success; the agent needs a retry or escalation path.
- Test coverage: cancelled, shipped, partially shipped, high-value, duplicate request, and prompt-injection cases.
Adding a cancel action without these controls would extend the same pattern that produced false return completions.