Burr vs Pydantic-AI vs Postgres voor agent-orchestratie

Een healthtech met 24 mensen in Utrecht draait een machtigings-agent tegen de portals van drie Nederlandse zorgverzekeraars en de HiX van één ziekenhuis. Vorige week diende de agent dezelfde machtigingsaanvraag tweemaal binnen een uur in. De trace was een FastAPI-handler van 600 regels met een status-enum en vier except Exception-blokken. Niemand kon zeggen welke retry het duplicaat opleverde. De CTO gaf zichzelf 48 uur om een echte orchestrator te kiezen.

Ze hield er drie over: Burr, een Pydantic-AI graph, en een zelfgebouwde Postgres state machine die ze in een week af kon hebben. Wij hebben voor klanten in vergelijkbare situaties agents op alle drie gebouwd. Hier is hoe de vergelijking er echt uitziet als de eisen debugbaarheid, schema-eigenaarschap en wat een IT-beheerder van een ziekenhuis tekent zijn.

De shortlist, kort

Burr, van DAGWorks, modelleert je agent als een state machine van acties en transitions, slaat elke stap op in een backend naar keuze (SQLite, Postgres, custom), en levert een lokale UI die je bij elke stap van elke run de state laat zien.

Pydantic-AI graph (het pydantic-graph package) zit in het pydantic-ai project. Nodes zijn Pydantic dataclasses met een async run-methode die de volgende node teruggeeft. State is een getypeerd Pydantic-model. Persistence is opt-in via een BaseStatePersistence-protocol dat je zelf implementeert.

Zelfgebouwde Postgres state machine is wat de meesten van ons de eerste keer schrijven. Een jobs-tabel, een status-enum, een job_events append-log, een worker-loop met SELECT ... FOR UPDATE SKIP LOCKED. Geen framework, volledige controle, elke regel jouw probleem als het om 02:00 stuk gaat.

Replay-from-step in de praktijk

"Replay from step" betekent: de agent faalde bij stap 7 van 12, je hebt de bug gefixt, je wil opnieuw beginnen vanaf stap 7 met dezelfde state als toen, niet vanaf stap 1. Voor een machtigingsworkflow met een verpleegkundige-review en een arts-akkoord is replayen vanaf stap 1 niet gratis. Je verstuurt opnieuw e-mails, pingt opnieuw de portal van de verzekeraar, vraagt de arts opnieuw een diagnose te bevestigen die ze gisteren al bevestigde.

Burr wint dit met overmacht. Elke transition wordt opgeslagen met de input van de actie en de resulterende state, gekoppeld aan een app_id en een oplopende sequence_id. Een vastgelopen run hervatten is één builder-call:

from burr.core import ApplicationBuilder
from burr.tracking import LocalTrackingClient

app = (
    ApplicationBuilder()
    .with_actions(check_dekking, verify_diagnose, attach_onderbouwing, submit)
    .with_transitions(...)
    .initialize_from(
        LocalTrackingClient(project="prior-auth"),
        resume_at_next_action=True,
        default_state={},
        default_entrypoint="check_dekking",
    )
    .with_identifiers(app_id="aanvr-2026-06-11-7421")
    .build()
)

De Burr UI laat een ontwikkelaar in aanvr-2026-06-11-7421 klikken, de state-diff bij elke stap zien en vanaf elke node replayen. Voor een team dat de hele dag machtigingen doet, is dat het verschil tussen een rustige post-mortem en een vrijdagavond opnieuw bouwen.

Pydantic-AI graph ondersteunt resume ook, maar het persistence-verhaal is jonger. Je implementeert BaseStatePersistence en bepaalt wat je opslaat. Er is geen meegeleverde UI; die bouw je zelf of je staart naar JSONB in een psql-venster. De graph zelf is netjes, de typing is echt goed, maar de operationele laag is van jou.

De zelfgebouwde Postgres-versie is precies zo goed als jij hem maakt. Het patroon dat werkt: elke actie is een rij in job_events met (job_id, step_id, input_state, output_state, attempt). Resume = pak de laatste geslaagde stap, zet output_state terug in de worker, draai step_id + 1. Dat houdt het voor één workflow. Voor vijf workflows die uit elkaar lopen onderhoud je nu je eigen mini-Burr.

Schema-migraties en wie de pager draagt

Elke optie heeft tabellen. De vraag is welke tabellen jouw team bezit en welke het framework bezit.

Burr's persistence-backend maakt en migreert zijn eigen tabellen. De PostgreSQLPersister schrijft naar een schema dat jij aanwijst, en zijn migraties zitten versioned binnen de Burr-release. Jouw Alembic weet er niets van en hoeft dat ook niet. De prijs: als Burr zijn schema upgradet, upgrade je Burr op een rustige middag, niet tijdens een storing.

Pydantic-AI graph werkt andersom. Persistence is jouw probleem. Jij schrijft de tabel, jij schrijft de Alembic-revisie, jij schrijft de JSON-serializer voor welke versie van het state-model nu actief is. Het voordeel is dat je DBA de tabel al begrijpt. De prijs is dat niemand buiten je team het ooit getest heeft.

De zelfgebouwde versie is uiteraard helemaal van jou. Het schema is klein (twee tabellen, één enum) en makkelijk te migreren. De val zit in workflow nummer twee. Machtigingen zijn één vorm, maar dezelfde agent gaat uiteindelijk ook nazorg-declaraties, declaratiecorrecties en patiëntportaal-triage doen. Elk wil iets andere state. Bij de derde workflow heb je of een generieke state-kolom gebouwd (en de typing verloren) of drie bijna-identieke tabellen (en je weekenden verloren).

Wat de IT-beheerder van het ziekenhuis daadwerkelijk goedkeurt

Dit is het deel dat de framework-vergelijkingen nooit raken, en het is het deel dat de deal kapot maakt. De IT-afdeling van een Nederlands ziekenhuis draait NEN 7510 en een inkoopproces dat elk Python-package op de requirements-file ziet als een supply-chain-risico. Drie dingen die ze vragen.

Waar leeft de state?

Alle drie de opties kunnen het in een Postgres zetten die ze al draaien. Burr en de zelfgebouwde versie doen dat standaard. Pydantic-AI graph doet het zodra je de persister bedraadt. Geen van drieën vereist een externe SaaS, en alle drie kunnen binnen de ziekenhuis-VPC blijven. Op dit punt staat het over de hele linie groen.

Hoeveel transitive dependencies?

De zelfgebouwde versie is het kleinst: psycopg, je worker, klaar. Pydantic-AI graph trekt pydantic-ai mee, dat een niet-triviale maar goed onderhouden boom is. Burr brengt zijn eigen dependencies plus een optionele tracking-server mee die je ofwel deployt ofwel uitzet. Voor een beheerder die een dependency-review doet voor NEN 7510-akkoord is 'kleiner is sneller goedgekeurd' geen abstractie.

Wat gebeurt er als de agent zich misdraagt?

De IT-beheerder heeft dezelfde verhalen gelezen als jij over agents die destructieve dingen doen met bestandssystemen die ze nooit hadden mogen aanraken. Ze willen weten: is er een kill switch, is er een rate limit op tool-calls, is elke actie te auditen. Burr geeft je een transition-graph die de beheerder in de UI kan lezen. Pydantic-AI geeft je getypte nodes. De zelfgebouwde versie geeft je wat je zelf hebt geschreven. Geen van de drie stopt op zichzelf een slechte actie. Alle drie maken die wel te auditen als je het zo opzet.

De keuze

Voor het Utrechtse bedrijf concreet is het antwoord Burr, met één voorbehoud. Alleen al de replay-UI verdient de upgrade-kosten terug. De per-stap opgeslagen state lost het dubbele-machtiging-incident op waar de CTO naar staart. De Postgres-backend houdt de IT-beheerder rustig. En het actie/transition-model is netjes te leggen op hoe een Nederlandse machtigingsflow daadwerkelijk loopt: check dekking, verifieer diagnose, koppel onderbouwing, dien in, parse respons, escaleer-bij-AGB-issue.

Het voorbehoud: zet de Burr tracking-UI niet zomaar op het ziekenhuisnetwerk tenzij jij de auth ervoor regelt. Draai 'm op de developer-laptop tegen een read replica, of zet 'm achter een SSO-proxy. De tracking-data ligt dicht tegen patiënten aan.

De Pydantic-AI graph zou onze keuze zijn als het team twee senior engineers had die graag infrastructuur schrijven en de workflow waarschijnlijk solo zou blijven. De types zijn uitstekend en de code leest goed. Op operability verliest hij vandaag.

De zelfgebouwde versie zou onze keuze zijn als het team drie mensen was en de workflow strikt lineair zonder human-in-the-loop. Dat is dit team niet.

Wat je morgen kunt doen

Zit je in dezelfde beslissing, begin dan met je workflow op een whiteboard als state machine te tekenen. Tel de states. Tel de transitions. Komen er minder dan acht states uit en één workflow, dan is zelfgebouwd prima. Komen er meer uit, of weet je nu al dat workflow twee eraan komt, installeer Burr in een branch en port één pad. Binnen een dag weet je of de abstractie past.

Toen wij een claims-triage-agent bouwden voor een klant in het Nederlandse zorg-domein, beet ons precies dit: we kozen de lichtste abstractie, leverden op, en bouwden de persistence-laag zes weken later opnieuw toen de tweede workflow erbij kwam. Uiteindelijk porteerden we naar een expliciete state machine, en sindsdien is dat onze default voor elke AI-agent.

Het kleinste wat je vandaag kunt doen: open je huidige agent-code en tel de except Exception-blokken. Zijn het er meer dan twee, dan heb je geen orchestrator. Dan heb je een retry-loop met een hoedje op.