[Feature]: Show reasoning and tool execution as separate agent steps #1169

Search existing issues

• I have searched the existing issues.

Is your feature request related to a problem?

When an AI edit takes several model and tool calls, it is difficult to tell whether the agent is reasoning, executing a tool, or waiting for a response. If a tool fails, the final response alone does not make it easy to see which step failed.

OpenScreen already has thinking, toolStart, and toolEnd events. The chat panel currently consumes thinking events live, while successful tool summaries appear with the completed reply. A unified, ordered view would make the existing execution lifecycle easier to follow.

Describe the solution you'd like

Add a collapsible execution-steps section for each agent turn, separate from the final answer and token usage summary:

• Show provider-exposed reasoning separately from tool calls, preserving their observed order. Do not invent reasoning for providers that do not expose it.
• Show each tool invocation with its name, a concise argument summary, running/succeeded/failed status, elapsed time, and a short result or error summary.
• Distinguish repeated invocations of the same tool, and update concurrent calls independently using stable invocation IDs.
• Keep the final assistant answer clearly separate from intermediate execution steps.
• Retain completed and failed steps on the originating project/session/turn, including when the user switches sessions during execution; restore them after restarting the app.
• Keep details collapsed by default and avoid storing raw provider payloads, credentials, or unrestricted tool output.

Example:

Execution steps
  Reasoning (expand, when provided)
  ✓ Read timeline          0.2s
  ✗ Detect silences        1.4s
    Audio file could not be read

Final answer
  Silence detection could not be completed...

Also support Markdown consistently for chat input and output:

• Let users write or paste multiline Markdown in the composer, preserving line breaks, indentation, and fenced code blocks when sending.
• Render user messages and final agent responses as Markdown, including headings, emphasis, lists, links, blockquotes, fenced code blocks, and tables.
• Render exposed reasoning and human-readable tool summaries as Markdown where appropriate; keep structured arguments and raw tool data in clearly formatted code blocks.
• Preserve the original Markdown source for copy actions and persistence rather than copying rendered markup.
• Render safely, without executing embedded HTML or scripts.

Suggested acceptance checks:

• A multi-call turn displays reasoning/tool steps separately from the final answer.
• A running tool updates in place when it succeeds or fails.
• Repeated and concurrent tool invocations are not conflated.
• Providers without exposed reasoning still show useful tool progress.
• Failed turns retain the completed steps and failure information.
• Switching sessions does not move steps into another conversation; restarting restores saved steps.
• Existing chat histories without execution steps remain readable.
• Multiline Markdown survives composing, sending, copying, switching sessions, and restarting without losing source formatting.
• User input and agent output render common Markdown elements consistently; code fences and tables remain readable.
• Markdown rendering does not execute embedded HTML or scripts.

Describe alternatives you've considered

A single generic "Thinking" indicator is simple but does not explain tool progress or failures. A full debugging console with raw requests and responses would be much broader than this proposal; a compact, collapsible steps view should be sufficient for the first version.

Additional context

This is inspired by the separation of reasoning, tool execution, and final output in agent harness workflows, including DeepSeek Harness. It should remain provider-agnostic and reuse OpenScreen's existing event flow, without introducing a new agent runtime or dependency on DeepSeek Harness.

Related: #1096 covers per-turn token accounting and persistence. This proposal covers execution visibility and would be a separate contribution.

DeepSeek's reasoning/tool-call API documentation is one reference for the separation of these event types: https://api-docs.deepseek.com/guides/thinking_mode/

I'd like to implement this and submit a focused PR. Maintainer feedback on the proposed scope would be welcome before implementation.