[Feature] Full activity for subagents

[AKolenda]

Full activity for subagents

A compact Agents panel with recent tools, saved child history, and final responses

Make the Agents panel a useful place to inspect delegated work: a compact roster by default, the latest tools when an agent is expanded, and a read-only full activity view that retains the agent’s final message after it finishes.

I built and tested an implementation in PR #10881 — show recent tools and saved child history. This discussion records the product request, design, implementation findings, and remaining gaps so maintainers can evaluate the idea separately from accepting that PR’s full diff. The reviewed implementation described below is at commit 3304f29b.

This is an implementation-backed follow-up to discussion #10507: inspect sub-agent prompts and live activity. That discussion already describes the underlying need well; this proposal adds a working UI, provider-specific findings, and evidence. It also relates to viewing tool/command output (#6682), nested subagent threads (#6689) and mobile subagent visibility (#6971).

Why this matters in everyday use

When several agents are working on the same project, a status, token count, and latest command are useful but incomplete. I need to know what each agent was asked to do, what it has checked, what it changed, and what it concluded—without asking the parent agent to narrate everyone’s progress or switching to provider-specific files and terminals.

For example, a parent delegates work to implement_offers and implement_documents. From the parent conversation I want to:

1. See which agent is active and which has finished.
2. Expand either card and glance at its recent tools.
3. Open its history to inspect the assignment, available messages, commands, results, and file edits.
4. Read its final response after it settles.
5. Return to the roster without interrupting the parent conversation or resuming the child.

The original panel was a plain roster with the most recent activity label. During development, a redesigned card could still show “no activity” even while the provider had a saved child transcript. That distinction matters: improving the layout alone cannot make the history appear.

Proposed interaction and design

1. Compact overview by default

Each agent has one card with its name, model/effort when available, readable status, latest activity or outcome, token usage, and elapsed time. Workflow members remain associated with their phases; direct spawns have their own group. Settled agents collect under a Finished disclosure so the roster gives active work priority.

An agent’s card begins collapsed. Looking at the roster should not require scrolling through command output or patches. Status must remain understandable without relying only on color. The current implementation treats idle agents as settled; that grouping is a product choice maintainers can review.

2. Expand a card for recent tools

Expansion shows the latest five tools, in chronological order, inside compact step boxes. The card reads the selected agent’s saved history rather than relying exclusively on attributed events in the parent’s retained activity list.

A muted, full-width Open full activity footer with a trailing chevron opens the detail view. This is the intended design shown below. Earlier intermediate versions used a bright inline link; those are not the proposed final footer.

Only mounted, expanded cards query recent history. Active cards refresh every ten seconds while the document is visible, and a card does not start a second refresh while its query is pending. This is periodic saved-history retrieval, not a claim of complete live child-event streaming.

3. Open full activity at the latest work

The detail view opens on the newest page of up to 50 entries and scrolls to the bottom. Previous/Next navigation makes older pages accessible, and Refresh retrieves another snapshot.

Tool output and file patches are collapsed behind clickable titles. Where the provider supplies structured file-edit information, the title identifies the affected path, such as Edit src/X.jsx; clicking exposes the available patch or tool details. Shell commands remain commands—we do not infer a reliable file diff from arbitrary shell text.

The agent’s messages, particularly its final response, stay expanded. Collapsing tool output must not hide the answer I opened the panel to read. Available reasoning summaries remain distinct from ordinary messages. An empty provider reasoning marker should not become a blank “Reasoning summary” card.

4. Preserve the conversation and explain missing history

History inspection is read-only. Opening a card must not create, resume, reload, or restart a provider coding session. Saved history should remain readable after the child stops, provided the environment still has the native history and can verify the child belongs to the parent.

Unsupported providers and unavailable/deleted histories need clear explanations. Neither case should pretend that the agent performed no work. The parent chat remains the place where the user continues the coding conversation.

Before and after

These are actual tester screenshots. The collapsed overview is the default; the lower row shows the two levels of additional detail.

Before — original Agents tab	After — collapsed overview
Expanded recent tools	Full agent details

Original light-theme design prototype

This is the design reference used while developing the feature, rather than a separate runtime verification. The screenshots above show the implemented Linux desktop UI.

Short interaction recording: expand recent tools, open full history, expand/collapse a patch, and return to the roster. Playback is sped up.

agent-activity-interaction.mp4

What the implementation revealed

The roster and the child’s detailed transcript are different data sources. A provider can supply enough progress information to update a card without supplying attributed child tool events to the parent’s activity stream. A progress summary can replace an earlier summary; it is not a durable tool history.

For Codex specifically, T3’s child-item handling supplied progress summaries while the activity presentation needed retained tool entries. Native saved child history was available through thread/read. The implementation therefore adds a separate on-demand history read, rather than trying to reconstruct a complete transcript from the current progress label.

This distinction also avoids making history depend entirely on the parent client’s bounded retained activity list. It does not remove native transcript availability, truncation, or provider protocol limitations.

Implementation approach in PR #10881

The client sends a typed, read-authorized orchestration.getAgentHistory request to the environment that owns the thread. The server uses the persisted provider-instance binding and resume metadata to select the correct adapter. Provider-specific interpretation stays at that boundary.

Adapters verify the selected child’s ancestry before returning its saved content. Responses normalize messages, reasoning, tools, and file edits into bounded entries. The implementation limits pages to 50 entries, titles to 500 characters, and details to 8,000 characters, with explicit truncation. Recent-tool previews use shorter details.

This is intentionally an environment-local read exposed through the existing WebSocket architecture. It does not assume that the browser can read the server’s filesystem or that localhost in the browser is the provider’s machine. Configured provider homes and credentials remain associated with the server’s provider instance.

Codex, Grok, and fallback OpenCode history reads share read-only transports per provider instance and working directory. They use a bounded pool of eight connections, release connections after 30 seconds idle, and release resources with the adapter’s scope. Initialization and reads have 20-second deadlines; failed connections are invalidated. This addressed review feedback that polling multiple cards must not repeatedly launch and terminate provider processes.

Provider support and confidence

Provider	Implemented path	Validation and limitations
Codex	Native thread/read, with child ancestry verification and an initialize-only history transport.	Checked against saved native history and tested with a fake native CLI for connection reuse and absence of session-start/resume calls. Reasoning uses the supplied summary, or native text when the summary is absent; empty entries are omitted. Missing text cannot be reconstructed.
Claude Code	Read-only access to the configured instance’s saved child transcript, with SDK conversation-chain reconstruction.	Checked against saved native history. Displays available text/thinking/tool blocks; malformed message records are skipped. Missing or redacted thinking is not recoverable.
OpenCode	Native child session/message APIs with ancestry verification and rewind boundaries; native Task lifecycle tracking supplies child identity.	Protocol-backed tests. There was no local saved child session available for an end-to-end native-history check, so that remains outstanding. Existing untracked cards are not backfilled.
Grok	Native saved-session metadata/update extensions, plus child lifecycle tracking.	Protocol-backed and fake-CLI tests. The real Grok CLI was unavailable locally; native end-to-end verification remains outstanding. Requires a CLI exposing those extensions. Malformed update envelopes are skipped; absent ancestry metadata fails closed.
Cursor	Explicit unsupported response in this implementation.	The current T3 ACP path does not provide a verified read-only child-history route with reliable child identity. This is a gap in the integration being used, not a claim that Cursor can never support the feature.
Antigravity	Explicit unsupported response in this implementation.	The current T3 ACP path likewise lacks a verified combination of individual child identity and saved-history access. A separate provider investigation/integration is needed.

The feature should communicate these differences honestly. Native validation of Codex and Claude should not be presented as proof that the other providers have equivalent coverage.

Verification completed

• 335 focused tests passed across history mapping, shared connection lifetime, provider adapters, provider-service routing, and panel logic.
• Server typecheck and targeted lint passed; web typechecking was performed during the UI work.
• Tests exercise concurrent/repeated connection reuse, directory isolation, idle and scope cleanup, failed reads, hung initialization, and timed-out reads.
• Claude tests verify that malformed records do not discard later valid messages. Grok tests verify malformed-envelope handling and rejection when ancestry cannot be established.
• Linux x64 AppImages were built and exercised in an isolated test profile. The tester verified the roster, recent history, full history, expandable edits, and visible final agent message.
• UI evidence is attached above and in the PR. Repository CI and maintainer acceptance remain separate from these local results.

Boundaries and work still needed

1. Mobile: this implementation adds no React Native Agents surface. Web and Electron share the web panel; mobile presentation needs a separate decision and implementation.
2. Provider gaps: Cursor and Antigravity remain unsupported; OpenCode and Grok still need real native end-to-end verification.
3. Large histories: response sizes are bounded, but some providers require reading the native transcript before selecting a page. Bounded payloads do not automatically mean bounded source-reading cost.
4. Refresh semantics: this is a saved-history snapshot view with periodic recent-tool refresh. It is not an instantaneous, lossless event stream. Pagination uses offsets rather than an immutable transcript snapshot.
5. Historical discovery: the feature reads known agents; it does not discover and backfill every older untracked child or introduce a complete nested-agent navigation tree.
6. Session status: a saved transcript is not proof that a child is still running. Restarted/dead session state must stay distinct from history availability.
7. Truncation and missing data: long entries are shortened explicitly. Unavailable native messages, reasoning, or deleted transcripts are not fabricated.
8. Remote validation: the endpoint is environment-scoped by design, but this proposal does not claim that every relay, tunnel, and multi-device combination has been exercised end to end.

Suggested acceptance criteria

• Opening Agents starts with a compact roster and does not fetch every child transcript eagerly.
• Expanding a supported agent shows its most recent available tools; failure and loading states are understandable.
• Full Activity reads the selected child from the owning environment and opens at its latest history.
• File-edit/tool details expand on demand, while the final agent response remains directly readable.
• Returning to the roster does not interrupt the parent conversation or restart the child.
• Finished/stopped children remain inspectable where native saved history exists.
• Reads cannot cross into an unrelated child or another configured provider instance.
• Repeated inspection does not cause unbounded subprocess churn, payload growth, or continuously repainting animations.
• Unsupported providers are explicit, and native validation gaps are documented before claiming provider parity.

Adoption options for maintainers

The existing PR is a working reference, not a request that every part must be accepted together. The user-facing behavior and screenshots are the outcome I care about; maintainers can simplify or reimplement the internals.

A smaller rollout could start with the shared history endpoint and Codex + Claude, then add the presentation and other providers in focused follow-ups. Alternatively, the UI implementation can be consolidated while preserving the same interactions. Simply deleting OpenCode/Grok from the existing diff does not make it a sub-1,000-line PR, because much of the size comes from replacing the old panel. Removing tests or compressing formatting would not improve reviewability.

For Julius and other maintainers evaluating this request, the main decisions are:

• Is this two-level inspection flow the right direction for Agents?
• Should Codex and Claude be the initial supported scope?
• Should mobile get an equivalent surface in the same initiative or a follow-up?
• Which provider-native history APIs are acceptable to rely on?
• Would smaller implementation PRs or a maintainer-owned implementation be preferable?

The full implementation, review discussion, screenshots, and recording are linked in PR #10881. This proposal is intended to remain useful even if that PR is split, deferred, or replaced.

Model: GPT-6 Astra. Harness: Codex.