Skip to main contentSkip to footer
Application GuideUX Pattern

Make delegated work visible enough to trust, steer, and resume.

Silent agents lose trust the moment the user can't tell what's happening. Async execution must surface its own state: started, progressing, blocked, complete.

By ·

Key Facts

Best fit
Product and platform teams shipping async agents in web, desktop, or internal tools
Primary risk
Silent progress ambiguity
Core shift
Hidden execution → persistent run visibility
Success signal
Users can tell what is running, waiting, blocked, or done without reopening a transcript
Doctrine mapping
P2, P3, P6, P8

Silent agents erode trust faster than bad outputs

The most common production complaint about agentic systems is not usually model quality. It is silence: your agent disappears into the background, users lose confidence, and they start prompting again just to check whether anything is happening. Strong background work visibility fixes that by giving delegated work a persistent presence across states, surfaces, and interruptions, while keeping feedback proportionate to attention and risk. Written by the AI Design Blueprint editorial team. Doctrine grounded in the 10 Blueprint Principles.

Make delegated work visible enough to trust, steer, and resume.

Why background work visibility matters now

Silent agents create the most common trust complaint in production: users cannot tell whether work is running, stuck, or finished. Once delegated work leaves the foreground, your interface must keep it perceptible through persistent, proportionate signals rather than forcing people to reopen chat or guess. P2 – Ensure that background work remains perceptible and P3 – Align feedback with the user’s level of attention define the baseline.

Delegated work now spans research, drafting, code generation, and multi-step tool use, so background execution is a normal state rather than an exception.
If status is only visible inside a transcript, users re-prompt for reassurance, duplicate work, or abandon successful runs mid-process.
Persistent signals can stay lightweight: taskbar badges, activity center rows, run chips, inbox updates, or completion toasts tuned to attention level under P3 – Align feedback with the user’s level of attention.

Why the standard approach fails

The standard pattern is still a foreground chat plus a generic spinner, with users expected to poll for updates by returning to the thread. That breaks as soon as work becomes asynchronous, long-running, or interruptible, because the system stops being legible when the user looks away. P5 – Replace implied magic with clear mental models and P6 – Expose meaningful operational state, not internal complexity explain why this fails.

Polling burden: the user must ask “still working?” because the product does not push state changes when they matter.
State collapse: everything is rendered as thinking, even when the run is queued, waiting on a tool, blocked on approval, or complete.
Lost context: if a page, tab, or window changes, the only status surface disappears with it, violating P2 – Ensure that background work remains perceptible.
Hidden blockers: failures and approvals appear late or not at all, which directly violates P8 – Make hand-offs, approvals, and blockers explicit.

How Blueprint replaces silent background execution

Blueprint replaces silent background execution with a persistent run model that stays visible across surfaces and attention states. Instead of treating delegated work as a disappearing chat event, you represent it as an inspectable task with named states, milestones, blockers, and outcomes. P9 – Represent delegated work as a system, not merely as a conversation is the structural shift.

Give every delegated job a durable run object with user-relevant states such as queued, running, waiting on you, completed, failed, or canceled under P6 – Expose meaningful operational state, not internal complexity.
Use push-based visibility for state transitions, blocker alerts, and completion signals; keep polling as a fallback for reconnects, stale clients, or low-capability channels under P2 – Ensure that background work remains perceptible.
Match surface depth to attention: ambient badge when absent, compact progress row when glancing, full run detail when inspecting under P3 – Align feedback with the user’s level of attention and P4 – Apply progressive disclosure to system agency.
Make the next dependency obvious whenever the run cannot continue, following P8 – Make hand-offs, approvals, and blockers explicit.
Let users inspect what happened and steer the work mid-run through checkpoints, retries, and reprioritisation under P7 – Establish trust through inspectability and P10 – Optimise for steering, not only initiating.

How to implement

Implement background work visibility as a state system first, then map that system to the right notification surfaces. Your agent should emit meaningful run transitions, while the interface decides how loudly to surface them based on attention, risk, and reversibility. P3 – Align feedback with the user’s level of attention and P6 – Expose meaningful operational state, not internal complexity should drive the design.

Define a small operational state model before designing UI: queued, running, waiting on dependency, waiting on user, completed, failed, canceled.
Store run state separately from the chat transcript so the user can find work from task lists, activity centers, tabs, or operating-system surfaces under P9 – Represent delegated work as a system, not merely as a conversation.
Push milestone updates on transitions, not every token or low-level event; reserve high-interruption notifications for blockers, approvals, and completion under P2 – Ensure that background work remains perceptible.
Keep polling as a recovery path for offline clients, refresh after reconnect, or channels without subscriptions; do not make polling the primary visibility model.
Design one inspectable detail view with timing, last successful step, current dependency, and next expected event under P7 – Establish trust through inspectability.

Starter brief

Task
surface background execution for delegated research runs
Scope
run state, notifications, blockers, and result delivery across web and desktop surfaces
Escalate when
approval is required, confidence drops, or the run is blocked for more than 2 minutes
Success signal
users can identify queued, running, waiting, completed, or failed work without reopening chat

Escalation and governance tiers

Use these tiers to decide which background actions can continue with ambient visibility, which need visible checkpoints, and which must stop for approval under P8 – Make hand-offs, approvals, and blockers explicit.

Tier 1 — AutonomousReversible background retrieval, summarisation, and draft assembly with visible statusLowPre-approved at task start
Tier 2 — CheckpointedMulti-step work that may affect shared artifacts, priorities, or customer-facing draftsMediumApproval at named checkpoints or before publish
Tier 3 — Approval-gatedExternal sends, production changes, regulated actions, or irreversible commitmentsHighExplicit human approval for each action

Anti-patterns vs. Blueprint patterns

Use this comparison to replace invisible async behavior with inspectable, user-relevant visibility patterns grounded in P2 – Ensure that background work remains perceptible and P6 – Expose meaningful operational state, not internal complexity.

Anti-pattern
Chat transcript as the only execution surface
Blueprint pattern
Persistent run view with status visible from task lists, activity centers, or system surfaces
Anti-pattern
Generic spinner that means everything and nothing
Blueprint pattern
Named operational states such as queued, running, waiting on user, blocked, and completed
Anti-pattern
User must poll the thread to learn what changed
Blueprint pattern
Push-based milestones and blocker alerts, with polling only as fallback recovery
Anti-pattern
Progress disappears when the user switches context
Blueprint pattern
Ambient persistent signals such as badges, rows, or notifications that survive navigation changes
Anti-pattern
Failures appear only after timeout or abandonment
Blueprint pattern
Explicit blocker state with reason, required action, and resume path

Real-world proof

Illustrative scenario

These anonymised traces show how visible background execution changes intervention timing and trust.

Team used a desktop research workflow with a persistent taskbar badge and run drawer. Agent attempted a multi-source brief in the background. System surfaced a blocker when one source required a new login, then resumed after approval. The team stopped sending duplicate prompts and completion time became predictable.

Team used an internal operations assistant that originally exposed status only inside chat. Agent attempted a long-running reconciliation task. System was redesigned to push checkpoint updates into an activity feed and mark waiting-on-user states explicitly because a manager often stepped away mid-run. Follow-up interruptions dropped and fewer runs were abandoned.

Frequently asked questions

Common implementation questions for teams adopting background work visibility.

What is background work visibility best for?

It is best for any delegated task that continues after the user shifts attention: research, drafting, coding, reconciliation, or multi-step tool use. The goal is not constant interruption; it is persistent legibility. P2 – Ensure that background work remains perceptible is the core requirement.

Do I need push notifications for every agent event?

No. Push should be reserved for meaningful transitions such as started, blocked, approval needed, completed, or failed. P3 – Align feedback with the user’s level of attention means low-value churn should stay in a quiet detail view, not in interruptive notifications.

When is polling acceptable?

Polling is acceptable as a fallback for offline recovery, reconnect behavior, legacy channels, or low-priority refresh. It becomes a design failure when the user must manually poll just to know whether work still exists. In Blueprint terms, polling supports resilience, but push carries visibility.

How much status detail should the default view show?

Show the minimum needed to answer the user’s first question: what is happening, whether anything needs them, and when the next update is likely. Then let them expand into timeline, evidence, and step-level detail when confidence or intervention matters. That is P4 – Apply progressive disclosure to system agency.

How do I expose state without leaking internal complexity?

Translate execution into user-relevant states and dependencies rather than raw tool logs, tokens, or stack traces. ‘Waiting for your approval’ is actionable; ‘tool call pending promise resolution’ is not. P6 – Expose meaningful operational state, not internal complexity should be your filter.

What should happen when the agent is blocked?

The blocker should become the most visible part of the run, with the reason, required action, and resume path all obvious. Do not leave the task looking active if it cannot proceed. P8 – Make hand-offs, approvals, and blockers explicit is the governing rule.

How do I know the visibility design is working?

Measure fewer reassurance prompts, fewer abandoned runs, faster time-to-resume after interruption, and higher successful completion for long-running tasks. Also test whether users can correctly name the current state without opening logs. If they can, you have stronger mental models under P5 – Replace implied magic with clear mental models.

Getting started checklist

  • Define one async workflow where users currently ask for reassurance or reopen chat to check status.
  • Create a small run-state model with user-relevant labels, following P6 – Expose meaningful operational state, not internal complexity.
  • Add one persistent visibility surface outside the transcript, such as an activity row, badge, or task list entry.
  • Trigger push updates only for transitions, blockers, approvals, and completion, following P3 – Align feedback with the user’s level of attention.
  • Keep polling as a recovery mechanism, not the main status model.
  • Test interruption scenarios where the user switches tabs, closes the app, or returns hours later.
  • Open Blueprint to validate your architecture.
Validate architecture

Next steps

Start with one high-friction async workflow and make its background execution visibly legible before you expand to every agent feature. Teams usually get the fastest gains by naming states clearly, pushing only meaningful updates, and exposing blockers early. P2 – Ensure that background work remains perceptible and P10 – Optimise for steering, not only initiating should shape the rollout.

Instrument drop-off points where users re-prompt, abandon, or duplicate delegated work.
Add one ambient surface, one glanceable surface, and one inspectable surface for the same run.
Review which transitions should be push-based and which can remain passive or pull-based.
Validate approval boundaries and blocker handling before increasing autonomy under P8 – Make hand-offs, approvals, and blockers explicit.

Apply the doctrine

Complete Foundations

Ensure that background work remains perceptible

Read →Validate in Pro

Align feedback with the user’s level of attention

Read →