PydanticAI 1.87.0 Is a Bet That Agent Frameworks Need Better Middleware, Not More Marketing

The most useful agent-framework releases are often the least marketable ones. They do not announce a new “agentic paradigm.” They do not ship a glossy orchestration diagram with five anthropomorphized subagents high-fiving each other across a slide deck. They quietly improve the middleware layer where approvals, streamed events, and provider quirks either become composable runtime behavior or collapse into callback soup. PydanticAI v1.87.0 is that kind of release.

The changelog is short: HandleDeferredToolCalls, ProcessEventStream, and GPT-5.5 thinking-setting support. Most people will read that and move on. That would be a mistake. This release is really about a framework choosing to formalize the messy middle of agent systems, the part between “the model emitted a thing” and “the application safely turned that thing into work.” That middle layer is where most teams end up reinventing fragile abstractions by hand.

PydanticAI has been clear about the product it wants to be. The docs pitch a Python agent framework that is model-agnostic, type-safe, observability-friendly, and built around composable capabilities rather than a monolithic all-knowing runtime. It supports MCP, A2A, UI event streams, human approval, durable execution, structured output streaming, and graph-based control flow. That is a lot of surface area, but the underlying pitch is coherent: use strong typing and explicit capabilities to make agent systems feel more like disciplined software and less like a pile of loosely supervised async side effects.

v1.87.0 strengthens exactly that thesis. PR #5142 adds a handle_deferred_tool_calls hook on AbstractCapability plus a HandleDeferredToolCalls capability that resolves approval-required and externally executed tool calls inline during agent runs. The PR notes eight tests covering approval, denial, partial resolution, sync handlers, fallback, and unresolved-error paths. That test list matters because it reflects a level of seriousness still missing from a lot of agent tooling. Deferred tools are not an edge case anymore. They are the normal shape of any system that involves human approval, external executors, compliance controls, or tools that cannot be run synchronously inside the same runtime boundary.

Many frameworks still treat those paths as application-specific awkwardness. They hand you a callback, maybe an interrupt event, and wish you luck. That approach works right up until your product needs approvals for only some tools, external execution for others, and reliable resume semantics when a user comes back ten minutes later. Then you discover that “we support human in the loop” often means “we emitted an event and now it is your problem.” PydanticAI is trying to move that burden down into the capability layer, which is exactly where it belongs.

Event streams are not telemetry exhaust anymore

The other big addition, PR #5141, is even more strategically interesting. ProcessEventStream can operate as either an observer or a processor over the event stream. An observer watches the stream and can back-pressure downstream consumers if it is slow. A processor can modify, drop, or add events before other consumers see them. That sounds subtle. It is not.

Event streams are where the modern agent stack gets real. The model emits partial output. The framework turns that into structured events. A UI listens for them. A trace pipeline records them. A human-approval step may block on them. An orchestration layer may branch on them. If the framework treats that stream as raw plumbing rather than a programmable interface, every serious product ends up building a second framework on top of the first one. That is how callback jungles happen. It is also how seemingly simple features, like “show the user why the workflow paused” or “scrub one sensitive event before it hits the frontend,” turn into bespoke architecture projects.

Giving developers an explicit observer-or-processor layer is a smart move because it admits the obvious truth: the event stream is not just debug exhaust. It is an application surface. The distinction between observer and processor is also healthy. Too many frameworks blur “watch this stream” and “rewrite this stream” into one magic interception hook. PydanticAI is being more honest about the cost and power of each. If your observer is slow, the downstream stream slows too. If your processor mutates events, that becomes part of runtime semantics. Good. Those are the tradeoffs practitioners need surfaced, not hidden.

This release also fits a broader industry shift. The agent market spent a long time pretending the key innovation was one more way to describe multiple agents talking to each other. That part has largely commoditized. The more valuable work now is in runtime middleware: approvals, resumability, event routing, state fidelity, and provider normalization. PydanticAI is not trying to win the loudest launch thread. It is trying to make these seams programmable without requiring users to fork the framework.

Provider quirks are still policy decisions

The GPT-5.5 thinking-setting update in PR #5196 looks smaller than the other features, but it belongs in the same story. The change updates model-profile detection so GPT-5.5 gets the same thinking-setting handling as GPT-5.4, while noting that gpt-5.5-pro keeps a more restricted medium, high, and xhigh pattern. This is a reminder that provider differences leak through every abstraction eventually. Mature frameworks do not pretend otherwise. They normalize where they can, document where they cannot, and make the mismatch explicit enough that application developers do not discover it at 2 a.m. in a broken workflow.

That is one reason PydanticAI remains interesting despite not having LangChain’s scale or OpenAI’s gravitational pull. It is opinionated in a builder-friendly way. Instead of burying runtime complexity under brand-heavy abstractions, it keeps turning that complexity into explicit capabilities, typed surfaces, and documented behavior. That makes the framework easier to reason about, especially for teams that care about correctness, inspection, and the ability to evolve systems without replacing half the stack.

There is also a competitive angle here. LangChain is still paying down runtime debt around tool outputs and streaming structure. OpenAI is thickening sessions and sandbox behavior while keeping the public API small. Microsoft keeps pushing deeper into hosted runtime, tracing, and A2A seams. PydanticAI is carving out a different lane: less “one platform to own everything,” more “a framework where the messy parts can be composed, tested, and understood.” For many teams, that is a better long-term proposition than another batteries-included framework that gradually becomes impossible to inspect.

For practitioners, the advice is straightforward. If your agent system includes approval-gated tools, external tool runners, custom event-stream consumers, or UI flows that depend on live runtime state, v1.87.0 is worth more than a casual skim. It may let you replace bespoke glue code with first-class middleware. And if you are choosing frameworks this year, start asking harder questions about event processing and deferred execution instead of just comparing tool counts and multi-agent demos. Those boring seams are where system quality actually lives.

PydanticAI’s release does not scream for attention. That is fine. The interesting story is that it keeps making the runtime more programmable in the exact places where real products get messy. In 2026, that is a better sign of framework maturity than another announcement about how many agents can chat with each other in a sandbox nobody has to maintain.

Sources: PydanticAI v1.87.0 release notes, PydanticAI overview documentation, PR #5142, PR #5141, PR #5196