Pydantic

As AI gets more powerful, the limit on the tasks it can perform increases. What happens when something goes wrong? The time taken to recover and the value of the lost work also increases. Samuel Colvin will be giving a keynote at PyCon Italia to talk about how durable execution makes it possible to break from failure constraints. You’ll leave the room understanding when durable execution matters, how to implement it, and what production-ready AI architecture looks like. Join Samuel and the Pydantic team at PyCon Italia on Saturday, May 30th, at 9:15 am (local time). If you're a Monty-fan, get ready for an announcement during the keynote.

The first SLO alert most teams write looks like this: "If the 5xx rate is above 0.1% for 5 minutes, page someone." It works for the dramatic case where a service is hard down. It fails everywhere else: • A ten-request blip in a quiet minute pages on-call at 3am for a problem that's already gone. • A 0.05% failure rate sustained for two weeks never trips the threshold — and silently consumes your entire monthly error budget. The fix, from the Google SRE workbook, is to alert on the rate at which you're burning the budget, and to require both a long and a short window to be above threshold before firing. Long window = the issue is real. Short window = it's still happening right now. Nicola Martino's new post walks through the whole loop in Pydantic Logfire: picking an SLI, building the dashboard, configuring multi-window multi-burn-rate alerts, and backtesting them against past incidents before they hit PagerDuty. Burn rate ends up being a single SQL expression that drives both the dashboard panels and the alert queries. Link to post in comments.

On Friday May 29th, Marcelo Trylesinski, maintainer of Starlette & Uvicorn will be speaking about what he learned maintaining the MCP Python SDK at PyCon Italia at the 15:45pm slot (local time). He will cover how to design scalable tool boundaries, maintainability, and testing strategies. Learn to avoid anti-patterns and prepare for the v2 SDK migration. Join and leave the room with a clear design framework for your server.

For a lot of teams, a shared SaaS infrastructure isn't an option. But "run it yourself" is a real operational cost. Kubernetes, Postgres, object storage, upgrades, incident response. Most teams would rather not staff that just to run observability. So we built a third path. Logfire Enterprise Dedicated is fully managed, single-tenant infrastructure: a dedicated VPC, managed Kubernetes cluster, managed Postgres, and object storage, in the GCP region you choose. CMEK, Private Service Connect, and IP allowlisting available for teams that need them. Same Logfire product. We handle the operations. The infrastructure belongs entirely to your deployment. It sits between our Enterprise Cloud plan (shared, fully managed, fast to deploy) and Enterprise Self-Hosted (you run everything). Dedicated is for teams where single-tenant isolation is a hard requirement, not a preference. Our early adopters are already running on it. Now broadly available. Full write-up link in the comments.

So you've built an AI agent. Now what? We're hosting an evening of talks for engineers and AI practitioners who are past the demo stage and into the part where things break in production. Speakers: • Spencer Hong, Founding Researcher at The General Intelligence Company of New York • Matthew Kim, databaseologist at Pydantic Logfire, on best practices for SQL queries against telemetry data Plus a feature launch from the Pydantic team. Real code, real trade-offs, real conversations with the people building the tools you use. Thursday, June 4, 6–8pm, NYC. Part of #NYTechWeek.

No, you cannot 'eval' your way into fairness. That's 🧐 Laura Summers talk at PyCon Italia this Saturday, May 30 at 15:35 - 16:20 (local Italy time). Laura is lead design engineer of our observability platform Pydantic Logfire. In this talk she will explain that fairness is felt, not calculated through classic optimisation techniques.This is a talk for people who suspect we can’t optimise our way to human dignity. Join Laura and the other folks from the Pydantic crew at PyCon Italia 2026.

A Pydantic AI agent on your laptop is easy to reason about. Production is less forgiving: a pod dies, a tool times out, a human's offline for approval. New guest post from Hamza Tahir on Kitaru, a new runtime layer underneath Pydantic AI 👇

It's 29℃ now in Utrecht. Finally, Summer weather is here! Unfortunately (or not), I'm enjoying my weekend reviewing security advisories, as it has been since the beginning of the AI boom. I just want to say that your stack is safe, and I'm doing my best to review security advisories as soon as possible. ❤️ I love what I do, and I'm not going anywhere. But if you are able to, please consider asking to your boss or decision-maker whether your company has a strategy for funding the open source it depends on. Recently, I lost half of my sponsorship amount (I only had 2 companies with meaningful monthly sponsorship, and now it's just FastAPI). So if your companies can, this is my Sponsorship page: https://lnkd.in/exhMuZFb. Disclaimer: this post was written by a human (I know, I know, rare stuff).

Hey you. Yes, you - the dev with the .env file full of API keys sat on your laptop right now. Pydantic's Jiří Kunčar, just wrote about an alternative way, pointing out that AI coding agents have turned developer laptops into "the most exposed credential stores in the company." He's not wrong. LiteLLM on PyPI and Axios on npm both got popped in March with postinstall credential stealers that read your env vars, dotfiles, and cloud creds the moment you install. node-ipc joined the list two weeks ago. The fix Pydantic is proposing (full post link in the comments): `logfire gateway launch`: real provider keys live server-side. Your laptop only ever holds a short-lived OAuth token, scoped to one session, gone when you close the terminal. Spend caps enforced before any request reaches a provider.

Pydantic AI 𝘃𝟮 𝗯𝗲𝘁𝗮 𝗶𝘀 𝗵𝗲𝗿𝗲. v2 is built harness-first, so much of what you configure on an agent now flows through one primitive, Capabilities. Extending an agent becomes a single composable concept instead of configuration spread across your codebase. What's new: - Capabilities as the core unit: One capability bundles an agent's tools, lifecycle hooks, instructions, and model settings, so a whole extension (memory, guardrail, coding toolkit) plugs into every layer at once. - A lean core with an ecosystem: Some capabilities ship with Pydantic AI, more from the 1st party Pydantic AI Harness, and others are 3rd party or your own. - Configuration in one place: Settings that used to be scattered across `Agent` arguments now live on the primitive. - More visibility: Updated instrumentation with aggregated token-usage attributes, plus message capture from interrupted runs for easier debugging. Release notes in comments.