Progressive Disclosure: The Design Pattern Taming Agent Output in Trae, Claude Code, and Cursor
Core conclusion: Trae, Claude Code, Cursor and other agent tools handle massive outputs (tool calls, command execution, reasoning) not by "hiding" them, but by progressive disclosure—by default they show only a clean, actionable surface (final answer + one status line), folding details into expandable containers that you open on demand. This follows a three-layer information architecture: Layer 1, conclusion surface (answer + status such as "thought for 8 seconds" or "reading file"), Layer 2, evidence surface (tool results, citations, key data), Layer 3, raw trace (full chain-of-thought, full command outputs, per-step logs). The four fold patterns—time folding, tool folding, thought folding, result folding—each target one type of noise. When three things are done right (default clean + on-demand drill-down + real-time feedback), users feel a sense of "satisfaction"; missing any one of them leaves users either drowning or suffocated.
Table of Contents
- One-sentence conclusion
- Why agent output "drowns" users
- Core principle: Progressive Disclosure
- Layered information architecture: how to split three layers of information
- Four fold patterns: time / tool / thought / result
- Product practice: what Claude Code, Trae, Cursor do
- Three sources of "satisfaction": clean, drill-down, feedback
- Two anti-patterns: over-collapse vs. over-expose
- Complete runnable code: a progressive disclosure fold component
- Symptom → cause → solution table
- Judgment closing
1. One-sentence conclusion
First, build an intuition 🎭: Agent output comes from the "back kitchen"; users only want to see the "plated dish"—if the back kitchen's chopping, wok-tossing, and dishwashing (tool calls, command execution, reasoning) are all shoved at the customer, the customer loses appetite; but when the customer wants to know how the dish was made, you can't weld the kitchen door shut.
So, the "satisfaction" of agent output comes from three sentences:
- Default clean: The first glance shows only "answer + one status line", don't let 3000 lines of logs hit the face.
- On-demand drill-down: Details you want to see are folded into expandable containers; click to open.
- Real-time feedback: Even in collapsed state, let the user see "it is working" (thought for 8 seconds, reading file).
One sentence: It's not "hide output", it's "layered presentation"—fold 90% noise, keep the 10% signal, expand the rest on demand.
2. Why agent output "drowns" users
First understand how severe the problem is. When an agent runs a task, the output it produces roughly includes:
- Reasoning (chain-of-thought): The model's reasoning tokens before answering, possibly thousands of words.
- Tool calls: What tool was called at each step, what arguments, what result, dozens to hundreds of steps.
- Command execution (shell output): Compilation logs, test output, file listings, often hundreds to thousands of lines.
- Intermediate results: File contents read, search results, API-returned JSON.
If you lay all of this flat on the interface, the result is: users scroll 10 screens without seeing the final answer, and truly important information ("did the task succeed", "what is the answer") gets buried in noise.
Using an analogy 🎭: This is like using "the whole cookbook + shopping list + dishwashing record" as a restaurant menu—the customer just wants to order, but you hand them the entire kitchen's ledger. More information is not better; unprocessed information load = cognitive burden.
💡 Key insight: Agent's process information is useful to debuggers, but noise to ordinary users. Folding's essence is distinguishing "who needs which layer in what scenario".
3. Core principle: Progressive Disclosure
This is the underlying principle behind all agent tool output design:
- Definition: Show a clean, actionable surface by default, letting users drill into details on demand.
- Why "progressive": Information is not given all at once, but unfolds layer by layer from summary → evidence → raw trace.
- Adaptation to agents: Agents generate a lot of information (reasoning traces, tool calls, intermediate results, confidence, citations); dumping it directly into the UI is cognitive overload.
Benefits of progressive disclosure:
- Clean first glance: Users see the "result" first, quickly judging "am I satisfied with this answer?"
- Controllable when needed: If you want to verify details, debug, or see evidence, expand.
- Cognitive grading: Different users need different depths—ordinary users see conclusions, developers see traces.
⚠️ Note the cost: Users may never expand and miss key information (e.g., a tool failure hidden in a fold), or become annoyed because they must click repeatedly to find details. So "folding" must be paired with "key status floating to the surface"—this is what sections 7 and 8 address.
References:
- Progressive Disclosure UI Patterns -- Agentic Design ⭐worth reading
- Agent UX & Transparency: Progressive Disclosure -- Max Gherman ⭐worth reading
4. Layered information architecture: how to split three layers
When progressive disclosure is translated into structure, it becomes Layered Information Architecture. Agent output is divided into three layers by value:
| Layer | Content | Default state | For whom |
|---|---|---|---|
| Layer 1 · Conclusion surface | Final answer + one status line | Always visible | All users |
| Layer 2 · Evidence surface | Tool results, citations, key data points | Folded (one-line summary) | Those who want to verify |
| Layer 3 · Raw trace | Full chain-of-thought, full command output, per-step logs | Deeply folded | Developers / debugging |
- Layer 1 is always visible: The thing users care most about—"is it done, what's the answer"—must not be folded.
- Layer 2 is for the "want to confirm" crowd: Sources, key tool results—one-line summary + expand to see full.
- Layer 3 is for the "want to debug" crowd: Full trace, raw logs—depth by default, only when needed.
Using an analogy 🎭: These three layers are like a newspaper's "headline → lead → full text"—a headline scan tells you the gist (Layer 1), the lead adds key facts (Layer 2), and to dig deeper you read the full article (Layer 3). No one demands "newspapers print only full text".
5. Four fold patterns: time / tool / thought / result
On the specifics of "how to fold", the industry has settled on four assembly patterns, each targeting a type of noise:
① Time folding (Thinking Duration)
- Method: Compress the entire reasoning process into one line "thought for 8 seconds", expand to see full reasoning.
- This is Claude Code's classic move—"Thought for 12s" shows only duration, not content.
- Best for: when the thinking chain is long but not critical to judging the result.
② Tool folding (Tool Call Accordion)
- Method: Each tool call collapses to one line "read config.py" or "ran pytest (3 failures)", click to see arguments and full results.
- While running, show status indicators like "Using Read..."; after completion, fold into a one-line summary.
- Best for: when tool call steps are many and each step's output is verbose.
- I covered the full chain of tool calls in How agents make tool calls: from a single Function Calling to the full production-grade tool orchestration chain; this article focuses on "how it gets folded into one line on the interface".
③ Thought folding (Chain-of-Thought Collapse)
- Method: Put reasoning steps into a collapsible "thinking" accordion, collapsed by default.
- assistant-ui's
ChainOfThoughtcomponent does exactly this—grouping reasoning steps and tool calls. - Best for: presenting reasoning in a way that is "visible but not intrusive".
④ Result folding (Output Truncation)
- Method: Long outputs (command logs, file contents) show only the first N lines by default plus "expand all (total 1200 lines)".
- Best for: when a single output is thousands of lines, and 99% of users only look at the first few.
| Fold pattern | What is folded | What remains visible | Expand trigger |
|---|---|---|---|
| Time folding | Whole thought | "thought for 8 seconds" | click to expand |
| Tool folding | Single tool call | One-line action summary | click to expand |
| Thought folding | Reasoning step chain | "Thinking" title | click to expand |
| Result folding | Overlong output | First N lines + line count | click to expand all |
References:
- ChainOfThought component -- assistant-ui ⭐worth reading
6. Product practice: what Claude Code, Trae, Cursor do
Looking at real products makes "layering + folding" easier to understand.
Claude Code / VS Code plugin:
- Thought blocks show only a label by default, like "Thought for 12s", click to see content—a classic "time fold".
- Supports streaming thinking: thoughts come over as
thinking_delta, the interface scrolls in real time without flooding. - Tool calls also stream, marked with
in_toolstatus, showing "Using Read..." while running.
Cursor / Trae-style IDE agents:
- Each tool call is a collapsible card: one line by default like "edited xxx.ts", expand to see the diff.
- "Thinking / generating" is shown with animation + progress hints, so users know "it's working" rather than frozen.
- Command execution results are truncated by default; click "view all output" to expand the full log.
Common patterns (used by almost all products):
- "Summary first": give the conclusion, then the process.
- "Failure first": key information like tool errors and verification failures is not folded, floats to the surface directly.
- "Status always present": even when everything is collapsed, keep a "what it is doing" status bar.
💡 Observation of their commonality: what is folded is "process details", what is not folded is "results" and "anomalies". This is the dividing line in all designs.
References:
- Stream responses in real-time -- Claude Code Docs ⭐worth reading
- Thinking: Streaming thinking -- Claude Platform Docs
7. Three sources of "satisfaction": clean, drill-down, feedback
When users talk about "viewing satisfaction", it breaks down to three things; missing any one flips the experience:
① Clean: don't hit the face by default
- First screen must be "result + one status line", not thousands of lines of logs.
- Criterion: Users can know "whether the task succeeded and what the answer is" without scrolling.
② Drill-down: everything you want is reachable
- Folding is not "deleting", it's "putting away"—clicking must reveal the full content.
- Criterion: When a user wants to verify, one click gets them there, no digging through chat history.
③ Feedback: the collapsed state must stay "alive"
- Even if thinking is fully collapsed, show real-time status like "thought for 8 seconds" or "running tests".
- Criterion: Users don't suspect a freeze because the interface is motionless.
Using an analogy 🎭: This is like a "food delivery app"—first glance shows "delivered + ETA" (clean), click to see "rider's route" (drill-down), and the map car moves during delivery (feedback). Only with all three is it called "satisfying".
⚠️ Many tools fail on the third point: folding is done beautifully, but there's no "working" feedback, so users stare at a static interface wondering "is it stuck"—worse experience.
8. Two anti-patterns: over-collapse vs. over-expose
The two most common failure modes in fold design sit at opposite extremes:
Anti-pattern one: Over-collapse
- Symptom: "Failures", "anomalies", and "key evidence" are folded too, so users never know a tool errored.
- Consequence: Users think the task succeeded when the agent actually failed—worse than no folding.
- Antidote: "Failure-first float"—errors, failed verifications, low confidence must not be folded, go straight to the top layer.
Anti-pattern two: Over-expose
- Symptom: No folding at all, laying all thinking, tool calls, command output flat.
- Consequence: Users scroll 10 screens without an answer, cognitive overload, and they give up.
- Antidote: Default to the first layer, fold the rest.
| Anti-pattern | Symptom | Consequence | Antidote |
|---|---|---|---|
| Over-collapse | Failures/evidence are folded too | Users mistakenly think success | Failure-first float, key anomalies not folded |
| Over-expose | All process laid flat | Cognitive overload, no answer visible | Default to first layer conclusion |
💡 One-line boundary: fold "process", expose "results" and "anomalies"—if you draw this line correctly, both anti-patterns are avoided.
9. Complete runnable code: a progressive disclosure fold component
Below is a complete HTML that you can copy-and-run. It implements a "progressive disclosure" agent output component: tool call cards collapse by default to a one-line summary, click to expand details, failure items are highlighted and expanded by default, and it includes a "thinking" real-time status. Save as agent-output.html and open in a browser.
<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="UTF-8">
<title>Progressive Disclosure: Agent Output Fold Component</title>
<style>
body { font-family: sans-serif; max-width: 640px; margin: 40px auto; padding: 0 16px; }
/* Layer 1: conclusion surface (always visible) */
.answer { background: #f0fdf4; border-left: 4px solid #22c55e; padding: 12px 16px; border-radius: 8px; }
/* Status bar: shows "working" feedback even in collapsed state */
.status { color: #666; font-size: 14px; margin: 12px 0; }
.dot { display: inline-block; width: 8px; height: 8px; border-radius: 50%;
background: #22c55e; margin-right: 6px; animation: blink 1s infinite; }
@keyframes blink { 50% { opacity: 0.2; } }
/* Layers 2/3: collapsible tool call cards */
.tool { border: 1px solid #e5e7eb; border-radius: 8px; margin: 8px 0; overflow: hidden; }
.tool summary { cursor: pointer; padding: 10px 14px; background: #fafafa;
font-size: 14px; list-style: none; }
.tool summary::-webkit-details-marker { display: none; } /* hide default triangle */
.tool summary::before { content: "▸ "; color: #999; }
.tool[open] summary::before { content: "▾ "; }
.tool .detail { padding: 12px 14px; font-size: 13px; color: #444;
background: #fff; border-top: 1px solid #f0f0f0; white-space: pre-wrap; }
/* Failure-first: error cards are highlighted by default and expanded by default */
.tool.error { border-color: #ef4444; }
.tool.error summary { background: #fef2f2; color: #b91c1c; font-weight: bold; }
</style>
</head>
<body>
<!-- Layer 1: conclusion surface, user sees first -->
<div class="answer">✅ Task complete: fixed port configuration in config.py, all tests pass.</div>
<!-- Real-time feedback: shows "working" even in collapsed state -->
<div class="status"><span class="dot"></span>Agent finished, executed 3 tool calls</div>
<!-- Layer 2: tool call fold cards (collapsed by default, click for detail) -->
<details class="tool">
<summary>Read config.py (128 lines)</summary>
<div class="detail">port = 8080
host = "0.0.0.0"
# ... (full file content goes here)</div>
</details>
<details class="tool">
<summary>Edited config.py: 8080 → 9090</summary>
<div class="detail">- port = 8080
+ port = 9090</div>
</details>
<!-- Failure-first: error item is expanded by default and highlighted, never hidden in a fold -->
<details class="tool error" open>
<summary>⚠ Test had 1 failure (fixed)</summary>
<div class="detail">FAILED test_server.py::test_port
AssertionError: expected 9090, got 8080
(After fix, rerun: 3 passed)</div>
</details>
</body>
</html>
How to read this code: .answer is Layer 1, the "conclusion surface", always visible; .status is the "real-time feedback" status bar; even when all tool details are collapsed, the user knows "3 tool calls were executed". Each <details class="tool"> is Layer 2, the "evidence surface", using native <details>/<summary> for folding, with summary::before showing ▸/▾ expand indicators (replacing the default triangle). Most crucially, .tool.error has the open attribute—failure items are expanded by default + highlighted red, precisely implementing the "failure-first float" from section 8. This code covers all four points: "layering + folding + feedback + failure-first".
10. Symptom → cause → solution table
| Symptom | Cause | Solution |
|---|---|---|
| User scrolls many screens without finding answer | All process laid flat, no folding | Default to first layer conclusion surface |
| User thinks task succeeded after fold, but it failed | Failure info is folded too | Failure-first float, anomalies expanded by default |
| User complains "need to click repeatedly to find details" | Fold layers too deep, entry points unclear | Put key details in Layer 2, one-click reachable |
| Interface static, user suspects freeze | No real-time status after folding | Keep a "thinking / running" status bar |
| Thinking chain too long, floods screen | Reasoning tokens shown in full | Time folding: "thought for 8 seconds" |
| Command output thousands of lines | Long output not truncated | Result folding: first N lines + expand all |
11. Judgment closing
When you should build a full progressive disclosure: if your agent tool produces multi-step tool calls + long thinking chains + large command output, and users need to see results, occasionally verify process—then the three-layer architecture + four folds are a necessity, otherwise the experience will fail. When you can simplify: if the agent does single-step, outputs are short, or users are developers who want the full trace throughout—then laying everything flat is more appropriate; forced folding is overdesign. The single criterion is: is the user "looks only at results, occasionally at process"—if yes, layering and folding; if "wants process all the time", then folding is a burden.
This column, "AI-Agent Tools", covers agent memory, tool calls, architecture selection, automated scheduling, evaluation, and interaction design, each piece accompanied by runnable frontend/backend code, updated continuously. To avoid pitfalls when building agent products, you can subscribe to the column page.
References (comprehensive):
- Progressive Disclosure UI Patterns -- Agentic Design ⭐worth reading
- Agent UX & Transparency: Progressive Disclosure -- Max Gherman ⭐worth reading
- ChainOfThought component -- assistant-ui ⭐worth reading
- Stream responses in real-time -- Claude Code Docs ⭐worth reading
- Reasoning Glimpse (Chain-of-Thought Visualization) -- Agentic UX Patterns
Top 1 from juejin.cn, machine-translated. The original thread is authoritative.
Adding a new angle: no matter how slick the folding is, once failure messages get hidden it's all for nothing — users think it succeeded, but it actually already crashed. Which do you find more unbearable? A: output slapped straight in your face, B: hidden too deep and you can't locate the error