Streaming Intermediate Steps From the Loop

A team shipped a capable research agent that took about forty seconds to finish a real query — and watched users abandon it in droves. The agent wasn't broken. It was silent. For forty seconds the interface showed a spinner and nothing else, and users did what anyone does when software goes quiet for that long: they assumed it had frozen, and they left. The fix wasn't making the agent faster. It was streaming agent loop steps to the interface so users could see it working. Abandonment dropped overnight, on the exact same forty-second agent.

Streaming intermediate steps means surfacing the agent's progress — the tool it's calling, the finding it just made, the step it's on — to the user as it happens, instead of hiding everything until the final answer. It doesn't change how long the work takes. It changes whether the wait feels like progress or like a hang. This is the story of that fix.

The Problem the Team Faced

The research agent did genuinely useful multi-step work: several searches, some reading, a synthesis. End to end, forty seconds. The team was proud of the quality and baffled by the usage numbers — people started queries and didn't wait for answers. Session recordings told the story: users stared at a motionless spinner, waited maybe ten seconds, and closed the tab.

The problem was entirely perceptual. Forty seconds of useful work presented as forty seconds of nothing reads as broken, because users have no way to tell a working agent from a hung one when both show the same spinner. The agent was doing everything right and communicating none of it. Trust collapsed in the silence.

What made it especially frustrating is that the failing metric — abandonment — pointed nowhere near the actual cause. The dashboard said "users don't finish queries," which reads like a relevance or quality problem, and a team chasing that reading would tune the model, rework the ranking, rewrite the prompts, all while the real issue was a blank spinner. The gap between the symptom (abandonment) and the cause (silence) is exactly why perceived-latency problems go misdiagnosed for so long.

The Wrong Approach

The team's first instinct was to make the agent faster — cut steps, use a quicker model, trim the work.

Do fewer searches and answer faster, even if less thoroughly.

What this does: sacrifices the agent's quality to shave the wait — trading away the thoroughness that made the agent worth building, to fight a problem that was never really about speed.

It helped the numbers a little and hurt the product. The faster agent gave worse answers, and users still abandoned during the shorter-but-still-silent wait, just slightly less often. They were solving the wrong problem: the issue was never the forty seconds, it was the forty seconds of silence. You can't win an abandonment problem by degrading the thing users came for.

⚠️ Common mistake: Treating a perceived-latency problem as an actual-latency problem. When users abandon during a wait, the instinct is to make the wait shorter — but often the wait is fine and the silence is the problem. Shortening a silent wait helps far less than filling it with visible progress. Diagnose whether users are leaving because it's slow or because it looks dead.

The Correct Prompt

The fix was to stream each loop step to the interface as it happened — turning invisible work into visible progress.

[object Object], ,[object Object],(,[object Object],):
    ,[object Object], step ,[object Object], agent_loop(task, model):
        ,[object Object], step.,[object Object], == ,[object Object],:
            emit(,[object Object],)     ,[object Object],
        ,[object Object], step.,[object Object], == ,[object Object],:
            emit(,[object Object],)        ,[object Object],
        ,[object Object], step.,[object Object], == ,[object Object],:
            emit(step.summary)                                ,[object Object],
        ,[object Object], step.,[object Object], == ,[object Object],:
            emit_final(step.content)
    ,[object Object],

What this does: emits a human-readable message at each step of the loop — what it's searching, what it found, what it's concluding — so the user watches the agent work in real time instead of staring at a silent spinner.

[object Object],
agent.on_step(,[object Object], msg: status_feed.append(msg))

What this does: wires each streamed step to a live status feed in the interface, so progress lines appear as the agent produces them and the wait becomes a visible sequence of actions rather than a blank pause.

Results and What Changed

Abandonment during the wait dropped sharply — on the same forty-second agent, doing the same work at the same speed. Nothing about the agent's performance changed; only its visibility did. Users who could see "Searching pricing data... Found 12 results... Comparing options..." waited happily, because the agent now looked alive and purposeful instead of frozen.

There was a bonus the team didn't expect: trust in the answers went up too. When users watched the agent search real sources and gather real findings, they believed the final answer more than when it materialized from a silent void. Showing the work turned out to be its own form of credibility.

That credibility effect is a real, if underappreciated, reason to invest in streaming agent loop steps beyond the abandonment fix. A final answer that appears from nowhere asks the user to trust a black box; a final answer that arrives after they've watched it search, read, and compare feels earned. The visible process becomes evidence. For agents whose output users have to act on — research, recommendations, analysis — that earned trust can matter as much as the abandonment numbers that justified the work in the first place.

⚡ Pro tip: Stream human-readable summaries, not raw internals. "Searching: competitor pricing" builds confidence; a raw JSON tool call or a stack trace erodes it. Translate each step into a short, plain-language status line written for the user, not a dump of the agent's guts.

How to Apply This to Your Situation

Any agent that takes more than a few seconds and shows the user a spinner is a candidate. The signal is a wait long enough that a user might doubt whether anything is happening — roughly anything past five to ten seconds of silence. If your agent works in steps and those steps take real time, stream them.

Map each loop event to a user-facing message: tool calls become "doing X," observations become "found Y," thoughts become "considering Z." Keep the messages short, plain, and honest — they should reflect what's actually happening, so a user watching them learns to trust them. The goal is a live narration of real work, not a fake progress bar.

The honesty part matters more than it first appears. Streaming agent loop steps only builds trust if the stream is true — if the status says "Searching pricing data" while the agent does something else, users notice the mismatch and trust erodes faster than silence ever eroded it. This is the opposite of a fake progress bar that inches along on a timer regardless of real work. A real step stream is a promise that what you're shown is what's happening, and keeping that promise is exactly why it earns the credibility a spinner never could.

⚡ Pro tip: Buffer rapid-fire steps so the feed stays readable. An agent that fires ten quick tool calls in two seconds shouldn't flash ten lines faster than anyone can read. Coalesce bursts into a steady, human-paced stream — the goal is a feed a person can follow, not a strobe of raw events.

⚡ Pro tip: Stream a meaningful first status within the first second or two. The most dangerous stretch is the opening silence before anything appears — get one honest "Starting research..." line out immediately, so the user never faces even a few seconds of the dead-spinner ambiguity that makes them leave.

Next Steps

Take an agent with a noticeable wait and stream its steps: emit a readable status at each tool call, observation, and thought, and render them as a live feed. You don't need to change the agent's logic at all — just surface what it's already doing. Watch whether users wait longer, because they usually do.

That's the part worth emphasizing: this is one of the rare product wins that's pure upside. You're not trading quality for speed, or cost for latency — the agent does identical work at identical speed, and you're simply choosing to show it. The engineering is a thin wrapper over a loop you already run, and the payoff is measured in users who stay to see the answer instead of leaving during the silence. Few changes this small move an abandonment number this much.

⚡ Pro tip: Instrument abandonment by step, not just overall. Logging which streamed step users were on when they left tells you exactly where the wait feels too long — maybe the opening search is fine but a slow synthesis step loses people. Then you know precisely which step to speed up or narrate better, instead of guessing.

The streaming wrapper and the event-to-message mapping are reusable across every agent with a real wait. I keep them saved and versioned in PromptABCD, so a new agent narrates its work from day one — instead of hiding forty seconds of genuine effort behind a silent spinner that makes users leave before they ever see the answer.