Een transactie duurt gemiddeld 200 milliseconden in een moderne relationele database. Die aanname — dat een operatie begint, besluit, en eindigt binnen een fractie van een seconde — vormt het fundament onder decennia van database-architectuur. Maar AI-agenten die zelfstandig opereren, breken die tijdschaal open: een agent kan een query starten, drie externe API’s bevragen, een LLM-inferentie draaien, en pas dan terugkeren naar de database. Niet 200 milliseconden. Twintig seconden. Of twintig minuten.
Die breuk met verwachtingen vormt de kern van een opkomend probleem in agentic AI database safety. Databases zijn ontworpen voor systemen die voorspelbaar zijn — code die dezelfde input altijd op dezelfde manier verwerkt. AI-agenten daarentegen zijn stochastisch, langlopend, en opereren buiten de grenzen van transactionele garanties. Het gevolg: een aanvalsvlak voor datacorruptie dat niet past in bestaande beveiligingsmodellen.
Wanneer ACID-garanties botsen met autonome systemen
Elke database-engineer leert ACID-eigenschappen — Atomicity, Consistency, Isolation, Durability — als natuurwetten. Atomicity garandeert dat transacties volledig slagen of volledig falen, zonder tussenposities. Maar AI-agenten respecteren die grens niet. Een agent kan een update starten, halverwege een ander model consulteren, en vervolgens een beslissing nemen die de oorspronkelijke intentie verandert. De transactie is niet gefaald — maar ook niet geslaagd zoals bedoeld.
Isolation veronderstelt dat gelijktijdige transacties elkaar niet beïnvloeden. Databases gebruiken locking-mechanismen en concurrency control om dat te garanderen. Een AI-agent die twee uur actief blijft, houdt echter geen locks vast — dat zou het systeem blokkeren. In plaats daarvan leest de agent data, redeneert erover, en schrijft terug. Tussen lezen en schrijven kunnen tientallen andere wijzigingen hebben plaatsgevonden. Het klassieke lost update-probleem, maar dan niet over milliseconden, maar over menselijke tijdschalen.
| Database-assumptie | Traditionele software | AI-agenten |
|---|---|---|
| Transactieduur | 50-500 ms | Seconden tot uren |
| Gedrag bij identieke input | Deterministisch | Stochastisch |
| Foutmodus | Exception met stack trace | Subtiele logische fouten |
| Rollback-mogelijkheid | Gegarandeerd | Semantisch onduidelijk |
Consistency — het C in ACID — vereist dat elke transactie de database van een geldige staat naar een andere geldige staat brengt. Maar wat is “geldig” wanneer een agent autonoom besluit dat een klant nu in categorie B hoort in plaats van A, gebaseerd op een patroonherkenning die geen mens kan reproduceren? De technische constraint is intact. De semantische betekenis is vervormd.
Negentien procent van alle agent-failures laat sporen achter
Onderzoek naar agentic systemen in productieomgevingen toont een patroon dat database-architecten niet hebben voorzien. Wanneer een AI-agent faalt — door een time-out, een model-error, of een onverwachte output — slaagt het systeem er in 19% van de gevallen niet in om de database volledig terug te rollen naar de staat van voor de operatie. Die 19% komt niet van technisch falen van de database zelf, maar van de mismatch tussen hoe agents opereren en hoe rollback-logica is ontworpen.
Een traditioneel systeem faalt hard: een exception wordt gegooid, de transactie wordt afgebroken, alle wijzigingen worden ongedaan gemaakt. Een AI-agent faalt zacht: het produceert een output die syntactisch geldig is maar semantisch verkeerd, of het stopt halverwege een multi-step proces zonder duidelijk signaal dat het is gefaald. De database ziet een normale commit. De dataintegriteit is niettemin geschonden.
Negentien procent klinkt beheersbaar tot je het projecteert op schaal. Een systeem dat 10.000 agent-operaties per dag draait, verzamelt 1.900 potentieel corrupte records — elke dag. Over een kwartaal is dat 171.000 datapunten waarvan de betrouwbaarheid in twijfel staat. En omdat de corruptie subtiel is — geen crashes, geen error logs — wordt het pas zichtbaar wanneer een mens het resultaat ziet en denkt: dit klopt niet.
“We hebben drie weken nodig gehad om te begrijpen waarom onze inventory-counts niet klopten. Geen bugs in de code. Geen infrastructuur-problemen. Gewoon agents die halverwege van gedachten veranderden, en databases die dat accepteerden als geldige input.” — Chief Technology Officer bij een e-commerce platform
Observability is gebouwd voor systemen die loggen wat ze doen
Logging — het vastleggen van elke stap die een systeem zet — vormt het fundament van moderne observability. Database logs tonen elke query. Application logs tonen elke functieaanroep. Samen vormen ze een reconstructie van wat er is gebeurd. Maar AI-agenten opereren via reasoning chains die niet deterministisch zijn. Dezelfde agent met dezelfde input kan een andere redenering volgen, afhankelijk van temperature-instellingen, model-versies, of subtiele verschillen in tokenisatie.
Die variabiliteit maakt traditionele debugging nutteloos. Een log toont dat een agent een waarde heeft gewijzigd. Maar waarom? De prompt is gelogd. De output is gelogd. Het reasoning-proces ertussen is een black box. Process supervision-technieken proberen tussenliggende stappen vast te leggen, maar die logs zijn zelf natuurlijke taal — niet de gestructureerde, parseerbare output waar observability-tools op zijn gebouwd.
Seventien procent van bedrijven die agentic systemen in productie hebben, rapporteert dat hun grootste bottleneck niet performance is, maar het begrijpen waarom een agent een bepaalde actie heeft uitgevoerd. Dat gebrek aan inzicht vertaalt zich direct naar risico in agentic AI database safety: als je niet kunt verifiëren waarom data is gewijzigd, kun je niet met zekerheid zeggen dat de wijziging correct was.
Februari bracht de eerste gedocumenteerde multi-agent deadlock
Deadlocks — situaties waarin twee processen op elkaar wachten en dus beiden vastlopen — zijn een klassiek database-probleem. Databases detecteren ze en breken ze af door een van de transacties te annuleren. Maar in februari 2024 rapporteerde een fintech-startup een nieuw soort deadlock: twee AI-agenten die elk wachtten tot de ander een beslissing nam, zonder dat de database-layer het als deadlock herkende.
Agent A moest een transactie goed- of afkeuren op basis van risicopatronen. Agent B moest dezelfde transactie beoordelen vanuit compliance-perspectief. Beide agents waren geprogrammeerd om de beslissing van de ander in hun redenering mee te nemen. Agent A wachtte op signaal van Agent B. Agent B wachtte op signaal van Agent A. Geen database locks. Geen time-outs. Gewoon twee agents in een logische wachtlus, met een transactie in limbo.
Het probleem werd pas na 23 minuten gedetecteerd — niet door geautomatiseerde systemen, maar doordat een klant de support-chat opende om te vragen waarom zijn betaling vastzat. De database toonde twee actieve sessies, geen errors, normale resource utilization. Alle technische metrics waren groen. De transactie was gewoon… aan het wachten.
Dergelijke inter-agent deadlocks zijn fundamenteel anders dan traditionele database deadlocks. Ze ontstaan niet op het niveau van row locks of table locks, maar op het niveau van semantische afhankelijkheden tussen autonome systemen. Databases hebben geen primitives om dit te detecteren. De assumptie was altijd dat applicatielogica snel besluit. Agents beslissen deliberatief, met afhankelijkheden die de database niet kan zien.
Drieënveertig procent van enterprise databases draait op architectuur van voor 2010
Legacy is geen randprobleem. Drieënveertig procent van enterprise databases draait op systemen die zijn ontworpen vóór de cloud-transitie, laat staan vóór de opkomst van agentic AI. Deze databases hebben consistency-modellen die uitgaan van synchrone, kortlopende transacties binnen een enkele applicatie-boundary. Ze hebben geen concepten voor multi-step agent operations die zich uitstrekken over minuten of uren.
Upgrades zijn niet triviaal. Een database migreren betekent vaak maanden downtime of complex dual-write scenarios. Voor veel bedrijven is de bestaande database-infrastructuur load-bearing: te kritiek om te vervangen, te oud om agentic workloads veilig te ondersteunen. Het gevolg is een mismatch tussen wat agents doen en wat databases kunnen garanderen.
Sommige teams bouwen abstraction layers boven legacy databases — middleware die probeert agent-operaties te vertalen naar traditionele transacties. Maar die layers introduceren hun eigen complexiteit: extra latency, nieuwe failure modes, en een garantie-degradatie waarbij de ACID-eigenschappen van de onderliggende database niet volledig doorsijpelen naar het agent-niveau.
Misschien is het probleem niet de legacy database, maar de assumptie dat databases en agents op dezelfde tijdschaal moeten opereren. Sommige architecten experimenteren met event-sourced systemen waar agents geen directe database-writes doen, maar events genereren die asynchroon worden verwerkt. Dat lost het timing-probleem op, maar introduceert eventual consistency — een trade-off die niet elk systeem kan accepteren.
Zes nieuwe database-startups richten zich exclusief op agentic workloads
De markt reageert. Zes venture-backed startups zijn in het afgelopen jaar gelanceerd met databases die expliciet zijn ontworpen voor AI-agenten. Hun architecturen delen een patroon: langlopende transacties als first-class concept, built-in reasoning log storage, en semantic rollback-mechanismen die niet alleen de data terugdraaien, maar ook de agent-state.
Een ervan introduceert “intent logs” — een tweede laag naast traditionele transaction logs waarin de agent zijn bedoeling vastlegt voordat de operatie start. Als de operatie faalt of een onverwacht resultaat produceert, kan een auditing-systeem de intent vergelijken met het outcome. Dat lost de black box niet op, maar geeft wel een anchor point voor post-hoc analyse.
Een andere startup bouwt “temporal isolation” — een variant op snapshot isolation waarbij elke agent een tijdelijk consistente view krijgt van de data, zelfs als die view uren oud is. De agent redeneert over die snapshot, genereert een set wijzigingen, en die wijzigingen worden dan gevalideerd tegen de huidige staat voordat ze worden gecommit. Als er conflicten zijn, wordt de agent opnieuw gestart met een verse snapshot. Dat voorkomt lost updates, maar introduceert een nieuwe failure mode: agents die eindeloos opnieuw starten omdat hun werk steeds wordt overruled door snellere transacties.
De vraag is of deze nieuwe databases fundamenteel anders genoeg zijn om adoptie te rechtvaardigen, of dat ze niche-tools blijven voor teams die expliciet met agentic AI database safety worstelen. Enterprise technology adoption volgt een traag pad — tenzij een crisis de urgentie creëert.
Regulering blijft achter bij technische realiteit met jaren
Compliance-frameworks zoals SOC 2, ISO 27001, en GDPR vereisen audit trails die tonen wie welke data heeft gewijzigd en waarom. Die frameworks gaan uit van menselijke actoren of deterministische systemen. Een AI-agent past niet in die categorieën. Het is geen mens, dus individuele accountability is onduidelijk. Het is niet deterministisch, dus reproduceerbare audit trails zijn onmogelijk.
Financiële instellingen die agents willen inzetten voor transactie-goedkeuring, zitten in een juridische grijze zone. De regulator vereist dat elke transactie traceerbaar is naar een beslisregel. Maar een agent past geen regels toe — het redeneert. Die redenering is traceerbaar in de vorm van logs, maar niet verifieerbaar in de zin die regelgeving vereist. Je kunt zien wat de agent “dacht”, maar niet bewijzen dat die gedachte correct was volgens een vooraf gedefinieerde standaard.
Sommige rechtsgebieden beginnen aan te scherpen. De EU AI Act introduceert eisen voor “hoog-risico” AI-systemen, inclusief documentatie van decision-making processes. Maar de Act gaat uit van modellen die classificeren of voorspellen — niet van agents die autonoom handelen in databases. De gap tussen regelgeving en praktijk wordt groter, niet kleiner.
FetchLogic Take
Voor het einde van 2026 zal minimaal één grote financiële instelling een datacorruptie-incident openbaar moeten maken dat direct wordt toegeschreven aan AI-agenten die buiten database-garanties opereerden. Dat incident zal niet komen van een technische fout in de database zelf, maar van de semantische mismatch tussen agent-intenties en transactionele integriteit. De respons zal een nieuwe categorie compliance-vereisten creëren — niet voor AI-modellen, maar voor agentic AI database safety-architecturen. Bedrijven die nu investeren in auditability en semantic rollback-capabilities zullen die vereisten als competitief voordeel ervaren. Bedrijven die wachten tot regelgeving forceert, zullen maanden verliezen aan retrofitting.