V2: 7 AI-agents handelen een vergunning af — wat de PoC leerde

In de eerste blog (9 mei 2026) beschreven we een plan voor 8 agents. Een week later draait er een werkende PoC op vv.lostlands.nl. Tijd voor een update: wat werkt, wat is anders dan beschreven, en wat vond de Bbl-toetsing agent in een nieuwbouw-aanvraag.

Wat klopt van de eerste blog, wat is anders

Waarom geen centrale regisseur-agent?

In de eerste blog beschreven we een centrale "regisseur" Hermes-agent die de andere agents zou aansturen. In de PoC zit die orchestratie nu in de webapp — pragmatischer en transparanter:

• De stappen zijn grotendeels deterministisch (Intake → RO → Beschikking → Publicatie). Daar heeft een LLM niets te beslissen — een FastAPI route doet hetzelfde voor minder geld en tijd.
• Auto-triggers zitten daar waar logisch (welstand-advies opgehaald → automatisch Beschikking-agent starten). Geen extra LLM-laag nodig.
• Voorspelbaar en debugbaar: je weet welke endpoint welke agent triggert. Een autonome regisseur introduceert een extra "wat besloot hij nu eigenlijk"-laag.
• Kostenefficiënt: een centrale regisseur die elke beslissing maakt is een 8e LLM-call per zaak voor weinig toegevoegde waarde.

Een echte regisseur-agent is wel zinvol wanneer het proces écht dynamisch is (bv. "agent kiest zelf welke tools nodig zijn voor deze unieke aanvraag"). Voor de gestandaardiseerde Omgevingswet-flow is een orchestratie-laag in code beter.

De architectuur klopt. De getallen kloppen ongeveer. De technologie-keuzes zijn tijdelijk anders omdat we nog geen RTX 5090 in huis hebben — Claude Sonnet 4-6 direct via Anthropic doet het werk dat Gemma 4 lokaal zou doen. Functioneel identiek, kostentechnisch nog cloud-afhankelijk.

De Bbl-toetsing — wat een agent in 3 minuten vond

Het meest interessante stuk: de BblToetsingAgent die met Claude Sonnet 4-6 een volledige aanvraag voor een nieuwbouwwoning ging toetsen. De zaak (geanonimiseerd): VTH-2026-H**** — een nieuwbouwwoning op een hoek-kavel in een Twentse gemeente.

De aanvraag bestond uit 12 bestanden: bouwtekeningen v1, bouwtekeningen v2 (aanvulling), constructieberekening, BENG-berekening (UNIEC3), Bouwbesluit-berekening (BBSL), geotechnisch onderzoek, energielabel, geluidsberekening, etc.

De behandelende gemeente had na een eerste beoordeling de aanvrager geschreven (geanonimiseerde mail uit een dossier):

De aanvullingen zijn bekeken en niet alle punten zijn voldoende.

Het gaat om het volgende:

• Achtererfgebied is niet kloppend. Het is een woning op de hoek waardoor de zijkant niet mee te rekenen is als achtererfgebied.
• Locatie van de warmtepomp op de tekening is niet terug te vinden — vanuit de geluidsberekening lijkt deze vrij te komen te staan?

— aanvulverzoek van de behandelende gemeente

Wat de Bbl-agent vond (3 minuten, 71 stappen, Claude Sonnet 4-6)

De agent gebruikte 6 tools (lookup_bbl_eis, lookup_omgevingsplan_lokaal, bereken_achtererfgebied, check_eis_tegen_waarde, read_pdf_text, extract_drawing_info) en deed 71 stappen. Voor elke gemeten waarde gaf hij ook de bron mee: "UNIEC3-berekening pagina 10", "Bouwbesluit-berekening pagina 4".

Hoe haalt een agent de gebruiksoppervlakte uit een document?

Goede vraag: hoe vindt een agent zonder vision-LLM nu precies "de werkkamer is 8,50 m²"? Het antwoord is: de meeste indieningsdocumenten zijn tekst-PDFs, geen pure afbeeldingen.

• De Bouwbesluit-berekening (BBSL) en BENG-berekening (UNIEC3) zijn rekenmodel-uitvoer met daadwerkelijke tekst, tabellen en getallen. Hier haalt onze read_pdf_text tool (pypdf) de waarden uit.
• De tekening-PDFs (situatie, gevels, doorsneden) zijn vaak lijntekeningen mét tekstlabels — de tekst is leesbaar voor pypdf.
• Voor pure lijntekeningen zonder tekst-laag hebben we nog geen vision-LLM ingebouwd. Dat is een volgende fase met Claude vision of Gemma 4 vision.

Een ervaren vergunningverlener zou hier 2-4 uur over doen voor de eerste beoordeling, en zou alleen de punten op zijn checklist vinden. De Bbl-agent vond hier extra issues die in het oorspronkelijke aanvulverzoek niet voorkwamen (BENG-1 en luchtdichtheid), met concrete getallen, bron en paginanummers.

De 7 Hermes-agents — met bron-tracking per tool

Elke tool die een agent gebruikt is voorzien van een bron_info: of het uit een knowledge-file komt, een HTTP-API, het filesystem, of een berekening. Dit logt in de audit trail. Voorbeeld:

tool_call: bereken_leges
  args: {activiteit_type: "dakkapel", bouwkosten: 12000, bevoegd_gezag: "TB"}
  bron:
    type: knowledge_file
    naam: legesverordeningen/tubbergen_2026.json (CVDR752464)
    url:  https://lokaleregelgeving.overheid.nl/CVDR752464/2

tool_call: get_omgevingsplan_regels
  args: {locatie: "Raadhuisplein 8", activiteit_type: "dakkapel"}
  bron:
    type: http_api
    naam: DSO Regels op de Kaart (productie) / mock voor PoC
    url:  https://service.omgevingswet.overheid.nl/web/regels-op-kaart/

tool_call: lookup_bbl_eis
  args: {aspect: "energiezuinigheid_BENG"}
  bron:
    type: knowledge_file
    naam: bbl_eisen.json (afgeleid van Bbl Hoofdstuk 4 Nieuwbouw)
    url:  https://wetten.overheid.nl/BWBR0041297

Dit is exact wat de Algoritmeregister VNG en de Autoriteit Persoonsgegevens straks willen kunnen inzien: per beslissing welke bron is geraadpleegd, met welke parameters.

Multi-tenant voor één ambtelijke organisatie

Bij Noaberkracht Dinkelland Tubbergen bedient één ambtelijke organisatie twee bevoegde gezagen. Zelfde proces, zelfde mensen, maar verschillende verordeningen:

Zelfde aanvraag, zelfde activiteit, ander tarief per gemeente. De Beschikking-agent kiest automatisch de juiste verordening op basis van het bevoegd gezag dat de Intake-agent uit het adres heeft afgeleid (postcode 7591 → Denekamp → DK, 7651 → Tubbergen → TB).

WKB-meldingen komen deels via email — niet alleen DSO

De Omgevingswet vereist drie meldingen voor een Wkb-bouwwerk (gevolgklasse 1). Niet allemaal lopen via DSO:

In de praktijk zien we dat de melding "ik start morgen met de bouw" vaak per email of webformulier bij de gemeente binnenkomt — niet via DSO. Onze stack moet dus twee inkomende kanalen hebben: DSO STAM webhook én een mailbox-watcher. Die mailbox-watcher staat op de roadmap.

Wat agents (nog) niet kunnen

• Klantcontact bij twijfel — relatiewerk, empathie, "even bellen"
• Bezwaarprocedure — juridisch maatwerk, hoorzitting
• Politieke afweging — afwijking omgevingsplan, monumenten, gevoelige zaken
• Strategisch advies college — beleid, niet operationeel
• Beleidsontwikkeling — omgevingsplan onderhouden, welstandsnota
• Beoordelen pure lijntekeningen visueel — wel mogelijk met vision LLMs, nog niet ingebouwd
• APV-aanvragen via PDF/email — stookontheffing, evenementen, drank-en-horeca komen niet via DSO maar via formulier (volgende fase)
• Ondertekenen — wettelijk altijd mens met mandaat

Wat het kost — schatting

In de eerste blog stond €6-10K voor een rackserver. Voor de PoC gebruiken we cloud-LLMs (direct Anthropic):

Voor 500-2000 zaken per jaar (typisch middelgrote gemeente): on-prem hardware is binnen 1 jaar terugverdiend. Cloud is sneller live.

Probeer het zelf — upload je eigen (geanonimiseerde) aanvraag

Andere ingangen in de PoC:

• PowerBrowser-mock — overzicht van alle demo-zaken (Dinkelland D-, Tubbergen T-, NTB VTH-)
• Welstand-tab — stel een advies op, haal op, automatisch beschikking
• Leges-calculator — vergelijk Dinkelland vs Tubbergen voor dezelfde aanvraag
• Knowledge files — alle JSON-kennis die de agents gebruiken
• Agents & Tools in detail — per agent welke kennis + tools + echte voorbeeld-calls en responses