Pydantic AI

What it is

Pydantic AI is an open-source Python library from the team behind Pydantic, built for people who already think in models: define the tools and the outputs as types, and the library handles the marshalling, validation and the awkward conversation that happens when the model returns something that does not fit. The spec card above — typed tools and outputs — is the entire pitch, and it is aimed squarely at production code.

It is a library, not a framework with opinions about your architecture. An agent is a small object: a model, some instructions, a set of typed tools. There is no graph to design and no crew to choreograph — what you get is a loop with type safety at both ends, which is a quieter ambition than most of this board and often the more useful one.

How it works

Tools are plain Python functions with type hints and docstrings; the library derives the schema the model sees and validates the arguments that come back. Outputs work the same way: you declare a return type — a Pydantic model, an enum, a primitive — and the model's reply is parsed and validated against it. When validation fails, the error does not merely surface; it is fed back to the model so it can correct itself, which is a small feature that removes a large category of glue code.

Around that core sit the parts a service actually needs: dependency injection so tools can reach your database and config without globals, support for multiple model providers so the model is a parameter rather than a commitment, and instrumentation for tracing and evaluation. For a team that already runs Pydantic across its stack, the marginal concepts are close to zero.

When it earns its place over a plain loop

When the output has to be a value, not prose. A plain loop plus a JSON prompt works until the model omits a field or invents an enum member at three in the morning, and then you are writing validation code anyway — just in the wrong place. If your agent's results feed a database, an API response or another service, typed outputs are not a nicety; they are the contract.

It also earns its place when you want to test agent behaviour as code. Typed tools can be stubbed and asserted on like any other functions, which is a far cry from prompt-hope. If you need orchestration between agents rather than type safety within one, though, this is the wrong tool and a plain loop with a second agent call is closer to what you want.

Limits

• Python only. The spec's language line is a hard boundary; the JavaScript world has other answers.
• Types describe shape, not truth. A validated result can still be semantically wrong — the schema proves the fields are there, not that their contents are right.
• Thin on orchestration. No built-in graph, crew or handoff machinery; multi-agent structure is code you write.
• Provider breadth needs checking. Multi-provider support is a moving target as model vendors change their APIs; verify current coverage in the docs before you design around it.

Alternatives on this board

• DSPy — when the bottleneck is prompt quality against a metric, not output shape.
• LangGraph — when the flow between steps is the hard part and needs to be explicit.
• OpenAI Agents SDK — handoffs and guardrails in a small API, at the cost of OpenAI gravity.
• CrewAI — when the split is by role and the orchestration is the point.