Pydantic AI

Last updated: Nov 4, 2026

---

Rationale

Pydantic AI is a Python-first agent framework to build production-grade, type-safe AI applications. It integrates with the primary model providers. Its purpose is predictable and validated inputs and outputs, it gives real-time observability, and it uses plain Python composition. Pydantic AI gives a type-safe design, real-time debugging, and performance monitoring through Pydantic Logfire. It is a good tool for AI projects that must have flexible and efficient agent composition with standard Python best practices.

These are its strengths:

• Model-agnostic: It supports OpenAI, Anthropic, Gemini, DeepSeek, Ollama, Groq, Cohere, and Mistral. Its interface makes it easy to add other models.
• Structured responses: Pydantic validation applies exact schemas. Thus, the outputs are more consistent from one run to the next.
• Type-safe by design: Strong typing makes the code clearer and refactoring easier.
• Logfire integration: It gives real-time debugging, performance monitoring, and behavior tracing for LLM applications.
• Cache-aware reasoning: It manages the interaction between prompt caching and thinking modes better than other frameworks.
• MCP support: Agents are MCP clients that connect to MCP servers and use their tools.
• Pythonic control: It has easy dependency injection, branching, and testing with standard Python.
• Built-in evals: It has a code-first evaluation framework with datasets, cases, and LLM-as-judge scoring to benchmark the quality of agents.
• User-friendly: It is ready for enterprise applications that must be very accurate. Its behavior is predictable, it has very little boilerplate, and you can change models easily.

Alternatives

LangChain

LangChain is a general-purpose framework for LLM applications. It has many integrations and patterns (chains, tools, agents, graphs).

Pros:

• It is very flexible and it has many features.
• It has a wide ecosystem and many integrations.
• It supports large pipelines and agent or graph patterns.

Cons:

• Because LangChain is flexible, it is also not easy to use. It is hard to learn, and it has some abstractions that overlap.
• Its integrations are in different lightweight packages. When you change models, you frequently must install more packages and change the code. Thus, it can have more boilerplate and configuration than Pydantic AI.
• MCP integration can be hard. The MCP Toolbox documentation does not explain its use clearly.
• Its type safety is not as good as the type safety of Pydantic AI.

Datadog LLM Observability

Datadog is a wide observability platform that at this time also does LLM monitoring and evaluations. It gives traces, cost tracking, hallucination detection, and side-by-side model benchmarking.

Pros:

• It is a mature observability platform with good dashboards, alerting, and cost and token tracking.
• It has built-in LLM evaluations by default: accuracy, faithfulness, relevancy scoring, and RAG pipeline testing.
• It gives one view of frontend sessions, LLM execution, and backend services.

Cons:

• It gives only observability and evaluations. Datadog does not give an agent framework. Thus, you must also use a different library (LangChain, custom code, or other) to build and run agents, and the stack has more parts.
• It does not have a built-in model-agnostic abstraction layer. To change providers, you must use more tools or write your own wrappers. Pydantic AI has one interface for OpenAI, Anthropic, Gemini, and other providers.
• It does not have type-safe structured inputs and outputs. You must do the output validation and schema enforcement separately.
• Pydantic AI includes evals (pydantic-evals), observability (Logfire), and type-safe model-agnostic agent development in one Python-native stack. Thus, it is not necessary to integrate different specialized tools.

rig (Rust)

rig is the most mature LLM agent framework in the Rust ecosystem. It gives structured extraction and a model-agnostic client to build agents in a systems language.

Pros:

• It has native performance and one static binary, without a Python runtime to ship.
• It has structured, type-safe extraction that the Rust type system supports.
• It is a reasonable alternative when the core of a component is deterministic Rust and the model is not the product, but only a part at the edge.
• At this time, Rust is the usual language of Fluid Attacks for new components. It has all the advantages that make Rust the default language in other parts of the stack: the compiler finds type errors, there are no runtime GC pauses, and it has memory and data-race safety without a garbage collector.

Cons:

• It has evaluation support, but this support is much less mature than pydantic-evals. It is weak for hard evaluations, for example, scoring of more than one run or a custom prompt for the LLM judge. Thus, you must build most of a large evaluation suite by hand.
• It does not emit the OpenTelemetry GenAI conventions. Thus, observability (conversational context, token usage, cost) must have hand-written instrumentation and a pricing table that you maintain. Logfire traces a Pydantic AI run without instrumentation code.
• On Amazon Bedrock, rig-bedrock stops prompt caching when thinking is on. This increases the cost of long agent loops, and the consumer cannot avoid this problem (read the analysis in work item #25198).
• At this time, its version is earlier than 1.0 (0.38.x when Fluid Attacks wrote this page), and it changes quickly. Thus, its API changes frequently, and upgrades frequently have breaking changes that the consumer must manage.
• Its ecosystem is much smaller than the Python LLM stack. Thus, most of the related tools are not available at this time. You must build and maintain the missing parts by hand. This takes much engineering time for plumbing, and not for the product.

Flue (TypeScript)

Flue is a headless, programmable agent framework in TypeScript from the team of Astro. Its core primitive is the agent harness (sessions, tools, sandbox, and skills), and not the model orchestration loop.

Pros:

• It has very lightweight isolated sandboxes. It ships just-bash, an in-memory Bash simulation written in TypeScript, for fast file reads and exploration without infrastructure cost and without Docker containers. For heavy or destructive runs, it can move the work to a local() sandbox or to Daytona without more tools.
• It has operational resilience through durable streams. It writes each prompt, model response, and tool result to an append-only ledger. Thus, if the host restarts during a loop, the framework continues the run from the point where it stopped. Thus, it is not necessary to send expensive Bedrock calls again.
• It has Markdown-based directives (skills). Long system prompts and instructions are in .agents/skills Markdown files, and Flue imports them dynamically as structured context. Thus, you can change review guides without a change to the TypeScript logic.

Cons:

• Its Amazon Bedrock support is fragile. The cause is the underlying pi-ai networking adapter, and it fails in these different ways:
  • It always adds a one-hour cache TTL for Claude models earlier than 4.5, and Bedrock rejects this TTL as a validation error.
  • When a stream stops during reasoning, it keeps an empty thinking signature. Thus, Bedrock rejects the next turn with a missing-signature error.
  • It silently stops the output at 4,096 tokens if you do not set maxTokens explicitly on each call. Thus, it cuts long analyses.
• Its API is volatile. At this time, it is in 1.0 beta and it changes quickly. It came as a large rewrite in mid-2026, its underlying agent core (pi) got a new name in a namespace move, and new top-level primitives continue to come between beta releases. The maintainers say clearly that the APIs can change. Thus, upgrades frequently have breaking changes that the consumer must manage.
• On AWS, it is operationally heavy. Lambda is the usual serverless location for an agentic workload, but Flue cannot run on it by design, because its Node server runs for a long time and keeps state. Thus, the documented AWS path is a persistent container on ECS/Fargate. To keep its durable state that can continue after restarts, you must add an RDS Postgres instance through its @flue/postgres adapter. Without this instance, sessions and run history are only in process memory.

Usage​

Fluid Attacks uses Pydantic AI for the AI agents of these components: sifts, reviews, explores, interacts, traces, fixes, matches, aggregates, and skims. Pydantic AI does these tasks in these components:

• Agent runs
• MCP integration with AI Agent (only in interacts)