Exceptions and operating records
What Happens When an AI Agent Gets It Wrong?
After an Agent enters a live workflow, success rate is not enough. Missing data, low confidence, tool failure, and out-of-scope requests need a stop, a handoff, and a reconstructable log.
Pilots are judged on the tidy examples: the class was right, the draft was usable, the record was written. Daily operations are decided by the messy ones. A customer sends “how’s that order,” an attachment is missing, an API times out, the same question arrives a third time. If the Agent still produces a complete answer, the risk is larger than a wrong FAQ, because it looks capable while nobody knows it has left safe ground. Exception handling is the difference from a chat demo. The Agent has to know when to stop.
Name the cases where it should not keep going
Typical classes are missing data, out-of-scope asks, tool failure, conflicting sources, and a user who is angry or requesting a person. They should not share one “please try later” line.
Missing data should ask for the gap. Out of scope should stop guessing. Tool failure should keep the half-finished record and the error. Low confidence should show the missing source instead of restating the same claim.
“Can I return the last one?” without an order number or an approved policy should collect facts and escalate, not invent a refund explanation in a gentle tone.
- Missing data: list the gap; do not complete the answer with guesses
- Out of scope: stop, keep context, escalate
- Tool failure: log the error, retry policy, and current state
Handoff with context, not a dead-end “contact a specialist”
Customers resent repeating a five-minute conversation. Staff resent an empty ticket. A handoff should include the original question, queries already tried, sources cited, the rule that stopped work, and a suggested next step.
The queue needs an owner for business hours, overflow, and holidays. “It can escalate” is not a staffing plan.
AgentTech treats the Agent’s intermediate result as a pending case, not merely a failure. People judge and release; they should not have to redo the sorting.
Logs should explain why the step happened
Full chat transcripts are not enough. Keep structured events: trigger time, record identifiers, tool, success or failure, gating rule, and who approved what. Mask personal data as policy requires; keep the chain reconstructable.
That also makes internal disputes checkable. If the Agent created the wrong customer, engineering can show the phone number and source form used at the time.
Retention and access should match existing customer-data policy. Do not treat the model vendor’s session history as the system of record.
Retries need limits; some actions cannot be quietly undone
Blind retries create duplicate customers and duplicate messages. Define idempotency keys before go-live.
Drafts can be voided. A message already sent to a customer cannot be silently recalled. Record it and let a person decide whether to correct it.
Use exception reasons to improve the workflow
If failures cluster on missing order numbers, fix the form or the LINE menu. If they cluster on conflicting documents, fix the knowledge. If they cluster on out-of-scope asks, the public description may be overpromising.
Acceptance tests should include missing inputs, unauthorized asks, and failed APIs. Stopping correctly is part of being production-ready.
Service for this topic
AI Agent system integration
AI AGENT
Connect AI Agents to custom systems, apps, data, and third-party tools, with explicit data access, allowed actions, human approval, logs, and exception handling.