When the status gets ahead of the work

Suppose an assistant prepares a report and submits it to a team channel after someone approves it. The interface marks the task complete when the share request leaves the product. The channel has not confirmed a post. The user sees completion at the one moment when the outcome is still uncertain.

Someone may leave assuming the report reached its audience or try sharing it again when they cannot find it. Marking the unconfirmed handoff complete has given them the wrong account of what the channel did.

The report may start streaming while data is still arriving and stop at a partial draft if a connection expires. Hours later someone may approve it. Each change gives the user a different decision to make. A live transcript alone cannot tell them what has been recorded and what still waits on someone else.

I would judge this interface by the decisions it leaves to the person using it. They need to know when to leave the report running and when to step in. On return they need to see what changed. That starts with a careful choice about what counts as progress.

What deserves to count as progress

A long task produces plenty of activity. Workers call tools while connections refresh and drafts change. A raw activity feed can be perfectly accurate while asking the user to act as its log parser. A spinner spares them that work and says almost nothing about who is waiting. I would promote an event to a visible milestone when it changes what the user can expect or do.

“Collecting data” may be enough while the report's connectors are working normally. “Waiting for you to reconnect the finance source” deserves more space because the task cannot proceed without that action. “Report ready for review” is another meaningful transition. Intermediate tool calls can remain in an expandable activity view. They do not belong in the primary progress line simply because they happened.

Refresh the page and the same task comes back with its latest milestone and any saved draft. Return the next day and the view shows whether work continued or now waits for a decision. The browser's connection to a live stream is incidental to that record.

A browser stream cannot serve as the task's memory. A long-running operation has an identity and a result that can be retrieved later. The product needs the same kind of record for a task whose user may leave and return. The stream is one way to watch it, not the record itself.

I would skip a percentage for the whole report because the agent may discover another source to query or pause for approval. The remaining work is not a known fraction of a fixed total. Recorded milestones tell the user what has happened without inventing an estimate. A percentage can still help when processing a known set of files as long as the screen says which step it measures.

“Collecting data” with a last update from a few seconds ago means something different from the same label after six hours. The last confirmed activity and the next expected check give that status some meaning. When the task is waiting for a person, the view says whose turn it is. Nobody should have to diagnose a stalled workflow by watching an animation.

The first words are provisional

Streaming lets someone read a draft and spot a bad direction while the agent continues working. It can also make unfinished text look like an answer. The agent might begin writing about a rise in support volume before the final data source returns. That source may change the conclusion.

I would stream the draft when early reading can help, with pending inputs visible beside it. The report moves out of draft state once it reaches a reviewable result, even if a missing source remains identified. That transition records completion of the writing, not certainty about every conclusion.

Later data may force the agent to revise a sentence the user has already read. Silently replacing it leaves them with a memory of the old claim and no sign that it changed. A material revision deserves a mark on the affected passage or a short change note when the completed draft appears. Minor wording changes need no ceremony. The threshold is whether someone might have acted on the earlier text.

The reader can still copy a provisional sentence before the agent revises it. The product cannot chase that sentence into a slide deck. I would keep the draft readable and hold back the built-in share action until the report is ready for review. That is a boundary the product can enforce. It makes the action under its control agree with the provisional status on screen.

When the agent is still checking facts that determine the report's main conclusion, “Comparing the latest figures” gives the user an account of progress without publishing a conclusion that may reverse. A product that streams every token because it can is letting transport behavior make an editorial decision.

Silence after the stream tells the user very little. The report might be ready, the connection might have dropped, or the task might be waiting for approval. The recorded task state has to settle which one occurred.

When the person can change the outcome

The report becomes a useful review point when the draft is ready and sharing it would take it outside the current workspace. Before then, the user can leave it running. An interruption becomes worthwhile when they can decide whether the report should be shared.

I want the report version and destination in front of the reviewer along with any missing inputs. They can edit the draft or choose another destination before deciding whether to share it. An edit after approval creates a new version that needs its own approval. Generic approval wording asks the person to infer too much about what follows. “Approve and share with the operations channel” gives the decision a scope.

An alert while the draft is still changing merely transfers the agent's wait to the person's attention. I would notify the user when the report is ready to review. Their decision can move the task forward then.

Approval can wait while the reviewer does other work. When they return, the task still shows the report version and destination they were asked to authorize. If the report changed while they were away, they review the current version before sharing. An approval tied to a vanished browser session would make an hours-long task depend on someone keeping a tab open.

An approved action still needs an outcome

Approval leaves two steps to report. The product sends a share request and later learns whether the channel posted it. The button animation is not part of the channel's acknowledgement protocol.

Approval records the person's decision and the version they authorized. The task can say the share was submitted once the request leaves the product. “Posted to the operations channel” needs confirmation from that destination. A link to the post would let the person check it. Confirmation says nothing about who read it. Without a reply from the channel, the share outcome remains unconfirmed while the product checks. A green success state would claim a fact the system has not established.

The user can still withdraw approval or edit the report until submission. After that, cancellation may stop future attempts but cannot promise to remove a post that might already exist. Offering to share again while the outcome is unknown could create a duplicate. The user can inspect the destination or wait while the product checks what happened. Another submission becomes available only when the product can establish that the first failed or that repeating the request cannot create another post.

The report can exist even if sharing fails. The finished draft stays available while the share is marked failed or unconfirmed. The person may use the report another way or share it later once the outcome is known. One task now contains finished work and an unresolved external action. A single success or failure badge would lose that distinction.

The next move has an owner

The finance connection needs renewed authorization. Repeating the tool call will not restore it, so the person who owns the connection has to reconnect it. If their organization has denied access, the task needs an administrator. A temporary outage can stay with the system while it waits or retries a bounded step. The unconfirmed share also stays with the product until it can establish what happened. Asking the user to submit it again would make an uncertain outcome their problem to diagnose.

Here I would say, “Finance connection expired. Reconnect to include those figures. The current draft is saved.” An administrator can follow a reference ID to more detail. Putting a stack trace or token name in the user's view makes the error longer and the next step no clearer.

Reconnecting one source gives the user a narrow recovery action. Restarting the whole report would discard work already done and might repeat unrelated calls. The partial draft is still useful if the source cannot be restored, so I would let the person inspect and save it. Sharing is a separate decision. The draft needs to carry the omission into that review, where the person can decide whether the report is useful without those figures. Polished prose is particularly good at concealing a gap in the data.

The returning user finds the latest confirmed state and partial report beside the available recovery action. The cancel control needs to say what it can stop. It might halt pending work or withdraw an unsubmitted action. Once the request reaches another service, cancellation may only be a request to that service. The product cannot promise to undo work the other system already accepted.

A useful test is to return after closing the page during report preparation or after losing the response to a share request. The person should find the current report and see whether sharing was confirmed. If they need a developer to read the logs before choosing a safe next action, the product has left their part of the task unfinished.

An agent can run out of things to say while its task remains open. The interface still owes the person an account of that work. It must keep the last established outcome and the next safe action available, even after the original conversation has ended.