Software interfaces are often designed around a clean, uninterrupted session: one person starts a task, watches it progress, and receives a result. Real work is less tidy. People leave meetings, priorities shift, dependencies fail, approvals take hours, and a different engineer has to take over.

Agentic systems should assume interruption is normal.

This changes the design of the interface. The screen cannot only show a stream of activity. It needs to show the current state of work in a form that remains useful after time has passed.

A handoff is not a failure

When a task stops, the interface should not communicate only that the agent is inactive. It should name the state: waiting for a specific decision, blocked on a missing resource, paused after a recoverable failure, ready for review, or superseded by another task.

The distinction matters because each state suggests a different next action. A reviewer may need to inspect a diff. An operator may need to refresh a credential. A new engineer may need to decide whether a changed requirement invalidates the plan. A generic "stopped" label offers none of that context.

The task record should preserve the smallest useful handoff:

• the objective and constraints;
• what changed in the workspace;
• which checks and external actions were completed;
• what remains unresolved;
• the next decision and the person or role that can make it.

This is enough to reconnect a person to the work without replaying a long conversation. It is also enough for a later agent session to resume with humility about which facts may have gone stale.

Design for return, not only for flow

An interface built only for flow rewards activity. It shows commands racing past, tokens accumulating, and a model producing a detailed narration. An interface built for return emphasizes stable landmarks: the task goal, its current branch or workspace, the last verified result, the outstanding approval, and the evidence that remains relevant.

These landmarks make a workbench calmer. They reduce the need to keep everything on screen at once. Logs, source, previews, and prior discussion can remain available, but the task should not force a returning user to parse all of them before discovering what happened.

The design question is practical: after twelve hours away, can the person tell whether there is anything they need to do, why it matters, and what will happen after they decide?

Time changes the validity of information

Interrupted work is not simply paused work. Time changes the environment. A branch may receive other changes. An external record may have been updated. A deployment preview may no longer match the current revision. An approval may be too old for the risk it was meant to cover.

Good interfaces expose that decay. They can mark evidence as stale, distinguish an old plan from the current workspace, and ask the agent to refresh assumptions before resuming a consequential action. This is not unnecessary caution. It is how the system avoids applying yesterday's context to today's state.

Handoffs need a human language

The language of a paused task matters. "Process exited with code 1" is a useful machine detail, but it is not a handoff. Neither is a model's generic apology. A good status explains the operational meaning: the preview build failed after the dependency change; the source branch is intact; no external action ran; the task needs either a package version decision or permission to test an alternative.

This kind of writing should be brief and specific. It should not perform certainty or disguise unresolved questions behind a polished narrative. The interface can link to terminal output, a diff, or a trace for the reader who needs more detail, while preserving an accurate plain-language account at the top of the task.

That is especially important when the next person is not an engineer. A product lead may need to decide whether a failed preview is acceptable for a release. A security reviewer may need to understand a requested connector grant. An operator may need to know whether a task has already affected a customer-facing system. The workbench should translate state into a decision, without deleting the technical evidence behind it.

The quieter interface is often the more capable one

There is a temptation to make an agent workbench visibly busy in order to demonstrate that work is being done. In practice, the most useful screen is often quieter: a short task summary, a clear status, a visible next decision, and a route to the details when they are needed.

The interface earns trust not by dramatizing the agent's inner monologue, but by preserving a reliable relationship between the task, the system state, and the person responsible for the next decision.

If agentic software is to become part of ordinary work, it must be designed for interruptions as carefully as it is designed for starting. The task should remain understandable when nobody has been watching.