Tracing
Following one request through every step it took.
Recording a full request as a tree of spans — retrieval, model calls, tool executions, subagents — with timing, tokens and cost attached to each step.
For agents, traces are the primary debugging tool. When a run goes wrong, the trace shows which step produced the bad context that everything after inherited.
A trace is what turns a multi-step agent from a black box into a timeline: which call was slow, which tool failed, which subagent burned the tokens. For anything beyond a single call, it is the difference between guessing and reading.
Finding the slow step
An agent task takes ninety seconds and nobody knows why.
The trace shows one retrieval call at sixty-five seconds and four model calls under five. The optimisation is a database index, not a smaller model — a conclusion that is invisible without per-step timing.
- standardOpenTelemetry GenAI semantic conventions ↗
Agreed attribute names for spans, metrics and events covering GenAI clients, MCP and provider specifics — what makes traces comparable across vendors instead of bespoke.
- docsLangSmith observability ↗
A concrete example of what an LLM observability product records: production traces, dashboards, alerts and user feedback. First-party, so not an independent comparison of tools.
Observability
Being able to see what the system actually did.
Agent Loop · Agentic loop
Think, act, observe — repeated until the task is finished.
Tool Result
What came back from the call, appended to context.
Prompt Versioning
Treating prompts as versioned, reviewable artifacts.