Pydantic

The refund agent said yes. The customer didn't qualify. Nothing errored, and the automated judge scored the run "helpful and polite". Because it was. Fluent, courteous, and wrong. The only person who can catch that is someone who knows your business. Until now, the way they told you was a Slack message that scrolled away by lunch. Annotations in Pydantic Logfire let them tell the system instead, on the run itself: • A pass / neutral / fail verdict, a failure category, and the corrected answer. That last field turns a bad run into a training example. • A keyboard-driven review panel: 1, 2, 3 for the verdict, cmd-enter to save and jump to the next run. Grade fifty runs in the time a review meeting takes to schedule. • Verdicts outlive the trace. When the run ages out of retention, the judgment about it doesn't. • Export to JSON or CSV and feed them straight back into your evals. Evals give you coverage; annotations give you ground truth. Every fail with an expected output is a case for your eval set, built from real failures on real inputs instead of the synthetic cases you'd have guessed at. And every time a human disagrees with the judge, you've found a bug in the judge. Priced at $0.00 per thousand scores, because rigor shouldn't be the thing you ration. Day four of Agents Week: link in bio.

We're continuing to hire across departments. Recently added roles: 👉️ Head of Growth 👉️ Growth/GTM Engineer 👉️ Growth Data Analyst 👉️ Developer Success Engineer 👉️ Marketing Associate 👉️ Content Engineer 👉️ Security & Compliance Lead Plus a handful of additional engineering roles, all listed here: pydantic.io/BfzID

Part of Autonomy AI's backlog is filed by agents reading production telemetry through the Pydantic Logfire MCP. AutonomyAI builds an agentic operating system that lets PMs and designers ship merge-ready code into existing codebases, and its production traces land in Logfire. Their own R&D agents review changes after they ship, and in five weeks they opened tickets on 12 that passed CI, merged clean, and never fired. Full story from Tammuz Dubnov and Alyosha Makarov at AutonomyAI linked in the comments below. 👇️

"You're absolutely right I read the keys out of your .env file!"

Your coding agent found your AWS keys in your .env, read them, and put them in a prompt. You're welcome. Who needs enemies when you have friends like these? An agent sees whatever the user typed, whatever the tool returned, whatever retrieval dragged in. Some of it is secrets, some of it is somebody else's PII, and every prompt is an outbound transfer to a third party. You don't fix that service by service, one regex at a time. You fix it at the one place every prompt and completion already passes through: the gateway. The Pydantic Logfire AI Gateway gives you: • One key for every provider: OpenAI, Anthropic, Google, Bedrock, Groq, Mistral, Azure and more. Managed and prepaid, or bring your own keys. • Data loss prevention: scan prompts and completions for secrets and PII, then observe, flag, redact, or block. • Priority failover and weighted load balancing, no code changes. • Hard spending caps that block the request when the budget is spent, not alert you after it's gone. And because the gateway and the observability are the same product, the redaction that fired and the failover that saved you are spans on the same trace as the rest of your agent. One control point for the whole fleet, and the audit trail comes free. Day three of Agents Week. One key in, no keys out.

Pydantic Logfire is now available on Stripe Projects. 🚀 Now you can provision Logfire straight from the command line when you set up a project, in your own account, with credentials written into your environment. When shipping AI features, observability is how you find out whether they work, which is why it should be there from the first run.

We're building a unified interface to sandboxing platforms in Logfire, even better - it's powered by monty's wire protocol so you can do useful and safe things easily. But we need design partners, please get in touch if you want to join the closed beta! 𝚊𝚜𝚢𝚗𝚌 𝚠𝚒𝚝𝚑 𝚕𝚘𝚐𝚏𝚒𝚛𝚎.𝚜𝚊𝚗𝚍𝚋𝚘𝚡(...) 𝚊𝚜 𝚛𝚎𝚙𝚕: 𝚊𝚠𝚊𝚒𝚝 𝚛𝚎𝚙𝚕.𝚏𝚎𝚎𝚍_𝚛𝚞𝚗('𝚙𝚛𝚒𝚗𝚝("𝚃𝚑𝚎 𝙵𝚞𝚕𝚕 𝙼𝚘𝚗𝚝𝚢")') https://lnkd.in/erJYtabH

The average run is lying to you. Your support agent fires 3 tools on a normal run. Your dashboard shows an average of 3.1 tools per run. Everything looks healthy. Then your monthly bill arrives higher than expected. You dig and find it: somewhere in the last ten thousand runs, one request hit a retry loop and fired 40 tools before giving up. It cost $12. It didn't error, so nothing paged you, and the average absorbed it without a ripple. This is why we built two new views in Pydantic Logfire for the agent era: - The Agents view: an inventory of every agent shipping traces to your project, with avg and p90 charts. The average is the story you want to believe. The p90 is the one costing you money. - The LLMs view: per-provider model inventory with latency, throughput, and cost (priced from open-source data you can audit). See regressions before they hit a war room. Both work with any framework that speaks OpenTelemetry: Pydantic AI, LangGraph, OpenAI SDK, Vercel AI SDK. All normalized into the same views on the same traces. No new instrumentation needed. Everything populates from the `gen_ai.*` spans your agents already emit. Ship rough. Read what comes back. Change it at the scale a herd demands. This is part 2 of Agents Week by Bill Easton.

A good harness arms a single run. A loop of agents is what you build when one run isn't enough. Give it a goal instead of a plan, and it works out the rest. It delegates to sub-agents, writes its own coordination as a program, and when it hits a task it has no tool for, it writes the tool and has it ready on the next run. It also outlives the run. It goes idle, wakes on a closed PR or a failed CI job, and resumes where it left off. The unit that improves is the loop, not the turn. Read part two of three on where harnesses are heading. David S. on sub-agents, dynamic workflows, and agents that build their own tools. Link in comments.👇️

The Pydantic team is heading to EuroPython 2026 🐍 🧐 Laura Summers and Marcelo Trylesinski are giving talks. Jiri Kuncar and Laís Carvalho will be roaming the halls with stickers (supply is generous, ask away). EuroPython is the largest Python community conference in Europe, and we're glad to be part of the programme. If you use Pydantic, Pydantic AI AI, Logfire, Pydantic Evals, Monty, HTTPX2, or anything else we maintain, come say hi. We'd love to hear what you're building. Feedback, feature requests, and mild complaints all welcome. See you there!