The agent escalates correctly. It stops, it does not touch money, and it hands the message
to a person with a tidy three-line summary: "Customer reports non-delivery. Consignment is
still in transit at the sorting hub and is eleven days past the promised date. Suggest a
goodwill refund." The support executive reads it, agrees, and pays. The courier scan
actually said delivered, four days earlier, with a signature at the door. The goods are
with the customer and so is the refund. Nobody blames the agent, because the agent
escalated — which is exactly what everyone asked it to do.
Any agent whose main safe exit is a hand-off to a human: support desks, claims triage, fraud review, ops queues. Fires hardest where the escalation volume is high enough that the human reads the summary instead of the evidence — one executive clearing sixty escalations in a shift will trust a fluent paragraph. On the P4 reference desk 73 of 310 messages are escalations by design, and 14 of them are disputed deliveries where the scan and the customer disagree, which is precisely the case a paraphrase gets wrong. Linked modules: P4 (Tool-using agent workflow), 3.9 (Agents), 3.7 (Evaluating LLM systems), 6.6 (Project defence drills).
The guardrails worked. The reporting did not, and nobody was measuring the reporting.
Take the summary apart. "Still in transit at the sorting hub" is a sentence the model
composed. The tool returned a list of scan rows whose last entry was delivered, plus
several earlier in_transit rows. The model summarised the chain and picked the wrong end
of it, then wrote the result in the same confident register it uses when it is right.
Every project measures whether the agent escalated. Almost none measure whether what it
said in the escalation was true.
There is a second, quieter mechanism. A summary is judged by the human as a whole, so one wrong clause inside four correct ones inherits the credibility of the correct ones. This is why paraphrase is dangerous here and quotation is not: a quoted line carries its own source and can be checked in two seconds, while a paraphrase asks the reader to trust a compression they cannot see.
Confirm your exposure with a check nobody runs. Take fifty escalation summaries from your own logs, and for each factual claim ask whether that exact string appears in a tool result in the same run's audit rows. Anything that does not appear is invented, however reasonable it sounds. Teams who run this the first time are usually surprised by the count, and the surprise is the finding: the escalation rate looked healthy the whole time.
Immediate: stop acting on agent summaries alone. Until the fix ships, the escalation queue shows the raw tool output above the summary, and the executive is told to read the scan line, not the paragraph. That is a one-day change in the queue view and it stops the bleeding.
Structural. Make the escalation tool refuse a paraphrase: escalate_to_human requires a
quoted_facts array, each entry a verbatim string from a tool result in that run, with the
tool name beside it. The free-text reason field may hold the agent's opinion and must
carry no numbers, no dates and no statuses. Then add the checker: after the call is built
and before the row is written, every quoted fact is matched against this run's audit rows,
and a fact that does not match fails the escalation rather than sending it. Where the tool
output is a chain — courier scans, ticket history, payment attempts — the summary must
quote the latest row and say so, because "in transit" and "delivered" are both true of the
same shipment at different times.
Finally, measure it. Add summary accuracy to the evaluation harness as its own metric, scored on a sample by hand first, and report it beside escalation precision and recall. An escalation with a wrong summary is worse than no escalation, because it converts a careful human into a fast one.
Write the rule into the tool contract on day one: an agent may quote or it may reason, and it may never do both in the same field. Facts go in a quoted array, judgement goes in a reason field, and the two are rendered differently in the queue so the reader can see which is which at a glance.
Design the human queue as evidence-first. Tool output on top, quotes beneath it, the agent's suggested action last and visually smaller — the reverse of what feels natural, and the layout that survives a busy shift. Keep a disputed-delivery class in the evaluation set with its own floor, because it is the class where a paraphrase does the most damage. And treat every "suggest a goodwill refund" as a money recommendation: it should carry the same audit row and the same review as a refund the agent could have made itself, since a human clicking yes on it spends the same rupees.
Q: "Your agent escalated properly and a customer still got a wrong refund. Where do you look?" Strong answer: say in the first sentence that the guardrail worked and the reporting failed, then name the mechanism — the summary paraphrased a tool result and the human read the summary instead of the evidence. Give the check that finds it: match every factual claim in fifty summaries against the strings in that run's audit rows. Give the fix as a tool signature change, not a prompt tweak — a required quoted-facts array, verified against the audit rows before the escalation is accepted, with judgement kept in a separate field. Strongest answers add the measurement gap that let it run for weeks: escalation rate and escalation precision were both healthy, and neither one looks at whether the summary was true.