Runs, traces, and the tree everything else is a view over
Every screen in this course is a view over one data structure. Dashboards, threads, cost columns, Insights reports, alert metrics: all of them are aggregations over runs. So if the tree is fuzzy now, everything downstream will be fuzzy later, and you will not be able to tell which.
A run, a trace, and that is the entire model
A run is one unit of work that got recorded. A trace is the whole tree of runs produced by one top level invocation.
The run at the top is the root run. When somebody says “that trace took four seconds”, they mean the root run’s latency, which is wall clock for the whole thing. Everything else hangs off it.
The seven run types, exactly seven
LangSmith tags every run with a run_type, and there are seven of them:
chain, llm, embedding, prompt, tool, retriever, parser.
Learn it as a closed list rather than as a vibe. A question that shows six real types and one invented one is free marks if you know the set and a coin flip if you do not.
What builds the tree
Two fields, and they do different jobs.
parent_run_id points a run at its parent. That gives you the edges. A root run has no parent.
dotted_order is the one people skim past, and it is why the UI is fast. It encodes the run’s full path from the root as a sortable string, so the frontend renders a correctly ordered, correctly indented tree by sorting a flat list. No recursive walk, no waiting for every child to show up.
That has a practical consequence. Runs are posted asynchronously and can land out of order. Because ordering is baked into the string rather than inferred from arrival, a trace renders correctly even when the middle of it arrives last.
The 25,000 run cap
One trace holds a maximum of 25,000 runs. Hard cap, not a soft warning.
You will never hit it with a normal agent turn. You will absolutely hit it with an unbounded loop, or with a batch job you accidentally wrapped in one root run instead of one root per item.
Two screens, two jobs
The runs table answers population questions. Everything that errored in the last hour, everything slower than ten seconds, everything from one user. It is a filtered list and it is where you start.
The trace detail view answers single case questions. For this one invocation, what happened, and where did it stop being right. It renders the tree, and selecting any node swaps the side pane to that run’s inputs, outputs, metadata, feedback, latency and tokens.
The workflow is always the same: filter to a population, open one representative case, walk down the tree until the output stops being what you wanted. The run where the output first goes wrong is the broken one, and everything below it is faithfully processing garbage.
Try it yourself
Name all seven run types
Pure enumeration, and enumeration questions are the cheapest marks on the exam. There is one on this list that almost everyone drops.
List every run type LangSmith supports. There are exactly seven. Which one is most often forgotten, and why does it feel like it does not belong?
Reveal answer
chain, llm, embedding, prompt, tool, retriever, parser. The forgotten one is embedding. It feels wrong because embedding calls happen inside your vector store integration rather than in code you wrote, so it reads like somebody else's concern. It is a real LangSmith run type. parser is the second most forgotten, and chain is the catch all default that wraps anything not more specifically typed.
What actually builds the trace tree
You expand a trace in the UI and see a nested, correctly indented tree. Something computed that nesting from flat records.
Show answer
Correct answer: B — parent_run_id together with dotted_order
Hierarchy comes from parent_run_id plus dotted_order. The tempting wrong answer is the trace id one, because a shared trace id genuinely is what makes those runs a single trace, so it feels like the answer. But trace id only says these belong together; it says nothing about who is nested inside whom. Timestamps cannot recover depth either, since a parent and its first child can start in the same millisecond. Arrival order is meaningless because runs are posted asynchronously and land out of order.
The hard cap on runs in a trace
A looping agent generates an enormous number of runs inside one trace. There is a documented ceiling.
Show answer
Correct answer: C — 25,000 runs per trace
25,000 runs per trace is the documented hard cap. 1,000 is the dangerous distractor because it is also a real LangSmith number: it is the cap on traces processed by a single Insights job, which you meet in module 2. Those two numbers sit next to each other in memory and get swapped under time pressure. Keep them apart: 25,000 runs in one trace, 1,000 traces in one Insights run.
Which screen answers which question
Production is misbehaving. You want every failed run from the last hour so you can find a representative case.
Show answer
Correct answer: A — Filter the project's runs table on error status and a one hour range, then open a result
Filter to a population in the runs table, then open one case in the trace detail view. The Insights option is the genuinely tempting one, because Insights really does cluster failures into named categories and that sounds like exactly what you asked for. It is scheduled and capped though, so it answers what has been going wrong lately rather than what is broken right now. An alert rule is forward looking and cannot tell you about an hour that already happened.
Read one trace all the way down
Any project with traces in it will do. This takes two minutes and it is the cheapest possible insurance against a UI question on the day.
You can point at the root run, name the run type of each child, and say out loud why one particular run is nested under another rather than sitting beside it.