PydanticAI - The NEW Agent Builder on the Block

PydanticAI positions itself as a new, Pydantic-first agent and LLM application framework built to make model outputs reliably conform to structured schemas—so results can be used programmatically instead of treated as free-form text. The core idea is familiar from earlier “LLM + validation” patterns: define a data model, validate the model’s response against it, and—when needed—prompt the model to correct its output. What’s new is the shift from “plug Pydantic into an agent framework” to “build an LLM framework on top of Pydantic,” with the surrounding features—system prompts, tool use, chat history, and RAG-style workflows—designed to work with that validation layer.

The pitch matters because most agent frameworks already rely on schema validation somewhere in the pipeline, but teams still face friction: keeping outputs consistent, wiring structured results into downstream code, and managing production control flow. PydanticAI claims to address these issues with model-agnostic support (OpenAI, Google Vertex AI/Gemini, Grok, and planned Anthropic support), type-safe design, and “vanilla Python” control flow for agent composition. That Pythonic approach is presented as a production advantage: rather than relying on complex orchestration abstractions, developers can restructure state and workflow logic directly in Python.

From there, the walkthrough demonstrates three practical capabilities. First is straightforward chat prompting: create an agent with a system prompt and a user prompt, then swap models (e.g., using Gemini 1.5 Flash) and adjust the system prompt dynamically via injection. Second is structured output. By defining a Pydantic class for the expected response (example fields include city, country, and a reason), the model returns neatly formatted data. The example extends the schema to include a “famous person from the city,” showing how adding fields to the schema changes the output contract while keeping the rest of the workflow intact. The results are also inspectable—down to token usage—and accessible as Python objects or JSON.

Third is tool use / function calling. A weather agent is built with two tools: one tool resolves a location description into latitude and longitude, and a second tool uses those coordinates to fetch weather details (temperature and a natural-language description derived from API codes). When API keys are absent, the tools return dummy responses, but the tool-calling trace still shows the model deciding which tools to call and in what order. The example demonstrates multiple tool calls in one run (London and Singapore), followed by a final natural-language response that combines the tool outputs.

Overall, PydanticAI is framed as a compact alternative to heavier agent stacks: schema-driven reliability, dynamic prompt/tool injection, explicit message history management, and streaming-friendly structured output—implemented in a way that aims to stay readable and easy to adapt for real deployments. The accompanying mention of Logfire adds an observability option for tracking inputs and outputs, though it’s treated as optional rather than required.