New request
#536: ux(chat): separate working/execution flow from final answer delivery
We'll provision a sandbox, run an agent against the issue, and open a draft PR. You can pull the branch and iterate from there.
Summary
The current chat experience mixes two very different things into one surface:
- the agent's long-running internal work (thinking, tool use, command execution, intermediate progress)
- the final user-facing conclusion
For agentic workflows, these should feel like two distinct UX stages rather than one continuous stream.
Proposed UX model
Stage 1 — Working / Thinking / Execution
This is the active process stage where the agent is still figuring things out and doing work.
The UI should make that legible as an ongoing process, for example:
- a visible "Working for ..." timer while the run is active
- a clear Thinking block for each reasoning/planning step
- sequential tool / command execution blocks
- short progress summaries after each execution round
- older low-level execution details collapsing into compact summaries as the run continues
The goal of this stage is not to present the final answer yet. It is to help the user feel that the system is actively progressing through a real task.
Stage 2 — Final Answer / Conclusion
Once the agent has completed enough internal work and is ready to answer, the UI should transition into a clean conclusion state.
At that point, the user should receive the final response as a stable, coherent answer rather than as just another continuation of the execution stream.
This distinction matters because the user experience of "watching the work happen" is different from the experience of "reading the answer."
Why this matters
Right now, many agentic UIs feel noisy because process visibility and answer delivery are mixed together.
A clearer two-stage model would improve:
- readability of long-running sessions
- confidence that the agent is making progress
- clarity of the final answer
- overall chat UX, especially for more complex coding / tool-using sessions
Interaction implications
This model also suggests different placement for interactive cards:
- Approve cards belong in Stage 1, because they are execution-time interruptions or permission gates
- Clarify cards seem better suited to Stage 2 (or the transition into Stage 2), because clarification is a higher-level decision point that should appear only after the agent has completed enough thinking to ask a stable, meaningful question
In other words:
- approvals are part of doing the work
- clarifications are part of stabilizing the answer path
Proposed direction
A good design goal may be:
Make the chat experience explicitly two-phase: first visible work, then clean conclusion.
This does not necessarily require copying Codex exactly. The important part is the interaction model:
- process visibility should feel structured and progressive
- the final answer should feel distinct, calm, and readable
Open questions
- Should Stage 1 remain fully visible, or partially collapse once Stage 2 begins?
- Should the final answer visually replace the live working state, or sit beneath it?
- Should Clarify appear as an inline system card, or as a separate transition state before the final answer?
- Should the timer span both stages, or stop when execution ends and answer delivery begins?
/cc @aronprins
Fundamental chat UX restructuring requires new frontend visualization stages, streaming state machine changes, and message formatting logic.
- static/js/chat/streaming.js
- static/js/chat/message_renderer.js
- static/js/components/execution_block.js
- static/css/chat.css
- api/streaming.py
- api/models.py
- tests/smoke/test_chat_streaming.js