Retry with backoff on rate limits
On by defaultWhen a provider returns a rate limit or quota error, the call is repeated up to three times, waiting 1, 2 and then 4 seconds.
Error handling and recovery
Model providers time out, APIs return errors and tools fail. The platform notices these failures and recovers without anyone typing retry, and in most cases the customer never sees that something went wrong.
Each capability is marked as on by default or configurable per assistant, workflow or tenant. Defaults that touch customer data can be switched off where regulation or your own policy requires it.
When a model fails
Model calls are the most common point of failure, so they have several layers of recovery.
Timeouts and automatic retries
On by defaultModel requests retry automatically and time out after 90 seconds, embedding requests after 30 seconds, so a hanging provider cannot block a conversation.
Switch to another provider
On by defaultIf a provider fails before the first word of an answer, the turn moves to a model from another provider and the switch is recorded in the trace. The operator can switch this off per environment when data may only go to approved providers.
Guardrail checks have a backup
On by defaultA guardrail model gets 15 seconds. If it fails or times out, the check runs once more on another provider instead of being skipped.
When a tool or system fails
Agents work with systems that are slow or down. The platform handles that inside the run.
Errors go back to the agent
On by defaultIn a workflow, a failed tool call returns the error to the model as the tool result. The agent then chooses what to do next: different arguments, another tool or another route to the goal.
A time budget for tools
On by defaultAll tool calls in one turn share a 45 second budget, so one slow system cannot stall the conversation.
MCP reconnects
On by defaultOn a connection error the platform reconnects to the MCP server and tries again, and it can call the same tool on another MCP server. MCP servers are health checked every hour.
Empty results are retried
On by defaultWhen the model returns an empty response in a workflow, the step is repeated up to two times.
Validation and retry per workflow step
ConfigurableA workflow step whose output fails validation is retried a set number of times with a delay between attempts, or the run stops, depending on the setting.
When an answer is not good enough
A technically successful answer can still be wrong. These checks catch that before the customer reads it.
Regenerate below a quality threshold
ConfigurableThe quality guardrail scores each answer. Below the threshold, the agent writes a new answer, up to a maximum number of attempts.
Leaked reasoning is caught
On by defaultWhen a model's internal reasoning ends up in the answer, the answer is generated again before it is sent.
No silent stops
On by defaultIf a turn still fails after these steps, the customer gets the fallback message configured for that assistant, and the error is logged with the conversation.
Seeing what happened
Recovery is only useful when you can check it afterwards.
Traces per conversation
On by defaultTraces record tool calls, retrieval, guardrail hits, provider fallbacks and regenerations for every turn.
Switch it off per assistant where regulation or your own policy requires it.
Scheduled monitors
ConfigurableTest suites run on a schedule, from every 5 minutes to once a day, and alert by email or webhook when results drop.
Decision log
On by defaultEvery recovery step, from a provider switch to a regenerated answer, appears in the conversation's decision log, which exports as JSON or over OpenTelemetry.
Switch it off per assistant where regulation or your own policy requires it.
Error handling: FAQ
How the platform works
Want to see it on your own systems?
We run a working session on your use case, with your data and the models you choose.
Plan a call