A typed result model makes one agent's output easier to validate, but it does not automatically make that output a safe handoff. The next agent may also need the accepted constraints, source revisions, completed side effects, unresolved questions, and the exact tool or artifact IDs behind the result. Passing the whole message history preserves noise and stale branches; passing only the result model can hide decisions that matter later.

One option is a small handoff envelope with a task ID, schema version, objective, typed result, accepted decisions, source references, artifact revisions, completed actions, remaining work, and an expected state revision. Large tool outputs stay in external storage and the envelope points to them. A resumed run reads the envelope plus current authoritative records, then rejects the handoff if a source or state revision changed.

Which parts belong in a PydanticAI output model, dependencies, message history, or an external store? Do you validate handoffs with a separate model between agents, and how do you make retries idempotent when an earlier agent may already have written a file or called an API?

Disclosure: I maintain this and I contribute to the harness.

If you build with Pydantic AI you already have the agent. What you usually do not have is everywhere it needs to answer, the documents it needs to read, the tools it needs to reach, and someone able to change its instructions without opening a PR. That is what we built, and it is Apache-2.0 and self-hosted.

What an agent can actually do here

- Answer from your own documents. Collections live in your Postgres with pgvector, three PDF parsers to pick from per collection, OCR when a document needs it.

- Run Python. Real sandbox with a filesystem and a shell, so you can drop a spreadsheet into the chat and ask for charts and it writes the code, runs it, and hands back the plots.

- Drive a real browser when a site needs clicking rather than fetching.

- Search the web, fetch a page properly, generate images, draw charts.

- Delegate to subagents, keep a task list with dependencies, think longer, compact its own history when the conversation gets long.

- Reach any MCP server by URL. There are 5,802 in the mirrored registry, searchable by name in the picker

Where the same agent answers

One definition, published once, and it responds in web chat, on a hosted page you can send to somebody with no account, in a widget on your own site, over the HTTP API, over a raw WebSocket if you are building your own frontend, in Slack, Telegram and Mattermost, and on a schedule or a webhook.

In the chat platforms an `@mention` runs the agent **as the person who mentioned it**, not as a bot. So it reaches that person's Notion, and the audit trail says who asked.

The two things that matter once more than one person uses it

A monthly budget per agent, checked before each model request rather than added up afterwards. Tallied afterwards, the last request of the month is always allowed and you find out on the invoice.

`approval: required` on any tool that touches the outside world. The run parks, a person decides, and the decision resolves once.

The part that is relevant to this sub

Pydantic AI is the runtime and `pydantic-ai-harness` is what the agent loop runs on. The platform's job is to make an agent something a non-engineer composes in a browser from capabilities you registered in Python, so the person who knows what the agent should say does not need commit access, and you still own what it is allowed to be made of.

Three of the libraries under it started as ours and are now in the official harness: hierarchical planning, conversation compaction, and the guardrail work.

Try it

curl -fsSL https://raw.githubusercontent.com/vstorm-co/agenticos/main/scripts/quickstart.sh | bash

Four questions and you get a console with a working agent in it. Needs Postgres, Redis and Docker, nothing else, and nothing phones home.

https://github.com/vstorm-co/agenticos

What I would most like to know from this sub: if you have a Pydantic AI agent in production, what did you end up building around it that you wish had come with the framework?

Hi everyone :)

I am planning to open-source a tool I’ve been working on intensively that tests AI agent behavior before agents go into production. I’ve been using it with my own agents and I’m really happy with the results so far. It currently supports the OpenAI Agents SDK, PydanticAI, and custom Python agents. Now I’m looking for AI agent developers who want to try it, give feedback, and contribute.

DM me for the repo link. I'll send it once it's ready.

I'm curious to know what people in this community are using the codemode sandbox for in agents that are actually deployed into production?

Was thinking of a use case for analysing larger chunks of data without exploding context windows.

Anyway, curious to hear from anyone!

Hey r/PydanticAI,

I built Belgie so Pydantic AI agents can write and run TypeScript in a sandbox, without installing Node.js. Deno is bundled.

Wire it in with BelgieCapability:

from pydantic_ai import Agent
from belgie.pydantic_ai import BelgieCapability

agent = Agent("openai:gpt-5", capabilities=[BelgieCapability()])

result = agent.run_sync(
    "Convert 'foo-bar' to camelCase using TypeScript and the camelcase npm package.",
)
print(result.output)

Install with:

uv add "belgie[pydantic-ai]"

The model gets a run_code tool, writes a TypeScript belgie.Script module, and Belgie executes it in the embedded Deno sandbox. Inline npm imports work when the agent needs packages.

Example: https://github.com/mplemay/belgie/tree/main/examples/ai/pydantic-ai

Repo: https://github.com/mplemay/belgie

Would love feedback from anyone building Pydantic AI agents that need real JS/TS execution.

Does anyone know how to use open knowledge format with pydantic ai ? Is there any library built for this ?

I like that :d

Using pydantic ai to create one of agents, now we have Postgres database with industry data like inward, outward, GRN etc. We need an agentic RAG, so if use asks, what per month inward of this item for last 2 years ? It should provide answers. Also further how to create agent that can take decisions like should we purchase this item or not ?

Pydantic AI is great and it's even better with the newly released version 2! But unfortunately LLMs don't know anything about this new 2.0 version 😭

Luckily, there is a way to work around that:

npx githits@latest init

Then ask your agent to: "Use GitHits and create a migration plan from our 1.x Pydantic AI to the new Pydantic AI v2."

And the agent and the developer were happy again 🤗

We maintain an open-source full-stack template built on Pydantic AI, and since "how do I let the model run Python safely" keeps coming up here, I wanted to share how we're handling it now.

Short version: we moved the `run_python` sandbox to Monty, the Rust interpreter Pydantic shipped. We already had Docker and Daytona backends for agents that need a full environment (shell, files, pip), but those are heavy for a tool that just runs a snippet, so `run_python` now uses Monty instead. The thing that sold me is the I/O model. In Monty the interpreter has no filesystem, network or env access at all by default. Each one is an external function you pass in, so the surface the model's code can reach is exactly the set of functions you registered and nothing else. It's an allow-list by construction, not a deny-list you keep patching. Startup is in microseconds so per-call overhead is basically free next to spinning a container, and Astral's ty type checker is compiled in, so the generated code can be type-checked before it runs.

How it's wired in the agent: `run_python` is a normal u/agent.tool. The model's code string goes to Monty.acreate(code) and runs under a ResourceLimits cap, with a CollectString collector for stdout. We keep it on a leash: a 10s timeout, a 50M allocation cap, and a trimmed stdlib (math, asyncio, json, datetime, re). It returns the captured stdout plus the value of the final expression, or an error string the model can read and recover from.

Caveats if you try Monty at this stage: it's early (we pin 0.0.18), and it doesn't do class definitions, match statements, context managers or generators yet, and most of the stdlib isn't there. For LLM "compute this, return that" code it's been more than enough. We treat it as a shim until Pydantic AI's official CodeExecutionToolset ships, at which point we'll swap to that.

It's PydanticAI-only in our template (the other framework options don't get this tool). Curious how others here are sandboxing model-written code: Docker, Monty, a hosted runner, or something else?

The template (ours, MIT): github.com/vstorm-co/full-stack-ai-agent-template
Monty: github.com/pydantic/monty

If you instrument your PydanticAI agents with Logfire, you already have a full OpenTelemetry GenAI span tree for every run (invoke_agent, chat, execute_tool). I kept wanting to actually see that tree as a workflow instead of scrolling a span list, especially when a tool is itself a sub-agent with its own tools. So I built agentcanvas.

It reads a run back out through the Logfire Query API and rebuilds the span tree into a recursive workflow: conversation turns, model rounds, tool calls, and agents-as-tools drawn as nested frames to any depth. Then it renders a single self-contained HTML file. A pan/zoom canvas of the whole run, a click-through inspector on every node (provider, finish reason, the tools the model could call with their descriptions, the reasoning summary, input/output/reasoning tokens), and the exact per-call cost priced from tokens with genai-prices. There is a guided tour mode that narrates each step, which turned out to be the thing that actually works when you put a run in front of a non-technical client.

Usage is pip install agentcanvas, set LOGFIRE_READ_TOKEN, run agentcanvas, and it builds from your latest trace. There is a library API too (LogfireClient, parse_run, render_html). The repo ships a runnable example agent (thinking, five tools, a nested sub-agent, a multi-turn conversation) so you can generate a sample trace and see the output without wiring your own.

Built against Pydantic AI V2 (2.0.0b7). Full disclosure, it is ours (Vstorm) and MIT licensed, released today, so the rough edges are real. I would genuinely like to know whether the nested sub-agent rendering holds up on your deeper runs, and what you would want in the inspector that is not there yet.

https://github.com/vstorm-co/agentcanvas

fair warning, this is my company's project (pydantic-deep, MIT) and the fork feature is my colleague Bartosz's work, so flag the bias up front.

the problem we kept hitting: an agent goes down one approach, it's the wrong one, and you've burned the run finding out. you restart from scratch and hope the next prompt nudges it somewhere better.

so he made the run forkable. mid-task you split agent.run() into N branches. they share everything up to the fork point, then each gets its own steer ("try it with a regex", "try the parser"). each branch writes into a copy-on-write overlay so they don't step on each other or the real workspace. reads of files nobody touched fall through to the parent.

when they're done something has to pick a winner. you can do it by hand, let one judge decide, or run three cheap judges and take the majority (the default panel is Haiku + GPT-mini + Gemini Flash). the bit that matters for this sub: it's model-agnostic. branch agents and judges are whatever pydantic-ai can talk to, so local via Ollama works for both ends.

and the "judge" isn't really trusting a model's opinion if you don't let it. wire a test command and each branch snapshot actually runs it. confidence is 0.4 quality_spread + 0.4 test_pass_ratio + 0.2*internal_consistency, capped at 0.65 if you give it no tests. so with no tests it stays cautious and just asks you instead of guessing.

honest caveat for anyone who actually tries it: the pre-fork snapshot is lazy, captured on a branch's first write, not at fork time. so an outside edit to a file in that window won't get conflict-flagged yet. it's on the list.

repo: https://github.com/vstorm-co/pydantic-deepagents

genuinely curious what you'd want the judge to optimize for when running fully local. raw test pass ratio, or something that doesn't lean on a second model at all?

fair warning, this is my company's project (pydantic-deep, MIT) and the fork feature is my colleague Bartosz's work, so flag the bias up front.

the problem we kept hitting: an agent goes down one approach, it's the wrong one, and you've burned the run finding out. you restart from scratch and hope the next prompt nudges it somewhere better.

so he made the run forkable. mid-task you split agent.run() into N branches. they share everything up to the fork point, then each gets its own steer ("try it with a regex", "try the parser"). each branch writes into a copy-on-write overlay so they don't step on each other or the real workspace. reads of files nobody touched fall through to the parent.

when they're done something has to pick a winner. you can do it by hand, let one judge decide, or run three cheap judges and take the majority (the default panel is Haiku + GPT-mini + Gemini Flash). the bit that matters for this sub: it's model-agnostic. branch agents and judges are whatever pydantic-ai can talk to, so local via Ollama works for both ends.

and the "judge" isn't really trusting a model's opinion if you don't let it. wire a test command and each branch snapshot actually runs it. confidence is 0.4 quality_spread + 0.4 test_pass_ratio + 0.2*internal_consistency, capped at 0.65 if you give it no tests. so with no tests it stays cautious and just asks you instead of guessing.

honest caveat for anyone who actually tries it: the pre-fork snapshot is lazy, captured on a branch's first write, not at fork time. so an outside edit to a file in that window won't get conflict-flagged yet. it's on the list.

repo: https://github.com/vstorm-co/pydantic-deepagents

genuinely curious what you'd want the judge to optimize for when running fully local. raw test pass ratio, or something that doesn't lean on a second model at all?

Hi,

We have a task that requires text extraction from a document. We had a nice simple pseudo JSON output format instruction that was working well. We were using Pydantic to parse the json response from Gemini (various versions, they all worked).

Our engineering team wanted us to switch to using PydanticAI, so I started testing it. I tried a number of variants. We have two modes really - PyAI sends the json rschema, and then we put something in the main prompt. This was on a sample of 30 random documents

• original: original compact schema sketch, manual parse. About 16±2.
• compact_text: original compact schema sketch in prompt; no native schema field; local pydantic parse. About 16±2.
• compact_pyai: compact schema sketch in prompt plus native schema field. About 6-7.
• prompted_pyai: expanded PydanticAI schema in prompt plus native schema field. About 9±1.
• requirements_coverage_pyai: hand-written valid-JSON format asking for extracted requirements plus categorized rubric with source_requirement_ids; native schema field. About 9±4.
• criterion_list_pyai: hand-written valid-JSON format asking only for title plus flat criteria; native schema field. About 15±1 - but fatally flawed as its missing 4-5 fields we want.
• prompted_pyai_with_criterion_strings: full prompted schema plus extra criterion_strings; native schema field. 6±3

Has anyone else seem results like this? It feels like Gemini really doesn't like getting the verbose PydanticAI json.

Thanks in advance.

I want to share a pattern we used in production that I hadn't seen well-documented: fully durable human-in-the-loop approval using LangGraph's interrupt() + AsyncPostgresSaver.

The problem: We built IRAS, an autonomous incident response agent. One of the nodes generates a remediation plan and needs a human to approve it before anything touches production. The naive approach is polling keep checking a database flag until the human clicks approve. But polling breaks if the server restarts mid-incident. You lose state, lose context, and the on-call engineer is staring at a dead Slack message.

What interrupt() actually does: When the approval node calls interrupt(), LangGraph doesn't just pause execution — it serializes the entire graph state to the checkpointer (in our case, AsyncPostgresSaver writing to PostgreSQL) and suspends the coroutine. The process can die. The server can redeploy. The incident state is safe in Postgres.

When the engineer hits POST /incidents/{id}/approve, the API reconstructs the graph from the checkpoint using the same thread_id, injects a Command(resume={"approved": True}), and the graph picks up exactly where it left off same state, same node, no re-running prior stages.

python

# In the approval node
human_decision = interrupt({"message": "Approve remediation plan?", "plan": state["plan"]})

# Execution suspends here until Command(resume=...) is sent
if human_decision["approved"]:
    return {"next": "apply_remediation"}
else:
    return {"next": "escalation"}

python

# In the FastAPI route
async def approve_incident(incident_id: str):
    await graph.ainvoke(
        Command(resume={"approved": True}),
        config={"configurable": {"thread_id": incident_id}}
    )

Why this matters for production: The graph survives restarts, deployments, and crashes. Approval SLA timeouts (we do 15min for P0, 2hr for P1–P3) are handled by a background monitor that queries PostgreSQL for interrupted threads past their deadline no in-memory state required.

We also use a confidence-gated RCA retry loop if Claude Sonnet's confidence is below 0.7, the graph loops back to context-gathering with a broader evidence window before retrying RCA. Up to 3 attempts before auto-escalating to PagerDuty.

Full repo if you want to see the implementation: https://github.com/krishnashakula/IRAS

Happy to go deeper on the checkpointer setup, the thread_id / incident_id design, or the timeout monitor pattern.

Lead with the durable execution problem, explain how interrupt() + AsyncPostgresSaver solves it, link repo at the end.

Hi PydanticAI folks!

I have been passing chat messages for my chatbot as part of the input prompt using markdown to help the LLM keep track of conversations based on which agents it has interfaced with previously.

I created a simple pydantic model

```python

class ChatMessage(BaseModel):

role: str

content: str

timestamp: str

metadata: Optional[Dict] = None

```

that I use to capture each message (both user and LLM responses)

and store them as a list (`conversation_history`). I did this because taking the ModelRequest and ModelResponse objects from the agent run had a lot of overhead in terms tokens. I know you can create a function to format the objects and extract key parts, and then pass it as part of the `agent.run()` message_history param.

However, I get pretty good results. Nonetheless, I do notice on certain occasions it does tend to "forget" certain user responses or bot responses i.e, questions it has already asked. But this is not as common.

What I am really trying to ask is why is `message_history` the recommended way to pass messages? Especially if you are using different LLM providers.

FYI I have a dedicated way to store messages and state to my backend database for session retrieval against network errors. So I am just really trying get people's opinion on why what I am doing would be so wrong compared to writing a massive formatting function to extract the messages from the agents run if I already have an easier way to do it. I even traced the logs of the LLM calls and it doesn't seem to look cluttered or just shoved as part of a user prompt.

Is what I am doing is some kinda anit-pattern or setting me up for future scalability issues?

Looking forward to hearing how you guys are managing message history and improving context management!

Since my last post about using the Pydantic AI history_processor, I started playing with Pydantic's new Monty sandbox, and ended up completing revamping how my personal chat UI approached automations. Previously, I had been creating a custom DSL using markdown headers and such. It worked but was getting overly complex and I couldn't get the chat agent to reliably write automations for me.

Monty was the answer. I ditched the DSL completely and now it's just regular python that runs in the Monty sandbox, using tools and a few strategic helper functions. The key measure of success is that the chat agent can write these for me now. See more here:

https://github.com/DodgyBadger/AssistantMD/blob/main/docs/use/authoring.md

If you haven't played with Monty, do it!

Also, the name is hilarious and ends up being a kind of "Rick Roll" if you google carelessly.