Traditional software fails like glass: rarely, loudly, all at once, and a dialog box apologizes. Agents fail like weather: routinely, partially, and probabilistically. Step four of seven breaks while the first three produced real value. A tool call times out on the second retry. An extraction is 90% right and 10% quietly wrong. Interfaces built for glass — the modal, the red toast, the start-over button — shatter under weather, because they treat a partial success as a total loss.
The design shift: failure is a state to render, not an event to apologize for. It belongs in the same visual system as running and done, with the same legibility.
The cardinal sin of agent failure UX is discarding completed work because a later step broke. Three booked-trip steps succeeded before the hold expired; the interface that throws that away just charged the user three steps of waiting for nothing, and taught them never to delegate anything long. The plan widget is the natural ledger: done stays done, failed shows its error inline, pending stays visibly untouched. Recovery means resuming from step four, never from zero.
When a step fails, the diagnostic material is the inputs, not just the error string. A failure that keeps its arguments attached lets a human spot the wrong assumption in seconds; a failure that shows only "something went wrong" forces a re-run to reproduce what the interface already knew. This is why every component in this system keeps arguments visible in the error state: the crash site should come with its flight recorder.
Agents can retry, which is a gift and a trap. Unbounded silent retries turn a ten-second task into a two-minute mystery spinner. Render the retry ("attempt 2/3, waiting 30s"), bound it, and when the bound is hit, stop and say what's left undone. An honest "I couldn't finish steps 4-5; here's what's done and why it stopped" preserves more trust than any amount of optimistic spinning, because the user learns the agent fails legibly, and that is precisely what makes them willing to hand it the next task.
Stopping is part of the same contract. A user-initiated stop is not a failure, and the receipt should prove it: what survived, stated plainly.
The rules that survive shipping: failure is a rendered state, not a modal; partial work is never discarded; errors keep their inputs attached; retries are visible and bounded; and the end of a broken run states exactly what's done and what isn't.
Applied in: Agent Task List, Interrupt Bar, Tool Call Card. Related: Calibrated Trust.