Summarising a run in one line, honestly
The collapsed state is the altitude most likely to be the only one a reader sees, which makes it the one place a summary that quietly omits a failed retry does the most damage.
One line. Something like Enriched 2 properties · 19s, with a chevron on the end. It is the smallest surface in the component and it took you about four seconds to write.
The run behind it called a search tool, a database read, two enrichment calls, and a write. One enrichment timed out and the retry succeeded. The line above says none of that, and it is not wrong about anything it says. It enriched two properties. It took nineteen seconds.
This lesson is about the difference between a summary that compresses and a summary that asserts, because the collapsed state is where those two look identical and only one of them is honest.
What the line is obliged to carry
Four things, and the altitudes reference page argues each one. What the run produced, in the run’s own domain terms rather than in step terms. Whether it fully succeeded. Wall-clock duration, if a human waited. One affordance to go deeper, always visible, never a hover.
Three of those four are easy. The second one is the lesson, because “whether it fully succeeded” is not a field you can read.
You already know why, from the span-model lesson. The tracing specification tells instrumentation libraries to leave a span’s status Unset unless there is an error, so a run that succeeded completely emits nothing that says so. And the failures an agent actually produces frequently never reach span status at all: a tool that returns an error payload to the model has not thrown, so nothing obliges the instrumentation to record a span error. Anthropic’s tool-result blocks carry their own is_error boolean — Anthropic documenting its own API — which is a second, independent notion of failure that can disagree with the first.
So the word in your summary is the output of a rule you wrote. Not a field. A rule. And an unwritten rule that produces the word “done” is the most consequential undocumented line of code in the component.
Who reads this line, and what is actually known about that
It is tempting to justify all of this with a statistic about how few people expand a trace panel. Do not, because there is no such statistic.
The research pass behind this course went looking for a usability study measuring how often readers expand a collapsed trace, step list or reasoning panel rather than reading only its summary, searching the HCI and UX literature for read-depth and expansion measurements on this kind of component. Nothing turned up. The adjacent finding that does exist is about a different element entirely: NN/g’s study of chat interfaces reports that “people rarely click citation links,” illustrated by a participant who said they would click through to check a source and then never did so during testing. That is citation links in a chat answer. It is not your panel, and substituting it in as though it measured your panel is the exact move this course exists to refuse.
The rule: compress freely, assert never
A summary is allowed to leave things out. That is its job. What it is not allowed to do is state something the schema does not support, and the four rules below are what that distinction looks like in practice.
1. Success is three-valued, not two-valued. Succeeded, succeeded after recovering from a failure, failed. A run that retried and got there is not the same object as a run that never stumbled, and the person deciding whether to accept the output is the person whose decision changes. Collapsing recovery into success is the single most common dishonesty in this surface, and it is the only failure on the altitudes page that a reviewer cannot discover by clicking.
2. Unknown is a fourth state, and it renders. A trace is sampled and advisory by design — W3C Trace Context says outright that trace flags are “recommendations given by the caller rather than strict rules” — so a run whose spans are incomplete has an unknown outcome rather than a good one. Your rule needs a branch for it and your line needs words for it. “Outcome not recorded” is a perfectly good thing for a summary to say, and it is infinitely better than a green check that means nobody made a claim.
3. The line speaks the domain, not the telemetry. “Enriched 2 properties” is a summary. “11 spans, 4 tool calls, 3 retries” is a status bar wearing a summary’s clothes. Counts of internal machinery mean nothing without the tree they came from, and the tree is one click away, which is where they belong.
4. Every number in the line is one the reader can act on. Duration passes, if a human waited for it. A token count does not. A dollar figure does not belong here at all until you can state its provenance, which is a later lesson’s whole subject.
Google’s People + AI Guidebook — Google’s own design research, from a company that sells AI products — makes the general version of this point about first contact: “Be up-front about what your product can and can’t do the first time the user interacts with it”. The collapsed summary is first contact, every time, for every run.
Three summaries of the same run
Same eleven-step run. One enrichment call timed out, retried, and succeeded. Two records were written.
Dishonest. Enriched 2 properties · 19s · Done. Every word is true and the object it describes does not exist. The reviewer accepts, and the fact that a call failed and was retried is now available only to someone who opens a panel they have no reason to open.
Unreadable. Completed with 1 recovered tool failure across 4 tool calls, 11 spans, 2 unsampled, est. $0.58 · 19.2s. Nothing here is false. It is also not a summary, it is altitude 02 squeezed onto one line, and a reader who has to parse a summary will stop reading summaries.
Honest. Enriched 2 properties · 19s · recovered from 1 failed step, with the chevron. One added clause. It changes the decision for the reader who cares and costs four words for the reader who does not, and the clause is the affordance: the person who reads “recovered from 1 failed step” now has a reason to open the tree, which is the only reliable way anyone ever opens a tree.
Where people get burned
Watch for the summary that hedges everything, which is the failure mode people reach for once they have been burned by the first one. A line that qualifies every claim teaches the reader that the qualifiers carry no information, and then the one run that genuinely half-failed reads exactly like the four hundred that did not. Honesty in this surface is not maximal disclosure. It is a small number of states, each of which means something different, each of which the reader learns to recognise.
Retrieval check
Your summary rule reads: outcome is “failed” if any span has Error status, otherwise “succeeded”. A run calls a pricing tool that returns {"error": "rate limited"} as its result payload, the model apologises in its final answer, and no span carries an error. What does your line say, and what should it say?
Check your answer
It says the run succeeded, because the rule read the only field it knew about and that field was Unset on every span. The run did not succeed. It produced an apology.
The repair is not a better condition on span status. It is accepting that failure arrives on two independent channels — the span status the instrumentation set, and the error signal inside the tool result — and that your schema has to carry both plus a rule for when they disagree. Disagreement is the normal case rather than the edge case, because a tool returning an error to the model is the designed behaviour of every tool-calling loop, not a crash.
There is a third channel you cannot read at all, which is the model giving up quietly inside its answer text. Do not try to detect that in the summary. Detecting it means classifying generated prose, which is a different system with its own error rate, and the honest position is that the collapsed summary reports what the telemetry claimed and visibly nothing more.
Hands on
Write the summary rule, then break it
Done when: ARTIFACT.md’s “Summary rule” section states, in prose a colleague could implement, how the collapsed line decides its outcome word — including the unknown branch and the disagreement branch — and lists at least two runs from your own captured payload where the naive version would have printed the wrong word.
- Write the outcome function in words before you write it in code. Four states: succeeded, recovered, failed, unknown. For each one, name the exact conditions on your schema that produce it. If a condition references a field your schema does not have, you have just found the next schema change.
- Decide the disagreement rule explicitly. Span status says clean, the tool result carries an error: which wins? Write down the answer and the reason. There is a defensible answer either way and there is no defensible position where the question was never asked.
- Define the unknown branch. What makes a run’s outcome unknowable — a span with no end timestamp, a parent reference pointing at a span that never arrived, a gap in the tree — and what words does the line use when it happens. “Unknown” is a state to render, not an error to swallow.
- Now write the line itself for each of the four states, at full length, as strings. Count the words. If the recovered state is more than about four words longer than the succeeded state, it is drifting toward the unreadable version above.
- Run your rule against the payload you captured in module one, including the step you deliberately made fail. Print what the line would say. If it says the run succeeded, do not fix the rule yet — write down what it printed, because that sentence is the entire argument for this lesson and it is worth having in your own notes in your own runtime’s words.
- Bring the rule and the wrong line into the chat. The disagreement branch is the part worth arguing about, and the answer you chose there will show up again in the step tree, where the same two channels decide whether a row is drawn as failed.
What this does not cover
This lesson wrote one line and the rule behind it. It said nothing about the surface directly beneath it, where the same run becomes a list of rows and three specific shapes in the data make the naive rendering lie: two calls that ran at once and read as a sequence, one retried call that reads as two calls, and a run still arriving that reads as a run that finished. That is the step tree lesson, which comes next.
It also left the affordance itself alone. What the chevron opens into, how much of a tool’s arguments belong in a row, and why redaction cannot happen in the view are the tool-call inspector lesson at the end of this module. And the question of what a summary should say when the run produced a claim rather than a record — a cited answer, a confidence number — is the citations and confidence module, where the sources are strong enough to answer it.
Read this next — primary source
Explainable AI in Chat InterfacesMegan Chan, Nielsen Norman Group, 12 December 2025 — fetched 2026-09-05. Free to read; NN/g sells training and research reports on this material.
The article is about citations and disclaimers in chat, not about trace panels, and the gap is the reason to read it properly rather than take the one quote this lesson borrows. Two findings transfer directly to a collapsed summary: that stated explanations are frequently unfaithful to the computation they claim to describe, and that a disclaimer works when it is written plainly and paired with an action rather than parked in a footer. The third, that people rarely click citation links, is the closest published thing to evidence about what readers do with an affordance to go deeper — and watching how carefully NN/g scopes it to what they actually observed is the model for how this lesson scopes its own claim.
Stuck, curious, or think this lesson is wrong? Ask your teaching agent. The lessons are the scaffold; the conversation is where the learning gets unstuck.