Pydantic AI uses Pydantic models to define structured results and tools, then validates the model's output and asks it to try again when validation fails.
2
The framework is designed for production Python applications, with dependency injection, static type checking, model support, and observability through Pydantic Logfire.
3
Samuel Colvin wants Pydantic AI to remain a thin library, adding structured support for agent handoffs, multi-agent composition, tool sets, Open API, and Model Context Protocol.
Summary
Samuel Colvin explains why the Pydantic team built Pydantic AI after finding existing agent frameworks unsuitable for the production applications they wanted to build. Pydantic models already define types, coerce values, generate JSON Schema, and validate structured responses. Pydantic AI uses those capabilities for tool calls and agent results. It adds reflection when validation fails, dependency injection with static type safety, and integrations with several model providers. Colvin shows an example where an agent finds locations, gets their coordinates, calls a weather tool, and returns the result. He also argues that observability is necessary because developers need to see tool calls, timings, token costs, and HTTP requests. Planned work includes direct agent handoffs, multi-agent composition, tool sets, Open API support, and Model Context Protocol support. His design preference is to keep the library relatively thin and let ordinary Python handle application-specific control flow.
Pydantic's existing type system fits structured model output
Colvin starts with Pydantic's original purpose: defining Python types and enforcing them at runtime. Pydantic can coerce an integer supplied as a string, convert a string into a date, and perform similar conversions from JSON. It also generates JSON Schema. That schema support was originally built for APIs, before the team knew it would help language models define tools. The same model can describe a tool's parameters and validate the JSON returned by a model, including producing errors when the data is invalid.
Pydantic AI turns models into tools and validated results
Pydantic AI builds on the pattern already used with OpenAI tool calls. A Pydantic model can define the result type, while its name and docstring provide the tool name and description. When validation fails, Pydantic AI sends the validation errors back to the model and asks it to try again. Colvin presents this as a framework for structured outputs rather than a special-purpose demo layer.
Dependency injection and typing target production applications
The framework lets developers define dependencies such as an HTTP connection and API keys, then pass them into an agent run. Tools access those dependencies through typed context. Static analysis with tools such as mypy or pyright can catch an incorrect dependency type or an invalid attribute access. Colvin says this matters more in a real application than in a short presentation because dependency injection and type safety make larger programs easier to maintain.
In Colvin's example, the model receives a request for weather in London and Wiltshire. It extracts the locations, calls a latitude-and-longitude tool for each one, then passes those coordinates to a weather tool. The model decides whether to call the discretionary tools. In the live run, the two location calls and two weather calls happen in parallel before the agent returns a response.
Colvin argues that developers need to inspect an agent's internal work. Pydantic AI has an optional integration with Pydantic Logfire, which shows the tools an agent called and how long they took. The dashboard also includes the timing of language-model and HTTP calls, along with token cost and per-operation details. He presents this as a way to understand agent behavior rather than treating the final answer as sufficient evidence.
Colvin describes planned support for registering one agent directly with another. The agents would share a dependency type, allowing dependencies to pass through a run with type-checking support. He also wants composition across multiple agents in sequence. A structured API could make it possible to build a static state machine showing which agents are called, under which conditions, and how the flows connect. He says Pydantic AI agents are deliberately small components that can be composed into a larger system.
Tool sets will connect applications to external interfaces
The planned tool-set abstraction would let developers register groups of tools instead of adding each tool individually. Colvin mentions tool sets based on Open API endpoints, JSON Schema, Model Context Protocol, or user-defined implementations. The aim is to reduce repeated integration code for services such as a Slack API and make reusable tool sets available to applications.
The framework stays thin and leaves application logic in Python
When asked about custom control flow, Colvin says developers can put their own branching logic inside a tool, or use structured results when a tool call should be required to finish a run. He describes a planned way to end a run early from a function tool. His broader rule is to avoid adding esoteric syntax when ordinary Python can handle the behavior, because every extra library feature becomes a long-term maintenance obligation.
"Pydantic AI is not about producing the best possible demo or giving you the easiest experience in the first 10 minutes, it's about building production applications."Samuel Colvin07:50
Who should watch
You are building a Python agent and want structured outputs, typed dependencies, and validation without adopting a large agent framework.
Your agent makes several tool calls and you need to inspect timing, token costs, HTTP requests, and the exact sequence of operations.
You are deciding how to compose multiple agents or expose external APIs as tools while keeping application-specific control flow in ordinary Python.
