NAME
agentic-infrastructure-stack — De agentische infrastructuur en de nieuwe backend
SYNOPSIS
cat agentic-infrastructure-stack.md
DESCRIPTION
We hebben vaak gesproken over agentische raamwerken. LangGraph, CrewAI, AutoGen, verschillende SDK's, loop, tool calling, geheugen, planner, criticus, supervisor. Allemaal nuttige woorden, in hemelsnaam. Maar hoe meer ik kijk naar de daadwerkelijk gebruikte agenten, hoe meer het mij lijkt dat het interessante deel onder het raamwerkniveau is gekomen.
De vraag is niet langer alleen: welke bibliotheek gebruik ik om een stappenmodel aan het denken te zetten?
De echte vraag is: waar woont deze agent als hij geen demo meer is?
Omdat een serieuze agent geen functie is die een model aanroept en tekst retourneert. Het is een klein gedistribueerd systeem. Het moet de context lezen, tools gebruiken, code uitvoeren, bestanden aanraken, beslissingen onthouden, toestemming vragen, goed falen, opnieuw opstarten, logboeken achterlaten, het budget niet verbranden en niet veranderen in een bulldozer in de productieopslagplaats.
Het raamwerk is het stuur. De infrastructuur is de weg, de remmen, de garage, de verzekering en de persoon die weet waar de sleutels zijn.
Omdat er nu veel over wordt gesproken
In 2023 en 2024 was het gesprek zeer modelgericht. Welke LLM? Hoeveel context? Hoeveel kost het? Hoe goed is hij in programmeren?
In 2025 en 2026 is het gesprek verschoven. De modellen zijn goed genoeg om echt werk te doen, maar daarom worden de saaie stukjes zichtbaar: runtime, beveiliging, connectoren, identiteit, waarneembaarheid, code-uitvoering, implementatie, rollback.
Het is de natuurlijke overgang van magie naar techniek.
Wanneer een agent alleen maar een reactie hoeft te genereren, is een chat voldoende. Wanneer u een pull-request moet openen, een database moet doorzoeken, een CRM moet aanroepen, een taak moet starten, door een site moet navigeren, Slack moet lezen, code moet compileren en een document moet bijwerken, heeft u er een besturingssysteem omheen nodig.
Niet in letterlijke zin. In organisatorisch opzicht.
Het eerste stuk: een looptijd waarin de agent het volhoudt
Een agent werkt vaak in stappen. Kijk naar de staat, kies een actie, gebruik een hulpmiddel, observeer het resultaat, werk het plan bij, herhaal.
Als deze lus zich binnen een enkel HTTP-verzoek bevindt, heb je meteen een probleem. Sommige acties zijn traag. Sommigen wachten op menselijke inbreng. Sommige mislukken en moeten opnieuw worden geprobeerd. Sommigen moeten een implementatie of time-out overleven.
Dit is waar duurzame workflows, wachtrijen, taakachtergronden en statusmachines een rol gaan spelen. Ze zijn niet glamoureus, maar ze zijn het verschil tussen een agent die slim lijkt tijdens de demo en een agent die je kunt laten werken terwijl je koffie gaat halen.
Voor mij moet de agentic runtime zeer concrete vragen beantwoorden:
- waar bewaar ik de status tussen de ene stap en de andere?
- wat gebeurt er als het proces halverwege stopt?
- kan ik pauzeren en om goedkeuring vragen?
- kan ik een run opnieuw afspelen om te begrijpen waarom hij die keuze heeft gemaakt?
- kan ik de duur, het geheugen, de tools en de kosten beperken?
Vercel zet zich op dit front hard in met AI SDK’s, functies, workflows en tools voor het bouwen van agents binnen webapplicaties. Maar het gaat niet alleen om Vercel. Het punt is dat de agent een operationeel thuis nodig heeft, en niet één enkel eindpunt.
Het tweede stuk: sandbox, omdat de agent vuil moet kunnen worden zonder te breken
Zodra een agent code schrijft of opdrachten uitvoert, is een sandbox nodig.
Het lijkt een technisch woord, maar het idee is huiselijk: je geeft hem een werkbank. Het kan bestanden openen, afhankelijkheden installeren, tests uitvoeren, experimenten uitvoeren en uitvoer genereren. Als hij het mis heeft, heb je de schade beperkt. Als het werkt, promoot dan het resultaat.
Een agentische sandbox moet enkele eigenschappen hebben:
- geïsoleerd bestandssysteem;
- CPU-, geheugen- en tijdslimieten;
- gecontroleerd netwerk;
- geheimen worden alleen gemonteerd wanneer dat nodig is;
- volledige logboeken;
- mogelijkheid om artefacten te exporteren;
- schone reset tussen runs, indien nodig.
Vercel Sandbox gaat precies deze kant op: geïsoleerde omgevingen om code uit te voeren, afhankelijkheden te installeren, met bestanden te werken en artefacten te produceren zonder alles in de runtime van de hoofdtoepassing uit te voeren.
Dit ding is belangrijker dan het lijkt. Veel agentische prototypes springen rechtstreeks van het model naar het echte systeem. Het model kan tool. Gereedschap kan dingen doen. Het lijkt allemaal elegant tot het eerste verkeerde commando, de eerste afhankelijkheid die op de verkeerde plaats wordt geïnstalleerd, het eerste token dat in een log belandt.
The sandbox is the adult way of saying: go ahead, but in here.
Het derde stuk: MCP en het connectorprobleem
Het Model Context Protocol is een van de meest interessante onderdelen van het ecosysteem geworden, omdat het iets probeert te standaardiseren dat anders snel onbeheersbaar wordt: hoe een model externe hulpmiddelen ontdekt en gebruikt.
Zonder standaard is elke integratie een klein eiland. Een connector voor GitHub op de ene manier, een voor Slack op een andere manier, een voor databases met verschillende semantiek, een voor browserautomatisering die op niets lijkt.
MCP stelt een gemeenschappelijke taal voor tussen client en server: tools, bronnen, aanwijzingen, autorisaties, transport, ontdekking. Het lost bestuur en veiligheid niet op magische wijze op, maar het geeft wel een grammatica.
En grammatica is belangrijk. Wanneer een agent verbinding kan maken met veel tools, is de vraag niet alleen "kan hij het?". Het probleem is: "Begrijpt hij wat hij kan doen, met welke grenzen, namens wie, en welke sporen nalaat?".
Voor mij is MCP geen hype omdat het "tool calling doet". Dat hebben wij al gedaan. Het is een hype omdat het het zwaartepunt verschuift van enkelvoudige integratie naar de operationele catalogus van tools.
In een goede agentische architectuur wordt MCP een soort patchpaneel:
- GitHub voor code en problemen;
- Speling voor gesprekscontext;
- Lineair of Jira voor gepland werk;
- alleen-lezen database voor analyses;
- browser of scraper gecontroleerd voor externe sites;
- documentopslag;
- geïsoleerde uitvoeringsomgevingen;
- interne systemen blootgesteld met strikte toestemmingen.
Het lastige is dat een beleidsvrije toolcatalogus slechts een elegantere manier is om chaos te creëren.
Het vierde stuk: identiteit en permissies
This is the area where many demos turn a blind eye.
Een agent handelt namens iemand. Het moet dus duidelijk zijn wie het onderwerp van de actie is.
Maakt het gebruik van gebruikersrechten? Van een serviceaccount? Van een werkruimte? Heeft u tijdelijk of permanent toegang? Kun je alles lezen of slechts enkele bronnen? Kun je schrijven? Kunt u annuleren? Kan hij echte mensen sms'en?
Als je deze vragen niet goed beantwoordt, bouw je vroeg of laat een assistent met huissleutels en geen herinnering aan wie ze aan hem heeft gegeven.
De vuistregel die ik hanteer is deze: de agent moet minder kunnen doen dan de mens, niet meer dan de mens. En als hij iets riskanters moet doen, moet hij stoppen en het vragen.
Dit betekent OAuth, tokenscope, geheimbeheer, auditlogboek, toolbeleid, toelatingslijst, goedkeuringsstap. Niet erg romantische dingen. Noodzakelijke spullen.
Het vijfde stuk: geheugen en context, maar zonder afval te verzamelen
Agenten hebben geheugen nodig, maar geheugen is gevaarlijk als het een zolderkamer wordt.
Er zijn minstens drie soorten geheugen:
- run memory: wat er tijdens deze uitvoering is gebeurd;
- projectgeheugen: conventies, beslissingen, beperkingen;
- persoonlijk of teamgeheugen: voorkeuren, toon, rituelen, processen.
Alles in de prompt plaatsen is de snelkoppeling. Het werkt totdat het niet meer werkt. Er moet voor nuttig geheugen worden gezorgd: geïndexeerd, bijgewerkt, verlopen, geverifieerd, citeerbaar gemaakt.
Een agent die zich slecht herinnert is slechter dan een agent die zich niets herinnert. Omdat hij met vertrouwen spreekt.
Daarom moet de infrastructuur het ophalen, instructiebestanden, de kennisbank, het inbedden wanneer dat nodig is, maar ook het opschonen omvatten. We hebben een herinneringscultuur nodig: wat komt binnen, wie keurt het goed, wanneer het vergaat, hoe corrigeer ik het.
Het zesde stuk: waarneembaarheid, evaluatie en herhaling
Als een agent een fout maakt, is het logboek 'het model genoemd' niet voldoende.
Je wilt de route zien. Welke context kreeg hij? Welke hulpmiddelen waren beschikbaar? Welk hulpmiddel heb je gekozen? Met welke argumenten? Welk antwoord kreeg je? Hoeveel kostte het? Waar is het vastgelopen? Heeft de mens iets goedgekeurd? Is er sprake van een foutmodel, tool, prompt, gegevens- of toestemmingsfout?
Hier lijken de agenten meer op gedistribueerde systemen dan op chatbots.
U hebt leesbare sporen nodig, niet alleen tekstlogboeken. Je moet een run opnieuw kunnen spelen. Het is noodzakelijk om twee versies van dezelfde agent voor bekende taken te vergelijken. We moeten regressies meten: het antwoordt niet alleen beter, maar het sluit ook het juiste ticket zonder ongevraagde bestanden aan te raken.
Agentische evaluaties zijn moeilijker dan tekstevaluaties omdat ze acties omvatten. Het is niet voldoende om een verwachte string te vergelijken. Je moet kijken naar sequenties, bijwerkingen, kwaliteit van het artefact, tijd, kosten, aantal menselijke interventies.
Het grappige is dat we daar altijd terugkomen: software engineering. Tests, omgevingen, sporen, rollbacks. Behalve dat de code nu ook beslist wat er vervolgens moet gebeuren.
Het zevende stuk: menselijke interfaces
De agent hoeft niet alleen in een chat te leven.
Sommige agenten hebben een bord nodig. Anderen een pagina met status en log. Anderen van een knop "goedkeuren". Meer inline-opmerkingen. Nog anderen van een CLI.
De gebruikersinterface verandert gedrag. Als de enige manier om een agent te controleren het schrijven van een lang bericht is, zal de gebruiker de agent vage instructies geven. Als hij echter het plan, de verschillen, de bronnen, de risico's en de volgende actie ziet, kan hij nauwkeurig ingrijpen.
Een fatsoenlijke agentinfrastructuur omvat bedieningsoppervlakken:
- huidige status;
- bewerkbaar plan;
- geproduceerde artefacten;
- verschil;
- goedkeuringsverzoeken;
- chronologie;
- stopknop;
- knop opnieuw proberen;
- zichtbare machtigingen.
Het lijkt triviaal, maar dat is het niet. Het verschil tussen ‘griezelige AI’ en ‘betrouwbare assistent’ is vaak alleen dat laatstgenoemde je laat zien waar hij zijn handen heeft.
De mentale stapel
Als ik het vandaag zou tekenen, zou de minimale agentenstapel dit zijn:
- Model: redeneren, genereren, tool calling, eventueel multimodaal.
- Orkestratie: loop, stap, planner, beleid, mens-in-de-loop.
- Duurzame runtime: workflow, wachtrij, opnieuw proberen, pauzeren, hervatten.
- Sandbox: code-uitvoering, geïsoleerd bestandssysteem, beperkingen, artefacten.
- Toollaag: MCP, interne API, browser, database, repository.
- Identiteitslaag: OAuth, reikwijdte, geheim, audit, beleid.
- Geheugenlaag: projectcontext, opvragen, instructies, vervaldatum.
- Waarneembaarheid: tracering, herhaling, evaluatie, kosten en kwaliteitsstatistieken.
- Productoppervlak: chatten als het genoeg is, dashboard als het nodig is, beoordelen als het er toe doet.
Het agentische raamwerk omvat voornamelijk punt 2 en een deel van punt 1. De rest is het echte werk.
Wat ik in de praktijk zou doen
Als een team me zou vertellen “we willen agenten in de productie”, zou ik niet met tien agenten beginnen.
Ik zou beginnen met een kleine, repetitieve en waarneembare workflow. Bijvoorbeeld: onderhouds-PR's openen, documentatie bijwerken van gesloten problemen, een wekelijkse beoordeling voorbereiden, dubbele bugs beoordelen, tests genereren voor getroffen bestanden.
Dan zou ik heel duidelijke grenzen stellen:
- niet schrijven zonder takken of zandbak;
- geen geheimen in de prompt;
- tools op de toelatingslijst;
- menselijke goedkeuring voor externe acties;
- verplichte log en trace;
- budget per run;
- output altijd controleerbaar.
Alleen dan zou ik uitbreiden.
Agenten falen niet alleen omdat de modellen het bij het verkeerde eind hebben. Ze mislukken omdat we ze in vage omgevingen plaatsen, met verwarrende toestemmingen en theatrale verwachtingen.
Mijn lezing
Agentische infrastructuur is op de beste manier saai.
Het is niet het onderdeel dat je doet klappen in de demo. Het is het onderdeel waarmee je de demo op maandagochtend daadwerkelijk kunt gebruiken, met echte mensen, echte gegevens en echte gevolgen.
De toekomst van agenten zal niet alleen worden bepaald door wie het beste rolmodel heeft. Het zal worden beslist door degene die de beste plek bouwt waarin hij kan werken: geïsoleerd als hij experimenteert, verbonden als dat nodig is, altijd waarneembaar, geautoriseerd met criteria en nederig genoeg om te stoppen als hij het niet weet.
Dat is waar agenten niet langer speelgoed zijn, maar infrastructuur worden.
Bronnen
METADATA
- date: 2026-06-30
- reading: 10 min
- author: Filippo Spinella
- tags: AI, Agents, Infrastructure, Developer Tools, Vercel