Long-Running Task Visibility: Designing a Floating Status Panel for AI Coding Assistants

1. The Problem: How Can Long-Running Tasks Be “Seen”?

As AI coding assistants become more capable, the nature of the tasks they handle has changed fundamentally. The interaction has moved from a simple question-and-answer exchange with second-level responses to a longer workflow:

1. The user defines a goal.
2. The assistant plans autonomously.
3. It performs multiple tool calls.
4. It produces a patch.
5. The user reviews the result.

Tasks of this kind often take minutes to complete. Complex refactors or multi-file changes can take even longer.

The issue is not simply that the user has to wait. The issue is an attention mismatch. In a traditional interaction model, progress can only be confirmed by returning to the main window and checking logs. This forces the user into one of two inefficient modes:

• Blocking wait: the user stares at the window, fully locked into the task and unable to do anything else.
• Blind switching: the user switches to other work but has no way to know the current task state, so they periodically return based on intuition. Each return also requires a full context rebuild.

The second mode is often underestimated. Every “let me go back and check whether it is done” moment involves window focus, finding the relevant log position, and re-understanding current progress. If a task takes 20 minutes and the user checks every minute, that creates nearly 20 unproductive attention switches.

The real pain point is not that the task is slow. It is that the task state lacks a low-cost, continuously perceivable external outlet.

There is also a second problem: parallel tasks. When a user starts three or four task threads at the same time, they need to know:

• Which task is running?
• Which task is blocked waiting for input?
• Which task is ready for review?

Without a unified view, one of the most common failure modes occurs: a task stopped ten minutes earlier waiting for confirmation, but the user did not notice. The entire workflow is silently blocked.

2. What the Panel Really Is: A Persistent Foreground Status Projection Layer

Treating this feature as “a decorative animation on the desktop” will lead the design in the wrong direction.

Its engineering essence is this: a lightweight status rendering layer that stays on top of the screen and is decoupled from the main application lifecycle.

The key difference from system notifications is time semantics.

• A notification is a one-time, transient, event-driven reminder. It appears and then begins to disappear.
• A status panel is a persistent, queryable snapshot of current state. At any moment, a quick glance can provide a definite answer.

Notifications answer “what happened?” A status panel answers “what is the current state?”

From an information perspective, the panel should carry only three types of information, and ideally no more:

1. Identity: which task or thread is currently being shown. This solves ownership confusion when multiple tasks run in parallel.
2. Status: whether the task is currently running, awaiting input, ready for review, or finished.
3. Brief progress: a one-sentence description of current progress, enough to judge whether the task is stuck without opening details.

The third item is the easiest to get wrong. It should not become a tail of raw logs. Scrolling logs contain far more information than a status panel can handle, and they may push users back to the main window, which defeats the purpose of the panel. Progress text should be a short summary derived from the state machine, not truncated raw output.

3. State Machine Modeling: Turning “Motion” Into Engineering Semantics

A personified or visually animated presentation layer can only be reliable if the underlying state model is rigorous.

A good practice is to replace boolean flags with an explicit status enum. Flags such as “is running” and “needs input” can easily create state explosion and invalid combinations.

type TaskStatus =
  | "planning"        // Planning: decompose goals and define steps
  | "running"         // Executing: call tools and modify files
  | "awaiting_input"  // Awaiting input: missing required information or authorization
  | "reviewable"      // Reviewable: changes are ready and awaiting human review
  | "succeeded"       // Completed
  | "failed"          // Failed
  | "cancelled";      // Cancelled
interface TaskSnapshot {
  threadId: string;        // Task or session identifier
  title: string;           // Short user-visible title (must be sanitized)
  status: TaskStatus;
  progressHint: string;    // Brief progress hint; recommended to limit length
  updatedAt: number;       // Last status-change timestamp
  heartbeatAt: number;     // Last heartbeat; used to detect zombie panels
}
// State is a projection of events, not the result of polling.
function reduce(state: TaskSnapshot, evt: TaskEvent): TaskSnapshot {
  switch (evt.type) {
    case "plan_created":   return { ...state, status: "planning", progressHint: evt.stepSummary };
    case "tool_started":   return { ...state, status: "running",   progressHint: evt.summary };
    case "approval_asked": return { ...state, status: "awaiting_input", progressHint: "Waiting for your confirmation" };
    case "turn_finished":  return { ...state, status: "reviewable", progressHint: "Changes are ready for review" };
    case "turn_failed":    return { ...state, status: "failed",     progressHint: evt.reason };
    default:               return { ...state, heartbeatAt: Date.now() };
  }
}

Two design choices are especially important.

First, the panel should subscribe to runtime events rather than poll the main window.

The task execution engine should emit structured events at key points:

• Plan created
• Tool started
• Tool finished
• Approval requested
• Turn finished
• Failure

The panel subscribes to these events and maintains its own snapshot projection.

This approach fully decouples the panel from the main interface. The main window can be closed or minimized, while the panel still holds the correct state. It also avoids low-frequency but persistent cross-process query overhead.

Second, “awaiting input” and “reviewable” must be modeled as independent states, not as substates of “running.”

These are the only two points in the task flow that require human intervention. They are also the highest-value information in the entire design. If they are collapsed into “running,” the panel loses much of its core value.

4. Interaction Design: The Minimum Usable Interaction Set

A window that remains in the foreground is naturally intrusive. Therefore, the interaction design should follow this principle: do not disturb by default, but make it easy to reach when needed.

The minimum usable set includes four elements:

• Always-on-top display and drag support: the window position should be persisted so that it does not occupy the same area every time the application starts.
• Click to return to the main interface: the panel acts as a shortcut to the main application. Clicking it should focus and locate the relevant task, and ideally also select the corresponding task thread.
• Multi-task switching: when multiple tasks exist, the panel should show the currently focused thread. Other tasks can be shown in a collapsed or count-based form to avoid turning the panel into a new management interface.
• Lightweight micro-feedback: hover or click should provide small animation feedback to confirm that the object is interactive.

The fourth item needs accessibility constraints.

Animations must support reduction or disabling. When the system enables “Reduce Motion,” the panel should automatically degrade to static highlighting.

The panel should also be keyboard reachable and have correct accessibility labels. State changes should be announced by screen readers.

A personified or character-driven presentation layer is essentially an emotional shell. It can reduce anxiety during long waits and improve the sense of task progress. However, it is still only a shell. This will be discussed further in the next section.

5. Implementation Concerns: Platform Differences, Performance, Privacy, and Reliability

This is the real threshold for moving from a demo to a deliverable product. It is also the part most easily overlooked.

Platform and Window Layer Behavior

System-level always-on-top capability depends on the window-layer APIs provided by the operating system and desktop environment. Implementations differ significantly across platforms.

The visibility of an always-on-top window may not be consistent in scenarios such as:

• Full-screen applications
• Multiple monitors
• Virtual desktop switching
• Remote desktop sessions
• Screen sharing

Engineering teams should explicitly enumerate these scenarios as test cases and provide policy switches such as:

• Show only on the primary screen
• Automatically hide during screen sharing

Do not assume that always-on-top equals always visible.

Permission Minimization

This type of window should prioritize only window-layer and focus-related capabilities.

Avoid requesting screen recording or accessibility permissions merely to “know what the main window is doing.”

The fewer permissions requested, the easier it is to pass compliance review in enterprise environments. If system-level information truly needs to be read, the purpose should be clearly explained, an off switch should be provided, and documentation should note any limitations on managed devices.

Rendering Performance and Power Consumption

A window that stays on screen 24/7 must be evaluated for long-term power cost.

The recommended approach is event-driven rendering rather than a fixed-frame-rate loop:

• No redraw when state has not changed
• Update only when events arrive
• Merge and throttle high-frequency events, for example by aggregating multiple sub-second tool-call events into one refresh
• Set an upper limit for animation duration

If a timer is used to refresh heartbeats, the interval should be measured in seconds, not frames.

Privacy and Sanitization

Text shown in the panel may come from task context. Therefore, progress descriptions must be sanitized and length-limited.

Do not display:

• Absolute file paths
• Credentials in commands
• Code snippets

In scenarios such as enterprise screen sharing, screen recording, or collaborative sharing, provide a one-click hide option or global mute.

This requirement should be written into the review checklist as a hard constraint, rather than left to the implementer’s judgment.

Reliability

The panel is a long-lived component. It must handle abnormal situations such as:

• Main process exit
• Crash and restart
• Process hang

The panel process should monitor the liveness of the main process and automatically recycle when necessary.

Snapshots should carry a heartbeat timestamp. If a task has not updated for too long, it should be marked as “state unknown” rather than continuing to display “running.”

Showing uncertainty explicitly is safer than presenting a wrong but definite answer.

6. Decouple Presentation Layer From State Layer

Personified characters, such as default characters, water drops, flames, rocks, or other preset images, should be understood as replaceable presentation themes, not as part of the core function.

The recommended architecture is:

• The state layer outputs standardized state and summary information.
• The presentation layer maps that state into images, animations, and copy.

interface Persona {
  id: string;
  // Only affects presentation; must not change state semantics.
  render(status: TaskStatus, hint: string): VisualState;
}

This decoupling brings three direct benefits:

1. Adding a new character does not require touching the state machine.
2. Copy can be switched by language or scenario, such as personal edition or enterprise edition.
3. Accessibility modes and low-power modes can be degraded uniformly at the presentation layer.

However, one boundary must be set: personification must not hide failure.

Cute character feedback must not replace error information. Failure states must be presented with clear text and actionable entry points.

Personification may only optimize the waiting experience during normal running periods. This is the dividing line between a toy and a production tool.

7. Decision Checklist: When Not to Build a Floating Panel

A floating panel is not a universal solution. It solves a specific problem under specific conditions.

The following questions can help decide quickly:

• Is the P50 task duration longer than about 30 seconds? If it is lower than this threshold, the benefit of the panel may be less than the cost of permanent screen occupation and implementation maintenance.
• Are parallel tasks real? In a single-task serial scenario, a progress indicator in the main window title bar or menu bar may already be enough.
• Do target users frequently switch between multiple applications for long periods? If the workflow is highly concentrated in a single window, the value of an external status outlet drops significantly.

If the decision is not to build a panel, several lighter alternatives may be preferable:

• Native system notifications: zero cost, but transient in meaning.
• Progress marker in the window title bar.
• Persistent icon in the menu bar.
• Writing status into the terminal title through escape sequences.
• Sound prompts at key moments.

These alternatives carry less information than a panel, but they are much less intrusive and much cheaper to implement.

For scenarios requiring cross-device synchronization or multi-person collaboration, aggregation and retention of state and summary information are better handled on the server side.

The task runtime can publish state-change events to a message queue. Logging services and monitoring alerts can then handle aggregation, retention, and anomaly notification. The client only subscribes and renders.

This keeps the panel itself stateless and naturally supports consistent views across multiple devices and reconnection after network interruption.

8. Phased Delivery Path

It is recommended to proceed in three phases. Each phase can independently deliver value.

P0: Usability Loop

This phase should include:

• Event-driven state snapshots
• A floating mini window
• Three core information items: identity, status, and brief progress
• Click to return to the main interface
• Automatic recycling when the main process exits

The acceptance criterion is: the user can accurately answer “What is the task doing? Does it need me?” without returning to the main window.

P1: Multi-Task and Personalization

This phase should include:

• Multi-thread switching
• Drag-position memory
• Visual encoding by state, especially making “awaiting input” and “reviewable” clearly different from “running”
• Automatic hiding during screen sharing
• Heartbeat timeout marking

P2: Presentation Layer and Experience Polish

This phase should include:

• Character themes
• Micro animations
• Reduced-motion and screen-reader support
• Multilingual copy
• Power optimization and low-battery mode degradation

Conclusion

A persistent foreground status panel may look like a playful interaction wrapper on the surface. In reality, it provides the status externalization channel that long-running autonomous tasks lack.

It turns an attention-management problem into a modelable state synchronization problem:

• Use an explicit state machine to eliminate invalid states.
• Use event projection instead of polling.
• Use a minimal interaction set to control intrusiveness.
• Use platform differences, power consumption, sanitization, and reliability constraints to ensure long-term viability.

The success criteria are also clear: the user reduces ineffective rechecks and no longer misses tasks that are waiting for confirmation.

When the panel can reliably answer “What do I need to do now?” it has moved from decoration to tool.