Agent interfaces should show recovery state before reasoning text

Agent interfaces should show recovery state before reasoning text. When an agent stalls, fails, or produces a doubtful result, the operator first needs to know what changed, what remains in flight, what can be undone, and what action is safe next. A generated rationale may help later. It cannot substitute for a visible account of the system state the person must now control.

Frontend state-management patterns make this requirement concrete. Async work already has states such as pending, fulfilled, and rejected; optimistic updates already require a snapshot and rollback path; message streams already need ordering and deduplication. An agent interface often hides these durable state transitions behind a single conversational bubble. The result is a polished transcript that says “done” while the application still cannot tell whether a tool committed, a retry duplicated an effect, or the visible answer belongs to stale workspace state.

I would model recovery as its own slice of product state. It should record the last confirmed checkpoint, the effects known to have committed, actions whose outcome is uncertain, blocked dependencies, available compensations, and the authority required to continue. Selectors can then render the same truth differently: a compact status strip for routine work, a step ledger during execution, and a detailed incident view when intervention is needed. This is more reliable than deriving status from prose because the UI reads explicit state rather than interpreting the agent’s claim about itself.

The order on screen matters. First show the operational facts: “two of four actions completed; invoice creation is unconfirmed; no retry sent.” Then show the available controls: verify, retry from checkpoint, undo, or hand off. Only after that should the interface offer the reasoning or trace that may help a reviewer understand why the agent chose the path. This follows the argument that recoverability beats explainability: comprehension is useful, but control is the immediate safety property.

Streaming makes the separation even more important. A token accumulator describes output progress, not task progress. The model may be producing a confident explanation while a tool call is still pending, or the text stream may stop after the external effect succeeded. I would therefore keep message state, execution state, and persisted domain state separate. Cache invalidation from the authoritative process should update the recovery view, while deduplication and ordering prevent a late event from making a completed action look pending again.

This design also improves evaluation. A recovery task can assert whether a participant noticed the uncertain effect, chose a non-duplicating next step, and resumed from the right checkpoint. That is stronger evidence than asking whether the reasoning text sounded clear. It also gives support and operations teams a shared vocabulary: not “the agent seemed confused,” but “the effect is unconfirmed and the last durable checkpoint precedes approval.”

There is one precise concession: for read-only, low-stakes answers with no persistent side effects, a short rationale may deserve more prominence than recovery controls because the only recovery action is usually to revise the query. My claim applies once work is asynchronous, stateful, interruptible, or consequential—exactly where a chat-shaped interface most often hides the information an operator needs.

I want the interface to answer four questions without reading the model’s mind: what happened, what is uncertain, what progress is preserved, and what can safely happen next. Reasoning text can enrich that answer, but it should never carry it. If recovery state is not represented explicitly in the application, the user is being asked to infer operational truth from generated language. That is not transparency; it is another probabilistic dependency.