Skip to main content

​
Tracing a run

Every one of the five deployed graphs emits a trace, with a child span per node.

​
One project, five root names

All five write into a single tracing project. They are separable because the compiled graph name is the root run name: clerk, bookkeeper, auditor, accountant, typewriter. Filter on run name. Per-agent projects are not achievable without a code change, because one service process hosts all the graphs and the project setting is process-wide. Adding per-agent tags is a one-line change per agent, deliberately not made as part of a build-and-stage task: it wraps the compiled graph in a binding the platform server introspects, and validating that belongs with a deploy.
Eval experiments are deliberately kept out of that project. Each graded run writes to its own experiment project, so a graded run never mixes with production traffic.

​
What a trace actually looks like

Three real traces, sampled during a baseline run. Two of those are worth reading closely. The Clerk’s 18 spans show the bounded repair loop firing twice. validate failed a shape check, re-prompted extract, and the cycle ran twice more before the record went to routing. That is real control flow rendered as a trace, not a flat list of steps. The Bookkeeper’s four spans are quietly the best evidence in the whole system. The trace itself shows the graph stopping at the gate. Not a log line claiming it stopped: the absence of a post span, in a graph that has one. The Clerk’s chat path traces separately as intake_router, scope_gate, scoped_answer, output_check, or ending in decline. Child spans carry step tags plus the assistant and checkpoint identifiers, so a paused run can be tied to the checkpoint a resume will restore.

​
The honest gap

There are no model-call runs in the trace.Model calls go through the keyless Agent SDK, which shells out to the local CLI. So the tracer sees the node span but not token counts, not model latency, and not the prompt or response bodies for the call itself.Tracing is healthy for graph observability. It is not currently giving you model-level cost and latency telemetry.
That is a real limitation of the keyless model path, and it is the trade for not holding an API key in the deployment. It is stated here rather than left for someone to discover while trying to attribute a cost.

​
Checking that tracing is alive

Reports whether the key authenticates, which project the runs are landing in, when the last run was, and the root run names in the recent history. Note what it does not do: trust the configured project name.
A configuration drift worth knowing about. One environment file sets the tracing project to a name no project matches; every trace lands in the real project anyway, because that file is not what the deployed service reads for this variable.Harmless today, and misleading tomorrow. The health probe therefore reports project drift explicitly rather than trusting the environment variable, which is the right posture for any check that could otherwise pass by reading its own configuration.

​
Reading a trace when something went wrong

​
Where it is enforced