Somewhere in the last year, coding agents became managers. Ask Claude Code a hard question and it doesn't just answer — it dispatches subagents: one to sweep the codebase, one to check the docs, a reviewer to poke holes in the plan. That's a real capability jump. It's also a transparency cliff, because in a terminal all of that delegated work renders as one line and a spinner. Your agent hired three workers, and you never see their output — only what the manager chose to repeat.
If your review standard is "evidence, not prose," that's a problem. The subagents did the actual reading; the summary you're shown is a summary of a summary. hang4r's answer is the Subagents tab: every delegated run in the session, live, as a thread you can follow.
Threads, not spinners
Each subagent run appears with its task label and its own transcript — the prompt it was given, every tool call it makes as it makes them, and the result it returned to the orchestrator. Watching one work feels like watching any other session, because structurally it is one: the same event protocol, the same rendering, one level down. Threads collapse when you're done with them, and hang4r remembers which ones you've folded away — across restarts, per session.
From claim to evidence in one click
In the conversation, a delegation shows up where it happened, with a ⤷ View thread button. Click it and the Subagents panel opens with that run expanded, scrolled into view, and briefly highlighted — so when a turn spawned five workers, you land on the one you actually asked about. The flow you end up using constantly: the main agent asserts "the reviewer found no issues" — one click, and you're reading what the reviewer actually looked at.
Why bother looking?
- Trust, calibrated. A conclusion inherits the quality of the search behind it. Seeing that the explorer subagent grepped three naming conventions — or only one — tells you how much weight the "it's not used anywhere" claim deserves.
- Debugging the turn, not just the code. When a big delegated turn lands somewhere strange, the threads show which worker went off the rails and what it saw right before it did.
- Better prompts. Watching how the orchestrator decomposes your request is the fastest way to learn what it can be trusted to decompose — and what you should split up yourself.
The honest edges
Two truths the UI states plainly instead of papering over. Subagents run inside the CLI's own process and its protocol has no per-subagent kill — so the Stop control in the panel says what it does: it stops the whole turn, all workers included. And commands the agent runs in the background — dev servers, watchers — are a different animal with a different lifecycle; those live in the Tasks tab, with per-task stop. Delegated reasoning is what the Subagents tab is for.