Skip to main content
A trace is one run of your agent: one request, one conversation turn, one job. Each trace holds spans, one per step the agent took (a model call, a tool call, an HTTP request, a database query, or any function you chose to time). The Traces page in the AgentHub sidebar lists the traces for the project you have selected and lets you open any one of them. Traces arrive in two ways:

​
The traces list

​
Columns

The list is sorted newest first. It loads 50 traces at a time; Load more at the bottom appends the next 50 without moving you back to the top. A counter under the table reads “Showing N traces”.

​
Provenance badges

The small outline badges next to a trace ID tell you where it came from. They are read from the trace’s source, environment and tags: At most three badges are shown. Hover a badge to see the trace’s full tag list.

​
Source and environment

  • Source is either live (the default for anything you send) or simulation. There is no filter for source in the list; use the badge to tell them apart.
  • Environment is a free-text label of up to 64 characters that you set when sending the trace (for OpenTelemetry, it is read from deployment.environment.name or deployment.environment). It defaults to production, which is why production traces show no environment badge.

​
Search and filter

Above the table:

​
Empty and error states

Tracing keys are managed in Settings, and on AgentHub only your organization’s super admins see the Tracing keys tab. If Get tracing key shows you nothing, ask one of them for a key. See Tracing keys.

​
Trace detail

Click a trace name to open it. The page has four parts: the header, the stat cards, the Run path, and the evaluation section.
  • The root name (or trace ID) as the title, the trace ID under it, and the same provenance badges as the list.
  • Run report opens the report for this trace.
  • A status badge, OK or ERROR.
  • ← Back to traces returns to the list.

​
Stat cards

​
Run path

“Every step the agent took, in the order it took them.” A summary strip sits above three tabs. Summary strip Expand all / Collapse all opens or closes the detail panel on every step at once. When you open a failed trace, the first failing step is already expanded.
A waterfall. Each row is one span, numbered in the order it ran, and indented under its parent. Bars are placed and sized on a shared clock, so a wide bar really did take longer. Gaps where nothing was running are marked with the idle time before the step, and the slowest step in the trace is flagged.A thin underline under each bar is that step’s cost relative to the most expensive step in the trace.A legend lists each span kind with its count, a Failed entry when there are failures, and “Numbered rail = execution order”. If the trace is marked ERROR, the waterfall shows where the run stopped, or notes when the trace is ERROR even though every recorded span is OK.Click any row to open its span detail (see below).

​
Very large traces

When a trace has more than 150 spans, the Timeline and Flow tabs first show only the key steps: the entry point, every failure, and the 20 slowest steps. A notice reads “Showing N of M steps” with a Show all M steps link. Payload previews are also hidden inside span details on these traces; the Table tab always lists every span.

​
Span kinds

​
Span detail

Opening a step shows:
  • Started (offset from the trace start), Duration, Tokens (in / out), Cost, Status, Model and Span ID.
  • A red Failed: line with the error reason, when the span recorded one in its output.
  • The payload, which depends on the kind:
    • Model-call spans: a collapsible System prompt, the User message, and the Assistant reply. If the model returned nothing, “The model returned an empty response.” If nothing was recorded, “No prompt or completion recorded on this span.”
    • Tool spans: the tool name, a simulated badge when the Cost Calculator simulated the tool, and the Result.
    • Acceptance spans (written by the Cost Calculator): a readable verdict with “Acceptance passed” or “Acceptance failed”, the composite score, the scenario category, “Why this failed” reasons, each assertion with its measured value against its bar, and any other measured scores.
  • Other input: any input keys not already shown above.
  • Output: the output object, when it isn’t already shown as a reply.
  • Attributes: every attribute you sent on the span.
  • Raw JSON: a collapsed section with the span’s input, output and attributes exactly as stored.
If a trace was ingested with no spans at all, the Run path shows No spans recorded instead.

​
Evaluate this trace

Below the run path is Evaluate trace. What it shows depends on your setup: Evaluate this trace opens the Your Evaluations tab of Evaluation with the trace carried over: the test input box is prefilled with the trace’s real first input and final answer, the judge is preselected, and the collection’s evaluators are preselected (up to 25). You review the input, then press Run.
That button does not run the collection against the stored trace. It starts a fresh model run seeded from the trace’s text, scored by an LLM judge. Those results are not saved to the trace. Collection runs that score the stored trace itself (and appear under Evaluation results on this page) are created through the evaluate API. See Evaluation runs for the difference and how to start one.

​
Evaluation results

Under the panel, Evaluation results lists every saved collection run for this trace, newest first. Each card shows the collection name, the time, the judge model (or “offline only”), the run status, and the average score. A table lists each evaluator with its Type (offline_deterministic or online_llm_judge), Score, Pass and Reason. If a run failed, its error message is shown. With no saved runs, the section reads “No evaluations yet.”

​
Using traces elsewhere

  • Reports. Every trace has a report: Report in the list or Run report on the detail page. See Reports.
  • Cost Calculator import. In the Cost Calculator, Import from traces lets you pick up to 20 OpenTelemetry-collected traces at a time and analyze them as if they were scenarios, without re-running them through a model. Traces generated by CorePillar itself are not listed there. See Cost Calculator.
  • Simulations. Cost Calculator runs and their per-scenario traces are summarized on Simulations.

​
Limits

Traces are stored in the same database as the rest of the platform and ingestion is processed as it arrives, without a queue. It is sized for evaluation and debugging workloads, not for high-volume production telemetry.