Snel shippen voelt pas later ingewikkeld
De eerste versie van een AI-agent is vaak verrassend overzichtelijk. Een team wil een supportvraag beantwoorden, een interne kennisbron doorzoeken of een voorstel genereren. Er is een operationele tabel, er is semantische zoeklogica, en er is een model dat iets zinnigs moet teruggeven.
Een actueel bericht over Build a unified AI agent architecture with DynamoDB and Bedrock is hier de context. Het nieuws is niet het punt; het maakt de operationele beslisdruk zichtbaar.
Op papier lijkt het logisch om alles zo dicht mogelijk bij elkaar te houden. Minder losse systemen. Minder integraties. Minder plekken waar iets kan breken.
Amazon speelt daar nu expliciet op in. In de architecture post over DynamoDB en Bedrock beschrijven ze een setup met native vector search in Amazon DynamoDB, waarbij embeddings naast operationele data in één table staan. Diezelfde table wordt gebruikt voor structured lookups én semantic search, terwijl DynamoDB Streams de embeddings synchroon houdt.
Dat is aantrekkelijk. Maar het schuift ook één vraag naar voren waar veel teams te laat eerlijk over zijn: optimaliseer je hier voor bouwgemak, of voor uitlegbaarheid van het gedrag later?
Eén table is geen neutrale keuze
Een unified table klinkt als volwassen architectuur. In werkelijkheid is het vooral een keuze om twee soorten waarheid samen te brengen.
De eerste waarheid is operationeel. Wat staat er in het account, ticket, contract of productrecord? Dat is netjes, exact en goed te testen.
De tweede waarheid is semantisch. Welke embedding hoort bij dit record? Welke context is “dichtbij genoeg” om terug te geven? Dat is probabilistischer, afhankelijk van modelkeuze, indexering en hoe recent de vector nog is.
Zodra je die twee samenvoegt, wordt de tafel niet per se complexer in schema, maar wel in gedrag. Een write is niet meer alleen een write. Een update triggert ook synchronisatie van embeddings. Een lookup is niet meer alleen een lookup. Het resultaat hangt nu ook af van de semantische laag die daar bovenop ligt.
Dat is precies waarom deze aanpak nuttig is voor teams die snel willen bouwen. Je beperkt het aantal systemen. Je maakt de eerste agent eenvoudiger te shippen. Je hoeft niet meteen een losse vectorstore, een extra synchronisatiepad en nog een aparte data-eigenaar in te richten.
Maar eenvoud in de eerste sprint is niet hetzelfde als helderheid in week twaalf.
Het kleine probleem dat later groot wordt
De misser die ik hier vaak zie is niet technisch heroïsch. Het is klein en saai.
Een team laat een agent draaien op een unified data model. De demo werkt. De retrieval voelt slim. Daarna komt de eerste supportvraag: waarom gaf de agent dit antwoord en niet dat andere record?
Dan blijkt dat niemand precies kan aanwijzen welke laag leidend was. Was het de structured lookup? De semantische match? Een embedding die nog niet was bijgewerkt? Een sync-keten via Streams die net achter liep? Of een index die inhoudelijk nog prima was, maar operationeel niet meer past bij de laatste wijziging?
Op dat moment is de discussie niet meer “werkt de AI?”. De discussie wordt “welke fout zien we eerst, en hoe lang kan die onzichtbaar blijven?”.
Dat is een ander soort softwareprobleem. Niet groter, wel lastiger uit te leggen aan product, support en leadership tegelijk.
En precies daar zit de spanning voor softwareleiders. Een agent die snel antwoorden geeft, kan alsnog een slecht productbesluit worden als niemand snapt welk signaal het antwoord heeft gestuurd.
De winst zit niet in elegantie, maar in beslisfrictie
Fourlab kijkt hier niet naar als een puur infrastructuurverhaal. Dit is vooral een productkeuze.
Als je embeddings naast operationele data zet, verklein je de frictie om te beginnen. Dat is reëel voordeel. Je kunt sneller experimenteren, sneller itereren en minder tijd verliezen aan integratieplumbing.
Maar je betaalt met een andere vorm van complexiteit: je moet explicieter worden over uitlegbaarheid, testbaarheid en monitoring. Niet omdat AI “onbetrouwbaar” zou zijn als containerbegrip, maar omdat je nu meer afhankelijk bent van de relatie tussen twee verschillende representaties van dezelfde werkelijkheid.
Voor sommige teams is dat prima. Als de agent alleen een eerste filter doet of een intern zoekproduct ondersteunt, kan één table precies de juiste trade-off zijn.
Voor andere teams is het onhandig. Denk aan situaties waarin de agent direct invloed heeft op prioritering, klantadvies of operationele acties. Dan wil je niet alleen weten of de query snel genoeg is. Je wilt weten welke fout je het minst lang niet mag zien.
Dat ene zinnetje stuurt de architectuur vaak beter dan een generieke “AI-ready” ambitie.
Waar je op stuurt als de eerste versie werkt
De AWS-aanpak maakt iets zichtbaar dat in veel teams toch al speelde: AI-architectuur wordt snel aantrekkelijk als alles onder één dak lijkt te passen. DynamoDB met native vector search, Bedrock als agentlaag, Streams voor synchronisatie — het is een nette route naar een werkende eerste versie.
Maar een werkende eerste versie is niet de eindvraag.
De echte vraag is wat je later nog kunt verklaren. Als een agent iets teruggeeft, kun je dan nog reconstrueren of de semantische laag leidend was, of de operationele data? Kun je zien wanneer een embedding verouderd raakte? Kun je een syncvertraging herkennen voordat product of support erop vastloopt?
Als het antwoord daarop vaag blijft, dan heb je niet alleen een technische schuld opgebouwd. Je hebt ook productschuld opgebouwd. Want het team leert dan om het systeem te vertrouwen op gevoel, niet op duidelijkheid.
Dat is zelden de bedoeling. Het gebeurt gewoon omdat “één table” zo heerlijk compact klinkt in de architectuurreview.
Mijn standpunt is simpel: unified AI architecture is een versneller, geen bewijs van volwassenheid. Gebruik het als het je beslisfrictie verlaagt. Niet als het alleen maar mooi oogt in een diagram.
En als je twijfelt waar je begint, begin dan niet bij de vraag welke database bij AI past. Begin bij de vraag welke fout je het minst lang niet wilt zien.