When an agent takes minutes instead of seconds, chat UI stops working: the user has nothing to look at, no way to redirect course, and no signal when the job actually finishes. The fix is to stop modeling the interaction as a conversation and start modeling it as a background job with a status surface — visible plan, live activity log, interrupt controls, and a real completion event.
Quick Answer: Long running agent experience needs a status surface, not a chat bubble. Show the plan before execution, stream an activity log during it, allow interruption at defined checkpoints, and notify on completion the way you'd notify for any async job — not with a spinner that hopes you're still watching.
Why Synchronous Chat UI Breaks Down Past 30 Seconds
Chat UI assumes a human is watching and waiting for each turn; once a task runs for minutes, that assumption collapses and the interface actively works against the user. A blinking cursor or spinner communicates "something is happening" but nothing about what, how far along, or whether it's stuck.
The core mismatch is temporal. Chat was designed for turn-taking at conversational speed — a few seconds between messages, where the cost of waiting is negligible and the cost of interrupting is low. Multi-minute agent tasks invert both variables: waiting is expensive (the user has moved on to another tab or task), and interrupting is now a real decision with consequences, not a casual "actually, wait."
This is well documented in HCI research on system status. Jakob Nielsen's "visibility of system status" heuristic — one of the original 10 usability heuristics from Nielsen Norman Group — states that a system should always keep users informed through appropriate feedback within reasonable time. A spinner satisfies the letter of that heuristic while violating its spirit: it's feedback, but it's not appropriate feedback for a job that might take eight minutes and touch a dozen files or API calls.
Consider what actually differs once a task crosses the multi-minute threshold:
| Dimension | Synchronous chat (seconds) | Async agent job (minutes) |
|---|---|---|
| User attention | Continuous, in-frame | Intermittent, tab-switching |
| Right mental model | Conversation | Background job / pipeline run |
| Failure cost of no feedback | Low (next turn is seconds away) | High (user may wait or abandon) |
| Interruption | Cheap, mid-sentence | Needs a defined checkpoint |
| Completion signal | Implicit (new message appears) | Needs explicit notification |
| Precedent UI | Messaging apps | CI/CD pipelines, batch jobs, file uploads |
The right precedent isn't a messenger app — it's a CI/CD pipeline or a long-running batch export, both of which solved this problem decades ago with progress bars, logs, and notifications. Our complete guide to AI agents covers this same distinction at the architecture level: agents that plan and act over multiple steps are structurally different from single-turn chat completions, and the UI has to reflect that difference, not paper over it.
Design Progress Visibility Like a Job Status Page, Not a Spinner
Progress visibility means showing what the agent is doing and how far along it is, not just that it's doing something — a plan preview before execution and a live activity log during it, both scannable in under two seconds. An opaque spinner is the single worst-performing pattern here because it conveys zero information about scope, direction, or risk.
The Plan Preview
Before an agent starts multi-minute work, it should render its intended steps as a checklist — not a paragraph of prose reasoning, a literal ordered list a user can scan, edit, or veto. This does two things at once: it sets accurate time expectations (a five-step plan reads very differently from a two-step one), and it gives the user a last checkpoint to catch a misunderstood instruction before any action is taken.
- Step name — a short verb phrase ("Search knowledge base," "Draft summary," "Update ticket status")
- Scope indicator — what the step will touch (files, records, external systems)
- Reversibility flag — whether the step is read-only, additive, or destructive
- Estimated weight — relative, not a false-precision timestamp ("quick," "moderate," "longest step")
This is directly related to how much latitude an agent should have before acting without confirmation, which is really an autonomy question. Our agent autonomy levels framework gives a vocabulary for deciding, per step, whether the agent should just do it, propose-then-act, or stop and ask — and the plan preview is where that decision becomes visible to the user rather than buried in a system prompt.
The Activity Log
Once execution starts, replace the spinner with a running log: timestamped, append-only, one line per meaningful action. Think of it as a lightweight version of a CI build log — a user doesn't need to read every line, but the log's mere existence and forward motion is reassuring in a way a static spinner never is.
- Timestamp each entry so stalls are visible (a 90-second gap between lines is a signal, silence is not)
- Name the action concretely ("Fetched 12 records from CRM," not "Processing...")
- Surface intermediate artifacts as they're produced (a draft, a diff, a partial result) rather than only at the end
- Flag branching or retries explicitly, since silent retries are one of the most common causes of user distrust in agent systems
A log also does something a progress bar can't: it makes non-deterministic behavior legible. Agents don't execute a fixed script the way traditional workflow automation does — they can take different paths depending on intermediate results, tool outputs, or ambiguity in the task. Our piece on agent vs. workflow non-determinism explains why that variability is a feature, not a bug, of agentic systems — but it also means the UI has an obligation to narrate the path actually taken, since the user can't assume it matches the plan preview exactly.
Make Interruption a First-Class, Not Emergency, Action
Interruptibility means giving users an always-available, low-friction way to pause, redirect, or cancel a running agent — not a hidden "stop" buried in a menu, and not a hard kill that discards all progress. Treat interruption like a pause button on a video, not a fire alarm.
The mistake most teams make is treating interruption as an edge case to handle defensively rather than a primary interaction to design for. But once a task runs multiple minutes, the odds that context changes mid-run — a new priority arrives, the user spots a wrong assumption in the activity log, a step turns out to be irreversible when the user expected otherwise — go up substantially. The interface needs to make correcting course cheap.
Checkpoint-Based Pausing
Rather than trying to interrupt an agent at an arbitrary instant (which can leave state half-mutated), define checkpoints — natural boundaries between plan steps where pausing is safe and cheap. This mirrors how CI/CD systems let you cancel between build stages rather than mid-compile.
| Interrupt pattern | When to use it | User-facing behavior |
|---|---|---|
| Pause at next checkpoint | Default, low-risk redirect | Agent finishes current step, then waits |
| Immediate stop | User sees a clearly wrong path forming | Agent halts, current step marked incomplete |
| Redirect with new input | User wants to adjust scope mid-run | Agent replans remaining steps, keeps completed ones |
| Resume later | User has to leave before completion | Session state persists; user returns to same point |
Resumable sessions deserve special emphasis because they're the pattern most chat-derived UIs skip entirely. If a user closes the tab or their laptop sleeps, the agent's state — plan, completed steps, partial artifacts — should persist and be resumable, exactly like a saved video-editing project or a paused download, not discarded like an ephemeral chat thread.
This connects to a guardrails question as much as a UX one: some steps genuinely shouldn't be interruptible mid-execution (a partially-applied database migration, for instance), and the interface needs to communicate that distinction honestly rather than pretending everything is safely cancelable at any instant. Our guide to agent action guardrails covers how to classify actions by reversibility, which is the same classification a good interrupt-pattern table like the one above depends on.
Design Completion Notification for Attention That Has Moved On
Completion notification means telling the user a long agent task finished through a channel that reaches them wherever their attention actually is — not a static in-app message waiting to be found. If a user has switched tabs or closed the laptop, an unread badge that only lives inside the original chat window has functionally failed at its job.
Notification Channels, Ranked by Reach
- In-app toast/badge — works only if the app is open and visible; the weakest option for anything over ~2 minutes
- Browser/OS push notification — reaches the user even if the tab is backgrounded, assuming permission was granted
- Email digest — appropriate for longer-running or batch-style tasks where immediacy matters less
- Webhook/Slack integration — best for team contexts where the output needs to land where the team already works
What the Notification Itself Should Contain
A completion notification is not just "done" — it should answer the same three questions a good CI notification answers: what ran, what the outcome was, and what (if anything) needs review. Include a one-line result summary, a flag for anything requiring human approval, and a direct link back into the session state — not just the app's home screen.
This is the same principle behind the jobs-to-be-done framing of "hire" and "fire" moments: the user hired the agent to free them from watching a task run, and the notification is the moment that job either gets completed cleanly or reveals it wasn't actually done. A vague "Task complete!" push notification under-delivers on that job as badly as no notification at all.
Patterns and Anti-Patterns for Long Running Agent Experience
Good async agent UX borrows deliberately from job-scheduling and pipeline interfaces that already solved visibility, interruption, and notification decades before agents existed; the anti-patterns are almost all attempts to force a multi-minute task back into a conversational shape it doesn't fit.
| Pattern (adopt) | Anti-pattern (avoid) | Why the anti-pattern fails |
|---|---|---|
| Plan preview before execution | Silent start with no visible intent | User can't catch a misread instruction until it's too late |
| Timestamped activity log | Opaque spinner or "thinking..." loop | Zero information about scope, progress, or stalls |
| Checkpoint-based interrupt | Hard kill only, or no interrupt at all | Forces users to either wait blindly or lose all progress |
| Resumable session state | Session dies with the tab/window | Punishes the user for doing anything else while waiting |
| Multi-channel completion notice | In-app-only badge | Fails the moment attention moves elsewhere, which is the point of async |
| Reversibility flags per step | Uniform "AI is working" messaging | Hides which steps are risky vs. safe, undermining trust |
Two of these deserve a second look because they're easy to half-implement and call done. A plan preview that isn't actually editable is barely better than no preview — it needs to function as a real checkpoint, not decoration. And a notification without a deep link back to session state forces the user to hunt for context they already had, which defeats the purpose of async in the first place.
How This Maps to the Customer's Actual Journey
Async agent UX isn't just a moment-in-time interaction problem — it sits inside a broader arc of trust that builds or erodes across a session and across repeated use. Mapping that arc explicitly, the way our customer journey guide describes for product experiences generally, surfaces where an emotion dip is most likely: typically right after the plan preview (will this actually do what I asked?) and right before notification (did it work, and do I need to fix anything?). Designing extra visibility at exactly those two points does more for trust than polishing the middle of the log.
Where Prodinja Fits Into Async Agent Design
That design choice is a direct, honest illustration of the plan-preview pattern this article argues for — visible intent is what lets a user extend trust to a process they can't watch every second of. It's one part of a broader prototype that also includes real, usable computing tools like Spec Studio for living PRDs with readiness gates, and RICE/Kano prioritization scoring, alongside simulated-experience layers (like stress-testing a spec) that are presented as intended prototype flows rather than as claims of a finished production AI pipeline.
Key Takeaways
- Chat UI is the wrong shape for multi-minute agent tasks — it assumes continuous attention and cheap interruption, neither of which holds once a job runs for several minutes.
- A plan preview before execution turns a silent black box into a checkpoint where a user can catch a misread instruction before any action happens.
- A timestamped activity log beats a spinner every time — it makes both progress and non-deterministic branching legible instead of hidden.
- Interruption should be checkpoint-based and resumable, not an emergency hard-kill that discards all progress or nothing at all.
- Completion notification needs to reach the user's actual attention — push, email, or team-channel delivery, not just an in-app badge nobody's looking at.
- Reversibility flags per step let users judge risk honestly instead of trusting a uniform "AI is working" message that hides which actions are safe.
- Visible intent, illustrated by how Prodinja is designed to surface an agent's plan for review, is what sustains trust across a task the user can't watch continuously.
Frequently Asked Questions
What is async agent UX?
Async agent UX is designing an AI agent's interface like a background job — with a visible plan, a running activity log, interrupt controls, and a completion notification — instead of a real-time chat conversation. It applies whenever a task takes long enough that continuous user attention can't be assumed.
Why does a spinner fail for long-running AI agents?
A spinner communicates only that something is happening, not what, how far along, or whether it's stalled. Past roughly 30 seconds, that gap between "activity" and "informative feedback" starts costing user trust, which is exactly what Nielsen's visibility-of-system-status heuristic warns against.
How should you design interruption for an AI agent?
Design interruption around checkpoints — natural boundaries between plan steps — rather than an arbitrary instant, so pausing never leaves the task in a half-mutated state. Offer at least a pause-at-next-checkpoint option and a resumable session, not just a hard cancel.
Should agent progress be shown as a percentage or a log?
A log is usually more honest than a percentage bar, because agent tasks branch non-deterministically and a fixed percentage implies a fixed, known path. Pair a lightweight step checklist (which step is active) with a timestamped log rather than promising false precision with a numeric percentage.
How is agent notification different from a normal app notification?
Agent task notifications need to reach the user wherever their attention has moved to since the task started — push, email, or a team channel — because the whole point of an async task is that the user stopped watching. The notification should also summarize the outcome and link back into session state, not just announce that something finished.