What your Pydantic AI traces turn into
Complete typed-agent runs you can follow end to end, with recurring validation and tool failures already grouped for you.
- Complete agent runsFollow the user request, model turns, tool calls, retries, and validated final output in one trace.
- Models, tools, and validationAgent runs, model requests, tool execution, arguments, results, and structured output attempts appear as nested spans.
- Errors and retry loopsInspect tool exceptions, invalid arguments, output validation failures, exhausted retries, and runs stopped by a usage limit.
- Cost, latency, and metadataFilter token usage, the cost Pydantic AI computes per call, time to first chunk on streamed runs, model, agent name, and the release, user, and environment you attach.
Three steps to your first Pydantic AI trace
Initialize Latitude, enable Pydantic AI's native instrumentation, and wrap the agent entrypoint.
Install the SDK
Python 3.11+. Both packages resolve together on a clean environment.
Enable instrumentation
Pydantic AI creates OpenTelemetry spans for agent runs, model requests, and tool execution. capture() adds session and user context.
Run one agent turn
Open Traces. Inspect every model request and tool execution, including arguments, results, token usage, and final output.
The Latitude SDK registers shutdown handlers. Short-lived scripts and notebooks should still call latitude.shutdown() so buffered spans finish exporting. Pydantic AI integration guide →
Debug Pydantic AI failures in production
The validation, retry, tool, streaming, and model failures that appear after typed agents meet real inputs.
Validation retries exhaust the run
Tool arguments or structured output fail Pydantic validation repeatedly. Read the retry prompt on each following model request, then group the inputs that exhaust the retry budget into a Signal.
Tools receive valid data with the wrong meaning
Arguments satisfy the schema while selecting the wrong customer, date, or action. Search tool-call spans by intent and compare affected sessions.
Tool and model loops burn the usage budget
The agent repeats model requests or tool calls until a request, token, or tool-call limit stops the run. The Thrashing flagger and usage metadata surface the pattern.
Regressions after a schema or model change
A new output type, tool schema, prompt, provider, or model raises validation and failure rates. Tag traces by release and let resolved Signals reopen when the issue returns.
Find recurring failures hidden across Pydantic AI sessions
Reading traces one at a time finds the failure you went looking for. Latitude surfaces the one costing you the most sessions.
Search
Describe it in plain language
Find sessions by meaning, exact text, or metadata. The query above finds traces that never use those words.
Behaviors
Grouped by what users tried to do
Whole sessions clustered by intent and outcome, so patterns surface without you writing the query.
Signals
One named, tracked problem
Repeated failures become one Signal with a trend, affected sessions, and a lifecycle. Flaggers feed it automatically.
From production failure to verified fix
Turn a recurring Pydantic AI failure into a regression test, an opened PR, and a verified fix.
Latitude detects and verifies. Your coding agent writes the fix. You review the PR.
Fits the Pydantic AI stack you already have
- Python 3.11+
- Native OpenTelemetry GenAI spans
- Agents, tools, toolsets, structured outputs, and streaming
- Any supported model provider
- Content capture can be disabled in Pydantic AI
- Cloud or self-hosted (MIT)
Using Pydantic Logfire or another OpenTelemetry backend?
Keep it. Pydantic AI uses OpenTelemetry, and the same tracer provider can export to multiple destinations. Configure Logfire with its own destination and add Latitude through an additional span processor or OTLP export path.
Latitude does not import historical Logfire traces. Search, Behaviors, and Signals begin building from newly exported Pydantic AI runs.
When do you need more than Pydantic AI logs and traces?
A typed trace explains one run. Latitude shows which validation, tool, and behavior failures keep affecting production sessions.
| Capability | Application logs | Basic tracing / Logfire | Latitude |
|---|---|---|---|
| Complete agent sessions | Limited | Yes | Yes |
| Semantic search across sessions | No | Varies | Yes |
| Recurring failure detection | Manual | Varies | Signals |
| Production traces into evals | No | Varies | Yes |
| Dispatch and verification | No | No | Yes |
MIT
Open source, 4.6k stars
20K
Free credits a month, 30-day retention
Unlimited
Seats on every plan, no per-user pricing
GDPR
Compliant, data in AWS eu-central-1
Pydantic AI observability FAQ
How do I add observability to a Pydantic AI agent?
Install latitude-telemetry and pydantic-ai, initialize Latitude, call Agent.instrument_all(), and run the agent inside capture() when you want Latitude session and user context. Pydantic AI emits the agent, model, and tool spans through OpenTelemetry onto the provider Latitude registers, so you do not need an instrumentations entry for it.
What does Latitude trace in Pydantic AI?
Each agent run arrives as one span with nested model-request and tool-execution spans. Model spans carry the input and output messages, model name, provider, finish reason, prompt and completion token counts, the tool definitions sent with the request, and the cost Pydantic AI computes for the call. Tool spans carry the tool name, arguments, and result. The agent span carries the agent name, conversation id, aggregated token usage, and the validated final output. Streamed runs also record time to first chunk. The exact content follows your Pydantic AI InstrumentationSettings.
Can I prevent prompts and tool data from being exported?
Yes. Call Agent.instrument_all(InstrumentationSettings(include_content=False)) to omit prompts, completions, tool arguments, tool results, and other message content while keeping the structural telemetry: span names, roles, token counts, latency, and status. Binary content and large model-request parameters can be disabled separately with include_binary_content and include_model_request_parameters. Note that tool definitions, which include tool names, descriptions, and parameter schemas, still export.
Can I use Latitude with Pydantic Logfire?
Yes. Both use OpenTelemetry, and the same spans can reach more than one destination. Latitude receives the full Pydantic AI trace whether you configure Logfire before or after initializing Latitude: initialize Logfire first and Latitude attaches its span processor to the provider already registered. If you configure Logfire with send_to_logfire=False, only the other OpenTelemetry destination receives the spans.
Does Latitude treat approval and deferred tool calls as errors?
No. Latitude renders the status Pydantic AI emits, and with instrumentation format version 5 these are control-flow events. A tool that raises CallDeferred gets a tool span with unset status rather than error status, a tool marked requires_approval produces no execution span until it is approved, and the agent run itself also stays unset.
Does Latitude sample Pydantic AI traces?
Latitude captures 100% of the traces it ingests within your retention window. LLM-based flaggers and evaluations can sample at analysis time, starting around 10% by default, and that coverage can be increased.
Trace your first Pydantic AI agent run
Connect Pydantic AI's native OpenTelemetry spans, run one production-like session, and inspect model, tool, validation, and output execution in Latitude.
No credit card required.
Trace your Pydantic AI agents in production