Overview

Add an inspectable tool timeline to the Hermes CLI so users can reopen any prior tool call, tool result, or intermediate tool event after it has rendered. This would move Hermes closer to the strongest OpenCode/Claude Code-style UX pattern for agent CLIs: tool activity stays compact in the main transcript, but the full underlying event is always recoverable on demand.

Right now Hermes already emits a lot of useful tool activity, but most of it behaves like transient terminal output. Once a tool line scrolls by, truncates into a preview, or gets visually compressed into a single summary row, the user loses easy access to the complete arguments/result that drove the agent's next decision.

This is one of the highest-leverage CLI UX improvements available for tool-heavy sessions because it makes existing tool data meaningfully more usable without changing model behavior.

---

Research Findings

What Good Agent CLIs Do

The common pattern in stronger agent CLIs is not simply “show tool output.” It is:

• render compact event summaries during normal flow
• preserve a structured history of tool events
• allow reopening the exact call/result later
• give the user enough fidelity to audit why the agent chose a path

For tool-heavy workflows, this matters as much as nicer rendering. Recoverability is the feature.

The Pattern

The UX pattern here is a persistent, inspectable timeline: terse summaries in the main transcript, with full detail available via selection/expansion/focus. The key win is preserving historical access to tool events after the live moment has passed.

---

Current State in Hermes Agent

The current CLI already has most of the display primitives needed for this, but tool activity is still presented as ephemeral text rather than as a first-class inspectable timeline.

Existing CLI layout primitives

The prompt_toolkit layout in cli.py:4226-4470 already composes multiple dynamic Window / FormattedTextControl blocks:

• spinner_widget (cli.py:4226-4229)
• clarify_widget (cli.py:4331-4337)
• sudo_widget (cli.py:4359-4365)
• approval_widget (cli.py:4413-4419)
• input-region composition in the main HSplit (cli.py:4457-4470)

So the UI layer already has a precedent for dynamic, state-backed panels instead of plain print-only output.

Existing tool rendering is summary-first

agent/display.py already contains the compact display logic that this feature would need to build on:

• build_tool_preview() in agent/display.py:66-164 extracts a primary argument and truncates it for compact display
• get_cute_tool_message() in agent/display.py:388-537 renders the one-line per-tool activity stream shown in quiet mode

That means Hermes already knows how to derive compact tool summaries — but those summaries are currently terminal-oriented output strings, not stable timeline records.

Existing pain point

Pain points today:

• tool calls and emitted states are easy to miss while a run is active
• long tool outputs are difficult to revisit once they scroll by
• truncated previews in build_tool_preview() intentionally discard detail for readability
• get_cute_tool_message() gives a good one-line summary, but not a path back to the underlying call/result payload
• users cannot cleanly reopen a specific historical tool event and inspect its full data

This is especially painful for:

• multi-step terminal tasks
• large diffs and patch previews
• browser/web/delegate outputs with substantial detail
• debugging why the agent changed direction after a specific tool result

Architectural implication

Today the display path is optimized around “render a line now.” This feature requires shifting toward “record an event, render a summary of it now, and preserve the event for later inspection.”

Likely affected areas:

• cli.py — prompt_toolkit state, layout, keybindings, focused views
• agent/display.py — reusable summary/event formatting
• tool preview / event formatting paths
• possibly session/UI-side storage for retained tool timeline metadata

---

Implementation Plan

Skill vs. Tool Classification

This is a core Hermes CLI change, not a standalone tool. It likely needs a small event model for tool activity plus CLI rendering/interaction support for reopening historical entries.

Specification

Represent tool activity as structured timeline events rather than only one-shot rendered lines.

Each event should retain:

• event ID
• event type (tool_call, tool_result, tool_progress, maybe tool_error)
• tool name
• timestamp / order index
• compact summary text for transcript rendering
• full underlying payload/result needed for later inspection

Core behavior:

• persist enough metadata for each tool event to reconstruct or display it later
• keep the compact transcript UX Hermes already has
• allow selecting a prior tool event
• allow opening the full tool call arguments
• allow opening the full tool result
• allow inspecting intermediate progress/state messages where available
• keep expansion behavior usable in narrow terminals, SSH, and tmux

UI direction

There are a few acceptable interaction models:

1. inline expand/collapse inside the transcript
2. focused details pane above the input area
3. modal-like expanded section for the selected event

Given the current layout structure in cli.py, a focused detail region or conditional container above the input feels like the lowest-risk first step because it matches the existing pattern used for clarify/sudo/approval panels.

Deliverables

• Introduce a structured tool-event timeline representation in CLI/UI state
• Assign stable event IDs and event typing for tool calls/results/progress entries
• Refactor tool display flow so compact transcript rows are derived from stored events rather than being the only representation
• Add a focused inspection view for the selected historical tool event
• Support full-view inspection for tool call args and tool results
• Add keyboard navigation for selecting/opening past events
• Add mouse interaction if practical within prompt_toolkit constraints
• Handle very large payloads with scroll/truncation/full-view fallback cleanly
• Validate behavior in narrow terminals, tmux, and SSH
• Add tests covering event retention, rendering, and inspection behavior

Suggested implementation split

Phase 1:

• define timeline event model
• retain events in CLI state
• expose keyboard-driven inspection for completed tool call/result pairs

Phase 2:

• mouse support
• better formatting for diffs / JSON / logs
• grouped views for delegate/background-process activity

---

Pros & Cons

Pros

• High-value UX improvement for every tool-heavy session
• Makes debugging dramatically easier without requiring model changes
• Preserves compact output while still exposing raw detail when needed
• Helps users audit why the agent took a specific action
• Creates a foundation for future search/filter/export over tool history
• Reuses existing Hermes strengths instead of inventing a new subsystem from scratch

Cons / Risks

• Requires careful prompt_toolkit interaction design to avoid awkward navigation
• Storing full event payloads may increase per-session UI memory footprint
• Very large tool outputs will need explicit policies for truncation, paging, or lazy loading
• Inline expansion could become visually noisy if not designed carefully
• Terminal compatibility needs testing in tmux, SSH, and narrow layouts
• Streaming/in-progress events complicate the model if we want them inspectable before completion

---

Open Questions

• Should the first version use inline expansion, or a dedicated detail pane above the input?
• Should the timeline store raw payloads, formatted views, or both?
• How should actively streaming tool events behave before completion?
• Should event retention be bounded/configurable for very long sessions?
• Should this ship first for quiet-mode tool lines only, or for all tool activity surfaces?

---

Note

I will be picking up this issue

---

References

• Existing CLI dynamic layout patterns: cli.py:4226-4470
• Existing compact tool preview logic: agent/display.py:66-164
• Existing compact tool activity rendering: agent/display.py:388-537
• Related design precedent: issue Feature: CLI Status Bar & Token/Cost Tracking — Persistent Context Window Visibility #683 (strong CLI visibility / persistent context philosophy)
• OpenCode-style inspectable tool timelines in agent CLIs