A Failed Turn Now Stays in the Conversation
August 26, 2026 · InfraScout Team
AI providers rate-limit, and a long agentic assessment has more opportunities to meet one than a short question does. Three changes to what happens when a turn fails.
A transient failure is retried in place
Where a failure is genuinely transient — a rate limit, a momentary provider error — the turn is now retried rather than abandoned. Up to three attempts, waiting the delay the provider itself asked for where it supplies one, or a 5/15/30-second ladder where it does not. A status line keeps the stream alive so you can see the wait instead of watching a stalled cursor.
Before this, a run that tripped a rate limit at its thirtieth step ended there — for want of the few seconds the provider had asked for.
Two conditions on the retry, both deliberate. It fires only when nothing has streamed on that turn, because a re-run starts the response from scratch and text already on your screen would end up duplicated beneath itself. And it does not fire on the final iteration, where the wait would be spent on a turn that will not be attempted again.
Worth separating from the Retry button, which is a different thing: that exists for deterministic failures that only a fresh send can repair, and those are precisely the ones an automatic retry would waste time on.
A real failure is written down
A turn that genuinely fails now appends what it had produced — the partial answer, the reasoning, the model that produced it — plus the failure itself. Reload the page and it is still there.
Previously a failed turn persisted nothing, so a reload showed no sign anything had happened. The conversation simply ended mid-assessment, with no explanation available to anyone reviewing it afterwards. In an audited assessment tool, a failure belongs in the record.
The error card is collapsible: a one-line summary, and a Details toggle that opens the verbatim provider text into a scrollable well with its own copy button. Enough to paste into a support request, without a wall of provider output sitting permanently above your composer. Retry and Dismiss sit beside it.
The timeline keeps what it already had
After a failure, sending your next message used to drop the failed turn's already-stored messages from view. They were never lost — a reload brought them back — but nothing said so, and until you reloaded it looked as though the work had gone.
The timeline now reconciles against the stored record whenever a failure identifies the message it wrote, and a retry replaces only the trailing messages that exist nowhere but your browser. Anything already stored stays put.
Where a failure happens before anything is stored — a rate limit at admission, say — your own message exists only locally, and it is deliberately kept so that Retry can resend it.
See Chat for what each state looks like.
Questions or feedback? Reach us at info@infrascout.cloud.