Long background jobs should not stream; they need progress and permission to leave

What it is

A twenty-minute analysis still dribbling tokens into a chat bubble forces people to watch the bubble and not close the page. A long job does not want first-token comfort. It wants progress and a right to leave: where we are, a magnitude of remaining, who will notify me after I close. Streaming a long job is staging background work as a foreground performance.

Inside the second-scale band, streaming is a perceptual tool. Out of the band, streaming becomes internment.

Why it happens

A stream is bound to a session: a connection, a scroll position, foreground attention. A background job is bound to a work item: disconnectable, movable across devices, callable when done. Reverse the bindings and people either spend their right to leave on those emitting words, or leave and lose progress and the result. Failure modes differ too: what should be reported is a stage and a recoverable checkpoint, not a half sentence.

Progress must be true stage progress, not token count painted as a percent. Tokens have almost nothing to do with “how much longer” once tool calls and queues sit in the way. Fake progress freezes in the tail and looks more stuck than none.

Studying it

The same twenty-minute task: in-chat stream versus a work item with stage progress and a notify-after-leave. Dependent variables: leaves, arrival at completion (people actually come back to the result), anxiety, false “it’s stuck.” Independent variables: progress as stages versus a fake percent, notify channel.

Arrival is the primary endpoint. A stream arm where nobody left is not “more engaged”; ask whether they could have left.

Where it stops holding

If someone explicitly wants to watch intermediate reasoning, an optional read-only stream can exist; the default is still a leavable work item. A one- or two-minute task still near the band can stream or take a short progress. True background with no live signal at all will be judged dead — the other extreme. This entry takes streaming off long jobs. It does not deny streaming’s perceptual value on short generation.

Applying it

• Tasks estimated over about thirty seconds, or with several tool steps, become work items: stage names, leave allowed, notify on complete. Do not squeeze them into a bubbling stream.
• Progress is stages (retrieving / analysing / writing the report), not a token percent.
• After leave, the result lands in an inbox or a task list and is there next open, not depending on that TCP connection.
• Check: give a twenty-minute task and see whether people can go do something else and be called back. If they cannot, the stream is internment. Then watch whether the bar freezes in the last 20% — frozen, the percent is fake.

Related

• Same group: L1.12.1 Generation latency sits in the felt-wait band · L1.12.2 Streaming shortens TTFT, not duration · L1.12.3 Streaming invites premature judgement · L1.12.4 Mid-stream self-correction shows overturned content
• Nearby: L4.12 Task progress and intermediate-state visibility · L3.11 Streaming the generation process · I3.07 Background tasks
• Search terms: background job not stream · progress and leave · TTFT versus long task