Add user-friendly topics to Agent Mode steps

[marksftw]

Summary

When an Agent works on a task, Maple shows its reasoning and the tools it uses, such as Read and Shell. This feature will organize that activity into collapsible topics with names that explain, in user-friendly language, what the Agent is doing.

For example, instead of showing Thought followed by several separate technical tool calls, Maple could show a topic named Inspecting the agent timeline, with the related reasoning and tool calls available inside it.

The existing Thinking label remains while reasoning is in progress. After reasoning finishes, Maple asynchronously generates a friendly name that replaces only the Thought label.

Proposed experience

While the Agent is reasoning, the user sees a collapsed Thinking row:

▸ Thinking

The user can open it if they want to read the reasoning as it streams.

Once reasoning finishes, the active topic opens and related activity appears inside it:

▾ Inspecting the agent timeline
   ▸ Reasoning details
   ▸ Read · Completed
   ▸ Shell · Completed

A later reasoning phase creates a new topic:

▸ Updating the affected components

The final assistant response remains outside the topics.

Approval cards also remain outside topics and continue to appear as standalone, actionable cards:

Permission requested
Allow once · Deny · Cancel

Topic lifecycle

State	Displayed name	Topic default	Contents
Reasoning is streaming	Thinking	Collapsed	Reasoning is visible only if the user opens it
Reasoning completed; name pending	Thought	Open while active	Reasoning and individual tools are collapsed
Name received; topic still active	Friendly generated name	Open	Reasoning and tools remain independently collapsible
A newer topic or final response begins	Friendly name or Thought	Collapsed	Details remain available when opened
Tools appear without visible reasoning	Working	Open while active	Tool rows are independently collapsible

These are default states. Users can still open or close each topic, its reasoning, and each tool individually. Routine timeline updates and arrival of the generated name should not undo the user’s manual choice.

The active-topic default should be easy to change in a future UI update.

Topic grouping

Each reasoning phase creates one presentation-only topic:

• Following tools belong to that topic until the next reasoning phase or final response.
• Multiple tools can belong to the same topic.
• Tools without visible reasoning appear in a fallback topic named Working.
• Final assistant responses remain outside topics.
• Approval, system, and error cards remain outside topics and retain their current order.
• The existing timeline remains flat and unchanged; nesting is only part of the UI presentation.

Tool components retain their current names, statuses, details, and expand/collapse behavior.

Approval behavior

Approval cards should behave exactly as they do today:

• They remain standalone cards outside topics.
• They are never hidden when a topic is collapsed.
• Their placement and interaction do not change.
• They do not expand or collapse a nearby topic or tool.

Moving approvals into the composer is a possible future improvement but is not part of this issue.

Friendly-name generation

When a newly completed reasoning phase is observed, Maple requests one friendly name using auto:quick.

The request must happen asynchronously and must never delay:

• Tool execution or rendering
• Approval handling
• Timeline updates
• The final response
• Run completion

Information sent to OpenSecret

Send only:

• A bounded copy of the latest user request from the same turn
• A bounded copy of the completed reasoning text

Do not separately include tool inputs or outputs, file contents, permission data, the final response, or the complete conversation.

Usage accounting should follow the same OpenSecret policy as New Chat title generation. Maple should not add separate billing behavior.

Information required in response

The only required value is one short, plain-text action name. No separate reason or summary is needed.

The name should:

• Be a concise, single-line phrase
• Describe what the Agent is doing in user-friendly language
• Avoid technical tool names, raw commands, Markdown, or explanations
• Use the user’s language when practical

A valid name replaces only Thought. Raw reasoning, tool text, approvals, and all other content remain unchanged.

If generation fails or produces an invalid name, leave Thought in place. Do not show an Agent error or delay the run.

Local persistence

Persist valid names locally so they survive session switching and app restarts.

• Store names separately from timeline items and Goose messages.
• Do not store the user request or raw reasoning with the generated name.
• Reuse an existing name without making another model request.
• Do not generate names for old, unlabeled history.
• Remove stored names when the related Agent session or Agent history is deleted.
• Missing or corrupt stored data falls back to Thought.

Out of scope for this issue

These changes may be considered separately but should not be included here:

• Changing the stored timeline structure
• Redesigning approval cards
• Moving approvals into the composer
• Rewriting or removing raw reasoning
• Changing normal-chat reasoning UI
• Synchronizing generated names between devices
• Generating names for existing Agent history

Acceptance criteria

• Thinking defaults collapsed while reasoning streams.
• Users can open Thinking to view the existing reasoning text.
• Completed reasoning changes to Thought, then to the generated name.
• Only the Thought label is replaced.
• The active completed topic defaults open.
• Related tool rows appear inside the topic and remain independently collapsible.
• Approval cards remain standalone and unchanged.
• Final assistant responses remain outside topics.
• The underlying timeline stays flat and unchanged.
• Name generation uses auto:quick and never blocks the Agent.
• The request contains only bounded user-request and reasoning context.
• Valid names persist locally and are not regenerated.
• Failed or invalid generation leaves Thought in place.
• Opening old history does not trigger name generation.

[AnthonyRonning]

I don't think the proposed scenario makes sense because reasoning is separate from tool calling. I don't like the idea of hiding the tool calling inside of thinking as it is streaming in.

I think more thought should go into the streaming look vs finsihed streaming look, tool calling vs content vs reasoning. Because the rebric of scenarios here leaves a lot of edge cases.

[marksftw]

I'm fine leaving the tool calling in the main flow for now. I think long term we'll want hidden behind something by default. It ends up being lots of "shell" and "read" on the screen that the user doesn't always need to see.

Here's an example of lots of tool calls where it would be nice to know what's going on:

Often times the "Thought" area has a good explanation why the reasoning decided to launch the tools. I'd like to use that and surface a short version in the main UI flow so the user has more insight into what's going on.

For example, this "Thought" message is almost already good enough. Have gpt-oss make a shorter version and replace the "Thought" text.

[AnthonyRonning]

Feel free to try a couple things. I think there's a lot of iterative improvements that it would be easier to do instead of one big sweep but if you find an approach that looks and feels good then I'd be curious to see.

[marksftw]

okay, I'll try some steps along the way and see how it goes.