Vat dit dossier samen. Stel een categorie voor. Zoek de relevante bepaling in het contract.
Dat is een logische wens en meestal ook de juiste plek om te beginnen. Het proces dat jij hebt, is een proces waarvan bewezen is dat het voor jou werkt. Maar juist op dat moment wordt de architectuur van het bestaande systeem ineens heel belangrijk.
De terminologie helpt daarbij niet. RAG, agents, MCP, orchestration: iedere maand komen er nieuwe termen bij en iedere leverancier heeft zijn eigen lijst met patronen. Daaronder ligt één vraag die vrijwel alles bepaalt:
Hoeveel mag het model zelf beslissen en hoeveel blijft in je eigen code?
Eerst workflow, dan agent
Op dit punt zijn de mensen die het meest publiceren over het bouwen met taalmodellen het opvallend vaak met elkaar eens. Anthropic maakt onderscheid tussen workflows, waarbij jouw code het pad bepaalt en het model de stappen uitvoert, en agents, waarbij het model zelf het pad kiest. De architectuurrichtlijnen van Microsoft adviseren om het laagste niveau van complexiteit te gebruiken dat het werk betrouwbaar uitvoert, en noemen één agent met tools vaak de juiste standaard voor enterprise-omgevingen. Thoughtworks' Technology Radar beweegt inmiddels dezelfde kant op.
Voor bestaande software is dat goed nieuws. Je systeem kent het proces al. Het weet welke stap op welke volgt, wie wat mag doen en wanneer iets klaar is. Precies die kennis zou een agent anders zelf moeten proberen te achterhalen.
Daarom zie ik het als een ladder. Elke trede geeft het model iets meer controle en vraagt daar in ruil meer van je systeem voor terug.
Trede 1: het model geeft antwoord, jouw code beslist
Het model krijgt een vraag en geeft een antwoord terug. Jouw code bepaalt wat ermee gebeurt. Een samenvatting in een zijpaneel. Een voorgestelde categorie in een dropdown. Een conceptantwoord dat de gebruiker kan aanpassen.
Twee dingen maken dit geschikt voor productie. Als je code het antwoord gaat gebruiken, vraag dan om gestructureerde output: een vast format dat je code kan valideren, in plaats van een tekstblok dat je eerst moet proberen te ontleden.
En bepaal of iemand moet wachten. Een samenvatting die 's nachts uit een wachtrij wordt verwerkt, vraagt vrijwel niets van je applicatie. Een knop waarop een gebruiker klikt, vraagt om een scherm dat om kan gaan met een antwoord dat enkele seconden duurt, plus een plan voor het geval de provider traag of niet beschikbaar is.
In beide gevallen moet je precies weten welke velden in de prompt terechtkomen, want die verlaten je systeem.
Trede 2: het model kent jouw data
Nu geeft het model antwoord op basis van je procedures, contracten of tickets in plaats van algemene kennis. Zoek de relevante informatie op, geef die aan het model en laat het daaruit een antwoord formuleren.
Dit is de meest gevraagde stap en tegelijkertijd de meest onderschatte.
De index moet synchroon blijven met je data. De toegangsrechten moeten op het moment van de zoekopdracht worden gerespecteerd: als een gebruiker een document niet in de applicatie kan openen, mag het model het ook niet aan die gebruiker citeren.
Bij veel oudere systemen zitten die rechten in de schermen en niet in de data. Daar zit het meeste werk verborgen. De rest zit in de documenten zelf. Drie versies van dezelfde procedure en het model heeft geen idee welke de actuele is.
Voor cijfers is dit vaak het verkeerde hulpmiddel. Een model dat zelf SQL schrijft tegen je database, produceert al snel vol vertrouwen de verkeerde bedrijfsgegevens. Laat het in plaats daarvan een laag aanspreken die al weet wat "omzet" of "openstaande order" binnen jouw organisatie betekent.
Trede 3: het model volgt jouw proces
Hier voert het model meerdere stappen uit, maar bepaalt jouw code de volgorde. Classificeer het binnenkomende verzoek, stuur het naar de juiste afhandeling, laat één stap een concept maken en een andere stap het controleren.
Het pad is voorspelbaar, testbaar en uitlegbaar, omdat jij het hebt geschreven.
Veel toepassingen in de praktijk eindigen op deze trede. En dat is prima.
Trede 4: het model handelt
Nu kan het model functies in je systeem aanroepen: een order opzoeken, een voorraadniveau controleren, een ticket aanmaken. Het model stelt de aanroep voor. Jouw code bepaalt of die daadwerkelijk wordt uitgevoerd.
Daarvoor heb je een API nodig, en niet ieder bestaand systeem heeft die. Je hebt ook een rechtenmodel nodig waar je op kunt vertrouwen, omdat het model moet handelen met de rechten van de gebruiker namens wie het werkt, en nooit met meer rechten dan die gebruiker heeft.
Begin met lezen. Schrijven komt later, met een expliciete bevestiging.
En iedere tekst die het model leest — een e-mail of een geüpload document — kan instructies bevatten. Het model kan die instructies opvolgen.
Nog een woord over MCP, het protocol dat momenteel door iedereen lijkt te worden omarmd. Het is nuttig, maar je bestaande API één-op-één omhullen en die vervolgens aan een model geven, is geen architectuurontwerp. Thoughtworks waarschuwt inmiddels expliciet tegen het standaard inzetten van MCP.
Een interface die voor een model is gebouwd, moet kleiner en veiliger zijn dan de interface die je voor je front-end hebt gebouwd.
Trede 5: het model bepaalt de stappen
Pas nu bepaalt het model zelf de route: zoeken, lezen, een tool aanroepen, een beslissing nemen en vervolgens een andere tool aanroepen.
Gebruik dit alleen wanneer de volgende stap echt niet vooraf te bepalen is.
Je hebt alles nodig van de eerdere treden, plus een trace van iedere stap, grenzen aan tijd en kosten en een duidelijk moment waarop het model stopt en het werk overdraagt aan een mens.
In een systeem met nette API's, events en expliciete rechten is dat haalbaar. In een systeem zonder die zaken zal de agent iedere zwakke plek in je architectuur vinden. En snel ook.
Eén deur voor al het modelverkeer
Op welke trede je ook zit, plaats één laag tussen je applicaties en de modelproviders.
Die laag regelt authenticatie, logging, kostenlimieten en een fallback wanneer een provider uitvalt. Later kan diezelfde laag eenvoudige verzoeken naar een klein, goedkoop model sturen en moeilijke verzoeken naar een groter model.
Het is niet het meest spannende werk. Het is wel de plek waar je in de toekomst antwoord wilt kunnen geven op iedere vraag over kosten, privacy en kwaliteit.
Wat de ladder je vertelt
Kijk naar wat de hogere treden nodig hebben: API's, events en een autorisatiemodel dat in de data zit in plaats van in de schermen.
Niets daarvan is specifiek voor AI. Het is wat ieder systeem nodig heeft om veranderbaar te blijven.
De meeste systemen die we onderhouden, zijn ontworpen voordat iemand ooit van taalmodellen had gehoord. Dat is zelden het echte probleem. Of een systeem AI kan opnemen, hangt af van beslissingen die jaren geleden zijn genomen.
Is er een API? Publiceert het systeem wat er gebeurt? Is duidelijk wie wat mag zien?
Als het antwoord nee is, dan is je eerste AI-project in feite een architectuurproject.
En precies diezelfde verbindingen en scheidslijnen maken het systeem ook om andere redenen makkelijker te veranderen.
Laat het model de taal doen. Laat je code de controle houden.
Waar ik zou beginnen
Kies één taak met een duidelijke eigenaar en een meetbare "situatie vooraf". Begin op de laagste trede die het probleem oplost. Ga pas een trede hoger wanneer de huidige trede goed draait in productie, niet alleen in een demo.
Welke trede bij jouw systeem past, is meestal binnen een uur vast te stellen, met één concrete use case en iemand die de architectuur kent.
Neem ze allebei mee. Wij zorgen voor de koffie.
