Pydantic AI

This is the framework for people who already hand their data to Pydantic. Structured outputs, typed dependency injection and typed tools mean your editor knows what an agent returns before anything runs, and that is the trait you feel hourly rather than during a demo. Changing model provider is a string, so a swap reads as a diff instead of a migration.

It will not organise a long stateful workflow on your behalf, and the coding-agent pieces sit in a companion package you opt into. Pick it for typed application code with a model in the loop. Pick LangGraph when control flow and resumption are the actual difficulty.

The risk is fragmentation. The core is one distribution, the protocol support arrives as an extra on a slim variant, and memory, sub-agents, context compaction and a full coding agent live in a second package. Three release cadences behind one advertised product is a version matrix you inherit, and a break across that seam costs you an afternoon of bisecting somebody else's dependency graph.

Pin them together and read both changelogs as one. Done right: durability is delegated rather than reinvented. Long-running work is handed to Temporal, DBOS or Prefect, systems that already survived production, instead of a retry loop written by an agent library.

1. Context is supplied through typed dependency injection, so what an agent may read is declared in a signature rather than assembled inside a prompt. 2. Actions are tools whose arguments are validated before the function body executes. 3. Verification is doubled. A structured result is parsed and checked against its declared type before reaching the caller, and the evaluation package asserts behaviour the way a test suite asserts code.

No benchmark is published, which is consistent. A library whose entire claim is type discipline gains nothing from a leaderboard, and reviewing a project that declines to offer one is a small relief.

The distribution here is unusual and almost entirely unpriced. This team maintains something nearly every Python service already imports, which is the cheapest route into a new category anyone on this board has, and the product page carries names including Atlassian, JPMorgan Chase, Microsoft, NVIDIA and Walmart. Logfire is the monetisation; the agent library is the introduction.

The soft spot is that observability is crowded and the emitted format is deliberately standard, which lowers the cost of leaving the paid tier. Likely acquirer: an observability incumbent, or a cloud buying the Python developer relationship. Position: long the library, and read the hosted terms before a team standardises on them.

The demo is an agent returning a validated object, which is exactly as exciting as it should be. Procurement is short. Nothing to buy, no seats to multiply, nobody holding our data. It emits OpenTelemetry over OTLP, so agent traces land in the monitoring stack we already pay for and the telemetry discussion closes before it opens. Background work runs on a durable queue our platform team already operates.

It runs unattended, so agents sit in the pipeline beside the tests instead of inside one person's editor. Onboarding is brief for anyone writing typed Python, which here is everyone. Approved, with a named owner for upgrades.

MIT, which is the licence I stop arguing about. One uv add and the loop runs; the mcp extra on the slim distribution turns tool servers into an install and a class rather than a plugin registry with opinions. Ollama sits in the provider list, so the model can be the machine in the corner and the calling code never notices.

The offline test model is what I appreciate most. I can build an entire agent on a plane with no key and no meter running. Nothing here needs the company's hosted service, and a fork would be maintenance rather than archaeology.