--- title: "AI & LLM Observability" description: "See every agent decision, tool call, and downstream service in one trace with Pydantic Logfire." --- # AI & LLM Observability

See every decision your agent makes and everything it triggers. Tell a prompt problem from a service problem before you change production.

Logfire turns an agent run into one trace (the full journey of one request or agent run, made of nested spans): the model calls, tool calls, database queries, API requests, and response your user receives.

An agent trace with model, tool, and database workA complete agent run: the agent calls a model, then an inventory tool, which queries a database, before the agent returns a response. The database span is visibly slow, showing why full-stack context matters.trace · inventory-agent.runsample runAgentLLMToolDatabaseinventory-agent.runmodel.generate1.8k tokenssearch_inventorySELECT inventory1.2 sHere's what happenedOne trace gives you evidence to investigate a wrong or slow answer.
**Before you explore:** this page explains what Logfire can show once your application is sending traces. [Send your first trace →](first-trace.md)
## Follow the complete agent loop
- [__Inspect a single run__](guides/web-ui/llm-panels.md) Read the messages, model settings, tool arguments, results, tokens, cost, and latency that produced one answer. - [__See the work behind each tool__](guides/web-ui/live.md) Follow a tool call into the database, API, queue, or service it touched. The trace keeps the causal chain intact. - [__Find expensive or unreliable paths__](guides/web-ui/llms.md) Compare models and agent runs by cost, error rate, latency, tokens, tool calls, and turns. Then drill into the trace.
## From a bad answer to a useful diagnosis An agent recommends an item that cannot arrive by Friday. The trace can show two very different failures. - The agent never passed the delivery constraint to `search_inventory`. That is a prompt, model, or tool-selection problem. - The agent passed the constraint, but the inventory service returned stale delivery data. That is a system problem. Both failures look like a bad answer to the user. They need different fixes. Logfire keeps the agent's decisions and the work they triggered in the same trace, so you can change the right part of the system. ## Improve the next run with evidence
- [__Turn failures into evals__](evaluate/overview.md) Build datasets from the cases that matter, compare changes before release, and score live traffic after it ships. - [__Iterate on prompts safely__](reference/advanced/prompt-management/index.md) Version prompts, test them against representative inputs, and promote the version that performs better. - [__Ask production data better questions__](how-to-guides/mcp-server.md) Query traces with SQL yourself, or connect the Logfire MCP server so your coding agent can investigate with you.
## Instrument the stack you have Start with a one-line integration for [Pydantic AI](integrations/llms/pydanticai.md), [OpenAI](integrations/llms/openai.md), [Anthropic](integrations/llms/anthropic.md), [LangChain](integrations/llms/langchain.md), or another supported framework. Logfire also accepts [OpenTelemetry (OTel), the open industry standard for collecting traces, metrics, and logs](how-to-guides/alternative-clients.md), so a TypeScript frontend, Python agent service, and Go backend can all appear in the same trace. [See all integrations →](integrations/index.md) ## Control cost and routing (optional) To cap what your app can spend on models, fail over between providers, or keep one API key for many models, route your calls through the [AI Gateway](reference/advanced/gateway/index.md). This is optional: the instrumentation above is all you need to trace and debug your agents.