The Overeager Order Status Agent
Northwind Outdoors, a B2C retailer, handles 12,000 help-center chats a month. Its new Agentforce service agent has two topics: Order Status and Returns Policy. Order Status calls a Flow that queries an order-management API with a two-second average latency; Returns Policy answers from three knowledge articles. The agent was told to 'be helpful and resolve quickly.' In an audit of 200 transcripts, 18% show the agent promising refunds above $50 without approval, 11% cite delivery dates that do not match the API response, and escalations occur only when the customer explicitly asks for a human. Leadership wants a 30% reduction in handoffs and says the agent should 'handle everything.' Refunds above $50 require human approval, and the OMS API is read-only.
1. Why is the agent making unauthorized refund promises and inventing delivery dates? Diagnose the design failure, not the model.
Read the worked answer
The agent is being asked to produce conversational answers in areas where it has no authoritative action or constraint.
- No refund action exists. The only grounded behavior is Order Status; Returns Policy is retrieval-only. When a customer asks for a refund, the model generates a plausible commitment from policy language instead of checking eligibility.
- The instruction 'resolve quickly' competes with policy. It biases the agent toward closure and against escalation, especially when the customer does not ask for a human.
- Delivery facts are not separated from explanation. If the Flow response is summarized generatively without a deterministic template, the model can round, infer, or invent dates.
- No explicit prohibition or guardrail says 'never promise a refund' or 'never state a date not returned by the action.'
- Escalation is reactive. The agent has no rule to hand off high-risk intents such as refunds over $50.
The fix is to constrain authority, not to add stronger wording alone.
2. Redesign the topics and actions to reduce handoffs by 30% without increasing unauthorized commitments.
Read the worked answer
Separate what the agent can know, decide, and do.
- Order Status topic - action
getOrderStatusreturns structured fields: status, carrier, promised date, last scan. Use a deterministic response template for the facts and generative text only to explain them. If the action fails, say so and escalate; do not infer a date. - Returns Policy topic - retrieval-only answers with citations. Instruction: explain policy but never promise an outcome or amount.
- Refund Request topic - action
checkRefundEligibilityreturns eligible/not eligible, amount, and reason. If eligible and at or below $50, confirm; if above $50, missing data, or exception, hand off with a structured summary. - Triage topic - route ambiguous requests and high-risk intents to the right topic or human.
A 30% handoff reduction should come from deflecting status and policy questions and automating low-risk refund decisions, not from pretending the agent has refund authority. Measure containment by intent, unauthorized-commitment rate, and escalation reason.
3. How should leadership interpret the instruction to 'handle everything'?
Read the worked answer
'Handle everything' is a capability boundary question, not a tone instruction. The agent can triage every request, answer many, and complete a narrow set of low-risk actions. It cannot safely approve refunds above $50, override policy, or invent facts it was not given.
A defensible interpretation is:
- Every request gets handled - acknowledged, routed, answered, or escalated with context.
- Not every request gets resolved by the agent. High-risk or irreversible outcomes need human authority.
- Handoff reduction is a outcome of good triage, not a reason to remove escalation.
Leadership should define risk tiers, approve which actions the agent may execute, and track containment alongside accuracy, complaint rate, and unauthorized-commitment rate. Removing the escalation path to hit a target would convert a measurable containment problem into an unmeasured trust problem.