UX: Group multiple consecutive web search cards into a single collapsible container

[403errors]

When a query triggers multiple sequential web searches, the UI generates a separate UI card for every single query executed. As seen in the attached screenshot, this creates significant visual clutter, unnecessarily stretches the vertical length of the chat history, and disrupts the overall user experience.

Solution
Instead of rendering individual cards for every search, consecutive web searches should be batched or grouped into a single, unified "Web Search" container.

• The parent container can show an aggregated status (e.g., "Searching the web... (4 queries)").
• Expanding the container should reveal the list of individual search queries executed.

Steps to reproduce

1. Enter a complex prompt that requires multi-hop verification or multiple separate search terms.
2. Observe the chat output rendering individual, repetitive "Web search" cards stacked vertically.

Visual Evidence

Suggested UX Improvements

• Collapsible Accordion: Wrap all concurrent/consecutive searches into one accordion component.
• Compact Styling: If keeping them separate, reduce the padding, margins, and border footprints for consecutive cards so they look like a single connected timeline or list.

[dubeyharshit0605]

@403errors Hi, I’m interested in working on this issue. I’d first trace how consecutive web-search events are represented and rendered, then propose a tested approach for grouping them into a collapsible container. Is this issue available for contribution?

[403errors]

Yeah sure buddy.

[dubeyharshit0605]

@403errors Thanks! Before I begin implementation, could a Rowboat maintainer please confirm that this issue is available for an external contribution and that nobody else is currently working on it? Once confirmed, I’ll investigate the rendering flow and share my proposed approach.

[arkml]

@dubeyharshit0605 it's available for external contribution. Please share your proposed flow!

Thanks - appreciate it!

[dubeyharshit0605]

@arkml Thanks! I traced the current rendering flow. getWebSearchCardData creates data for one search card, while groupConversationItems already groups consecutive ordinary tool calls but explicitly excludes web-search calls.
My proposed approach:
Add a dedicated web-search group type for two or more adjacent web-search tool calls. A message or different tool call would end the group, while a single search would continue using the existing card.
Add a shared collapsible group component showing an aggregated state and query count. Expanding it would expose each query and its existing result details.
Use the shared grouping behavior in the main chat and chat sidebar, and update the separate code-chat rendering path for consistency.
Add focused tests for a single search, consecutive searches, groups separated by messages or other tools, and mixed running/completed/error states.
Run the renderer lint and type-check commands before submitting.
Does this grouping boundary and three-surface scope match what you expect?

[arkml]

@ramnique ^^