Progress for long AI tasks: how to show it is moving without inventing percentages

How to show progress for an AI agent that works for minutes or hours: real steps, verifiable states and pending decisions, with a bar only if it is measurable.

info Quick Definition
The progress of a long AI task is how the interface shows what the agent has done, what it is doing now and what is left, during work that can last minutes or hours. It must reflect real steps and verifiable states; an invented percentage is worse than showing nothing.

Why are long tasks a design problem?

A chat response lasts seconds. An agent that refactors a project, researches ten sources or prepares a campaign can work for hours, going through dozens of tools. During that time the person sees nothing, or sees an indicator that says nothing. Then they wonder whether it is still working, whether it got stuck or whether it did something it should not have.

Without a clear signal, the person cannot decide whether to leave the work with the agent or interrupt it. That is why progress is not decoration: it is the information used to decide whether to wait, step in or cancel.

Usability research has been saying something similar for decades. According to Jakob Nielsen, after about 10 seconds the user’s attention drifts and the system should show when it expects to finish (NN/g, Response Times). Katie Sherwin adds that an indicator with no defined end leaves people unsure whether the system is still working or has stopped (NN/g, Progress Indicators). Those rules were written for waits of seconds; with an agent that works for hours, the problem only gets worse.

Anthropic describes a close case with agents that cross several context windows: each new session begins with no memory of earlier ones, and the agent tended to declare the project done too early. Their answer was a progress file (claude-progress.txt) and a feature list the agent may only mark as “passing” after testing (Anthropic Engineering, November 2025). Seen from a design angle, that list works as a progress view anyone can review.

What progress can you measure for real?

Before designing a bar, ask what can be measured. There are three kinds of progress:

  1. Counted progress. Files processed out of a known total, tests that pass out of fifty, rows reviewed in a batch. Here a bar is honest.
  2. Step progress. A list of the plan’s stages: read, plan, edit, test, close. It works when the number of steps is stable.
  3. Open-ended progress. Research where nobody knows how many sources are missing. Here no percentage is possible; show steps and findings instead.

NN/g’s classic rule says percent-done indicators are for operations longer than about 10 seconds, and that when a series of records is processed, the bar should come with text such as “Updating address 3 of 50”. That rule assumes you can measure how much is left. With an agent you often cannot: the number of steps changes midway. If you do not know which kind of progress you have, do not use a bar. A list of real steps is almost always enough and does not lie.

For waits of a few seconds, loading states are the right tool; the progress view is for work that takes minutes or hours.

How do you design the progress view?

A good progress view answers four questions without the person having to open anything:

  • What has been done? Finished steps, with a short result: “Read 14 files, 3 relevant”.
  • What is it doing now? The current step, in concrete words, not “processing”.
  • What is left? The pending steps, or an estimate clearly labeled as one.
  • Is there something to decide? If the agent needs an answer, that goes to the front, separated from the rest.

That last question matters most. An agent waiting for a decision that shows it as “running” makes people lose hours. The interface must distinguish “working” from “waiting for a person”.

A real example of a step list is in Claude Code: the agent creates a task list to plan multi-step work, with pending, in-progress and complete indicators, which you show or hide with Ctrl+T and which displays up to five tasks at a time. That list is separate from the /tasks view, which shows the running processes and subagents (Claude Code, Interactive mode). They answer two different questions, “which plan is it following” and “what is running right now”, and are better not merged into a single bar.

What happens when the task lasts hours?

For long tasks, three practices keep the person from having to watch:

  1. A checkable record. Progress is saved somewhere the person can open whenever they want: a progress file, a commit history, a dashboard. It does not depend on having a tab open.
  2. Verifiable checkpoints. Each stage ends with a check, for example tests that pass, and only then is it marked as done. That way progress reflects quality, not just time.
  3. Notifications only for important events. Alert when there is a result, an error or a pending decision. Notifying every step turns the tool into noise. Claude Code, for example, lets you run a script when it sends a notification and distinguishes types such as permission_prompt, idle_prompt, agent_needs_input and agent_completed, so you can alert only on what matters (Claude Code, Hooks).

An agent working in the background also needs a way back to its state. The page on background agents describes that model, and the notifications that go with it are in agent notifications.

What should the bar NOT do?

  • Move with time. A bar that rises with the minutes elapsed measures nothing.
  • Reach 100% before the work is finished. If the work has not finished, the bar must not say it has.
  • Go backwards without explanation. If the total changed because the agent found more work, say so: “Now it is 40 files, before it was 30”.
  • Stay on “processing”. A state with no detail makes people interrupt or close the task.
  • Hang on the last percentage. NN/g warns that if the bar moves fast and then hangs on the final stretch, people get frustrated. With an agent this is even likelier, because the last work (testing, fixing) is often the slowest.

Example

Illustrative example: an agent migrates 120 components of an interface to a new library. The first version shows a bar that reaches 100% in forty minutes, but the agent keeps fixing errors for twenty more. The bar was lying from the start.

The team changes the view to two parts. At the top, a real counter: “78 of 120 components migrated, 6 with failing tests”. Below, the list of steps for the batch in progress: “Migrating the forms group, step 3 of 4: tests”. When the agent finds a component it does not know how to migrate, the view marks it in yellow with the question. The person answers in two minutes and the work continues.

When should you NOT use a detailed progress view?

When the task is short, a few seconds, a simple indicator is enough. And when the person is not going to watch the progress because the task can finish without them, a notification at the end with the result and a link to what was done is better.

Common mistakes

  • Using a percentage that does not correspond to measured work.
  • Showing “processing” for minutes with no detail.
  • Mixing “working” with “waiting for a person”.
  • Notifying every step, which ends in noise.
  • Not saving progress, and losing it if the session is cut.

Sources

Frequently asked questions

How do you show progress for a long AI task?
With a list of real steps and their status: pending, running, done or failed. When there is a reliable measure of progress, show it; if there is none, do not invent a percentage.
Is a progress bar useful for an agent?
Only if it reflects measurable work, such as files processed out of a known total. A bar that moves with time and has no relation to the work is misleading.
What should an agent show while it waits for the person?
That it is waiting, exactly what it needs and since when. A waiting state with no explanation looks like an error and makes the person close the task.
How do you handle a task that lasts hours?
By saving progress to a log the person can check, with verifiable checkpoints, and by alerting only when there is a result or a pending decision.