What It Does

Error Handling is a regular state in every mechanical respect — prompt, tools, transitions — but it exists semantically to recover. The prompt tells the agent how to acknowledge the problem, what (if anything) to try, and how to exit gracefully. Common outcomes are "ask the caller to repeat," "offer a different path," or "transfer to a human."

When to Use It

• A tool call failed. The Calendly API timed out; the Knowledge Base returned nothing; the transfer could not be completed.
• The caller's input did not match anything the flow expected. They answered a yes/no question with a paragraph; they gave an invalid ZIP code; they spoke a language the agent cannot handle.
• A required field in a Collect Information step could not be captured after multiple tries.
• The flow reached a state the agent does not have the tools to handle — a safety net.

For very simple flows, you may not need an Error Handling state — the agent will usually recover on its own by asking again. Add one when the recovery path is distinct enough to deserve its own behavior (transfer, apologize, change approach).

Writing the Description in the Error Handling State

• Acknowledge the problem briefly. "I am having trouble with that" or "let me try a different way."
• Do not over-apologize. One apology is fine; three in a row sounds robotic and makes the caller more frustrated.
• Offer a clear next step. "Would you like me to transfer you to someone who can help?" is much better than a vague "let me know how to proceed."
• Always include an exit. Transfer to a human, send to voicemail, or transition to Closing. Never leave the caller stuck.
  

Tools to Include

A typical Error Handling state carries a small recovery toolkit:

• Route Call — the default escape hatch.
• Collect Info (optional) — take a callback request if no one is available.
• Transition to Closing/End Call — for cases where the right outcome is "end the call and let a human follow up."

You generally do not want to include every tool in the Error state. The point is to narrow, not widen, the agent's options.

How the Flow Gets Here

There is no automatic "catch any error and jump here" wiring — transitions to Error Handling are explicit, like any other transition. Typical triggers you write on an upstream state:

• "Go to error handling if a tool returns an error or the caller repeats a question the agent has already tried to answer twice."
• "Go to error handling if the caller asks for something outside the agent's scope."
• "Go to error handling if after three attempts the caller has not provided a required field."

Write the transition description as carefully as any other transition — too loose and every small hiccup fires the error state; too tight and real failures slip past.

Common Mistakes

• No exit. An Error Handling state with no transitions to Transfer or Closing traps the caller. Always give it a way out.
• Too chatty. An error recovery that apologizes for three sentences and then asks a new question feels worse than a quick transfer.
• Using it as a catch-all. If every transition points to Error Handling, the flow is under-specified. Add proper transitions on the upstream states first.