Trace Pydantic AI agents with Maple: export Pydantic AI's built-in OpenTelemetry spans (with or without Logfire) so each conversation is one Maple Agent Session with transcript, tool calls, sub-agent lanes and tokens. Triggers on 'trace my pydantic ai agent', 'add Maple to pydantic ai', 'agent sessions for pydantic ai', 'OpenTelemetry for pydantic ai'.
92%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
Low
Low-risk findings worth noting
Goal: every conversation = one Maple Agent Session. Each agent.run() = one turn (one trace) with transcript, chat spans with tokens, execute_tool spans with args/results, failed tools marked failed, sub-agents in their own lanes.
Mechanism: Pydantic AI's native OTel instrumentation (scope pydantic-ai, GenAI semconv on span attributes). No extra instrumentation package. Maple reads gen_ai.conversation.id as the session key for this framework.
python -c "import pydantic_ai; print(pydantic_ai.__version__)" (or read pyproject.toml / uv.lock / requirements*.txt).
conversation_id=: tell the user to upgrade; do not work around it.ToolFailed needs >= 2.16.TracerProvider(, set_tracer_provider, logfire.configure, opentelemetry-instrument, sentry_sdk.init, instrument_all, Instrumentation(, .instrument =.
TracerProvider exists → add a BatchSpanProcessor(OTLPSpanExporter()) to it; do NOT create a second provider.agent.run( / run_sync( / run_stream( / iter( call, where the chat/thread id lives in the request, every Agent( construction, and every tool that calls another agent's run().logfire.instrument_openai, OpenAIInstrumentor, OpenLLMetry Traceloop.init, a global logfire.instrument_httpx()) → they double-trace model calls. Keep Pydantic AI's; ask before removing the others if they serve something else. logfire.instrument_httpx(client) on a non-model client (tool HTTP calls) is fine to keep.https://ingest.maple.dev. EU: https://ingest.eu.maple.dev.Authorization=Bearer <key>.MAPLE_TEST (ingest accepts and discards it) and tell the user to replace it with their key from Settings → Ingestion.maple_sk_ key in browser code..env, settings module, secret manager) if it has one. Otherwise inline is acceptable: ingest keys are write-only.MAPLE_INGEST_KEY is not set; Maple telemetry export is disabled) and skip the Maple exporter so the app runs normally. Never raise or exit over the key; no bare KeyError on import, no header without a key.ingest_unauthorized ("Invalid ingest key") with a key you trust usually means the key belongs to the other region (keys are region-bound): try the other endpoint.Env vars (the exporter reads them when it is built; it appends /v1/traces). If the app loads .env (load_dotenv()), call it at the top of the tracing module, before the exporter or logfire.configure(); otherwise the exporter silently targets localhost:4318 with no key.
OTEL_EXPORTER_OTLP_ENDPOINT=https://ingest.maple.dev
OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer <key>"
OTEL_EXPORTER_OTLP_PROTOCOL=http/protobufAdd with the repo's package manager (uv/poetry/pip):
pip install "pydantic-ai-slim[openai]>=2.51" "opentelemetry-sdk>=1.45" "opentelemetry-exporter-otlp-proto-http>=1.45"Keep the project's existing pydantic-ai extras; only add the two OTel packages if pydantic-ai is already installed.
Create tracing.py (adapt service name / environment to the project):
from opentelemetry import trace
from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter
from opentelemetry.sdk.resources import Resource
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from pydantic_ai import Agent, InstrumentationSettings
provider = TracerProvider(
resource=Resource.create(
{"service.name": "support-agent", "deployment.environment.name": "production"}
)
)
provider.add_span_processor(BatchSpanProcessor(OTLPSpanExporter()))
trace.set_tracer_provider(provider)
Agent.instrument_all(
InstrumentationSettings(
tracer_provider=provider,
include_content=True,
include_binary_content=False,
)
)main.py, worker). It must run before the first agent.run(); agents constructed earlier are still covered.Agent.instrument_all(InstrumentationSettings(include_content=True, include_binary_content=False)) (uses the global provider).version=. Default 5 is the tested format; 2-4 are deprecated.service.name (never leave unknown_service).Keep the Step 1 env vars; they must be in os.environ before logfire.configure() runs. Logfire then adds OTLP span, metric and log exporters for this endpoint; pass metrics=False to logfire.configure() if only traces are wanted.
Do not install the Step 2a OTel packages: logfire already depends on the SDK and the OTLP/HTTP exporter, and logfire 5.1.x pins opentelemetry-sdk<1.45, so adding opentelemetry-sdk>=1.45 makes the install unresolvable. Tested with logfire 5.1.1 (OTel SDK 1.44.0).
import logfire
TOOL_CONTENT = {"gen_ai.tool.call.arguments", "gen_ai.tool.call.result", "final_result"}
def keep_tool_content(match: logfire.ScrubMatch):
if len(match.path) > 1 and match.path[1] in TOOL_CONTENT:
return match.value
logfire.configure(
service_name="support-agent",
environment="production", # adapt to the project
send_to_logfire=False, # keep the project's existing value as is (incl. 'if-token-present'); False only if unset
scrubbing=logfire.ScrubbingOptions(callback=keep_tool_content),
)
logfire.instrument_pydantic_ai()session, auth, password, cookie, secret, api key... with [Scrubbed due to '<word>']. gen_ai.conversation.id and message attributes are exempt. If the project already has a scrubbing config, merge the callback into it instead of replacing it.Agent.instrument_all(...) with another provider.Pydantic AI resolves gen_ai.conversation.id per run as: explicit conversation_id= > id on the last message of message_history > fresh UUID7. Pass it explicitly on EVERY run call, from the app's chat/thread/conversation id:
result = await agent.run(text, conversation_id=chat_id, message_history=history)async with agent.run_stream(text, conversation_id=chat_id, message_history=history) as run:
async for delta in run.stream_text(delta=True):
yield deltarun_sync(, iter(, run_stream_events(, and the resume run that sends DeferredToolResults.uuid4() per request, no module-level default.async with open until the stream is consumed (in FastAPI, inside the generator passed to StreamingResponse), or the invoke_agent span ends early.include_content=True): gen_ai.input.messages, gen_ai.output.messages, gen_ai.system_instructions on chat spans; tool args/results on execute_tool spans. Maple's transcript needs these.include_binary_content=False (base64 media repeats in every later chat span).include_content=False globally, or per agent: Agent(..., capabilities=[Instrumentation(settings=InstrumentationSettings(include_content=False))]) (from pydantic_ai.capabilities import Instrumentation; omit tracer_provider to use the global one). Tell them the transcript keeps roles but no text.redaction/transform processor.Agent(..., name="support"). Unnamed agents become agent and share one lane.raise ToolFailed("message") (from pydantic_ai import ToolFailed, >= 2.16). Span ERROR, message recorded as gen_ai.tool.call.result, run continues, no retry budget used.
ModelRetry also marks the span ERROR (one failed call per retry): use it only for real retries.return {"error": ...} / return "Error: ..." in tools with raise ToolFailed(...) only where the user agrees; returned errors show as successful calls.@orchestrator.tool
async def research_weather(ctx: RunContext[None], city: str) -> str:
"""Delegate to the weather worker."""
result = await weather_worker.run(
f"What is the current weather in {city}?",
usage=ctx.usage,
conversation_id=ctx.conversation_id,
)
return result.outputWithout conversation_id=ctx.conversation_id each delegate mints a UUID7, so one trace carries several ids and Maple may file the trace under the wrong session or split the turn.
4. Sequential pipelines of top-level runs (orchestrator run, then summary run): pass the same conversation_id= to each; each run is its own trace/turn in the same session.
trace.get_tracer_provider().force_flush() in a finally in the handler.provider.shutdown() at the end (finally).force_flush() after each task/cell that runs an agent.logfire.force_flush() / logfire.shutdown().Run one real conversation: 2+ messages with the same id, at least one tool call, one streamed message if the app streams, and a sub-agent call if the app delegates. If the app has no scriptable entry point (server, UI only), write a small driver for this run: one conversation id, 2+ turns, a tool call, flush before exit. Then check (Maple → Agent Sessions, filter by the service name; wait ~30 s):
run(); transcript shows user prompts, assistant replies and tool calls.invoke_agent <name>, chat <model>, execute_tool <tool>; each chat/execute_tool is inside its run's invoke_agent in the same trace.chat span has input and output tokens, including the streamed one.name=, all under the caller's session.Bearer token.With the Maple MCP: list_agent_sessions with search=<conversation id> returns one row.
Quick local cue: Pydantic AI 2.51 prints an observability: off banner on the first run when no instrumentation is set; it disappears once instrument_all() (or logfire.instrument_pydantic_ai()) has run.
Without Maple access (or with MAPLE_TEST), both must hold; silence alone proves nothing (no spans is silent too):
Failed to export / 401 lines on stderr.gen_ai.conversation.id, identical across runs of one conversation and on delegate spans. Add it temporarily: plain path provider.add_span_processor(SimpleSpanProcessor(ConsoleSpanExporter())); Logfire path logfire.configure(..., additional_span_processors=[SimpleSpanProcessor(ConsoleSpanExporter())]) (both from opentelemetry.sdk.trace.export). On the Logfire path its own console prints <agent> run / running tool: <x>; exported span names are still invoke_agent / execute_tool.ToolFailed → span ERROR, model sees message, run continues; ModelRetry → ERROR, one failed call per retry; other exception → ERROR, run raises, failed turn; return {"error": ...} → UNSET, shows as successful call.requires_approval=True) pause the run with no tool span; the execute_tool span appears only in the resumed run (the one sending DeferredToolResults). Same conversation_id= → paused and resumed runs are two turns of one session, both labeled with the original request.execute_tool <x> span whose only child is invoke_agent <worker> shows as a delegation; the tool's args/result become the lane's input/output. Several delegation tools in one model reply run concurrently, so lanes overlap in time.include_content=False also drops exception messages (only the exception type is kept).version: 5 default (tested); 2-4 deprecated with PydanticAIDeprecationWarning (version 2 used different span names); 6 is opt-in and sends tool results with role: "tool". Fix the warning by removing version=.chat spans carry gen_ai.usage.input_tokens, gen_ai.usage.output_tokens, plus gen_ai.usage.cache_read.input_tokens / gen_ai.usage.cache_creation.input_tokens when the provider caches. invoke_agent carries run totals under gen_ai.aggregated_usage.*, which Maple does not add to the session total. Delegate tokens stay on the delegate's spans.stream_options.include_usage), so streamed calls have tokens. Time-to-first-chunk is recorded under a key Maple doesn't read yet.operation.cost on chat spans when it can price the model, and Maple shows it. Maple never prices tokens itself; a model Pydantic AI can't price shows as unpriced.send_to_logfire=True (or a Logfire token in env) sends to both Logfire and Maple.[openai] for anthropic, google, openrouter, ...; the full pydantic-ai package also works.instrument_openai(), OpenInference, OpenLLMetry) double-traces model calls; keep Pydantic AI's.chat spans: binary content recorded as base64; set include_binary_content=False.event_mode="logs": content moves to logs, which Maple doesn't read (empty transcript).session.id or maple_ai.session.id: Maple reads gen_ai.conversation.id here; maple_ai.session.id re-vendors the span.MapleTechLabs/maple
e8695de
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.