Every key the tracing block takes
agent.yaml
langfuse | logfire | coval
required
Which service the spans go to.
logfire is this page. Any other name is
refused, with the accepted names in the message, and leaving the whole
tracing: block out means the agent exports nothing.What you need
One secret:LOGFIRE_TOKEN, a Logfire write token for the project. The agent
fails at startup if it is missing. A missing token means the deployment is
wrong, and failing loudly is better than running for a week without traces.
The token also names the region. A token that starts pylf_v1_eu_ goes to
logfire-eu.pydantic.dev, and one that starts pylf_v1_us_ goes to
logfire-us.pydantic.dev. An older token names no region, and goes to the US
region. That is how the Logfire SDK reads a token, so nothing else needs setting.
To make a write token for a project you already have, run the Logfire CLI:
.env, never in a
committed file.
Service and session names
The service name is<entry-agent>-<agent-name>, where agent-name is the
package’s name: joined to the target it was compiled for. Both targets build
it the same way, so a trace from either one names the same agent the same way.
Each target picks its own session ID from something it already has:
session.id and agent.name go on every span in the call, not only on the top
one, so a query that filters by session finds all of it.
What the spans look like
A call is one trace. Its root span holds the whole conversation ininput.value. Inside it each exchange is a turn span, with what the caller
said in input.value and what the agent replied in output.value.
Every row is labelled the way Logfire’s own integrations label theirs:
LiveKit wraps each model and speech call in spans of its own:
llm_node,
llm_request_run, tts_node, tts_request and tts_request_run. The emitted
project does not send them. Each one only repeats a row the trace keeps, and
Logfire would count llm_node as a second model call. A span started inside
one is moved up to that wrapper’s parent.
Every tool call is its own span, with the tool’s name in gen_ai.tool.name, its
arguments, and, once the call finishes, its result.
Agents and model calls
The call also shows on Logfire’s Agents page, as one run per agent turn. Each run holds its model calls, their tokens and their messages, and its tool calls. Click achat row to open it in the LLM panel.
Logfire counts a model call toward a run only when it sits right under the run’s
span. The emitted project arranges that on each target:
Pipecat keeps a model call’s messages under its own
input and output
attributes. The emitted project copies them to the names the LLM panel reads,
gen_ai.input.messages and gen_ai.output.messages.
On pipecat every run is named after the package, not after the agent that
answered. Pipecat’s tracing does not record which of several agents spoke.
Spans go to Logfire as plain OpenTelemetry over HTTP. The emitted project does
not use the Logfire SDK, so there is no logfire.configure() to call.
Pipecat tracing owns the process OpenTelemetry provider and startup fails if another SDK provider is installed first.
What a trace records
Checking it works
Starting the worker proves nothing on its own. Complete at least one user turn before you look for the trace, or you will be reading an empty one and concluding the wrong thing. Then open the project’s Live view, or query the newest spans for your service name:Where to go next
Langfuse
The other provider for live calls.
Coval
Attach spans to the simulation that produced the call.