Agentische AI loopt tegen een infrastructuurmuur aan voordat ze tegen een intelligentiemuur aanloopt

De modellen verbeteren sneller dan ons vermogen om uit te voeren wat er van ze wordt gevraagd.

De meeste discussies over de toekomst van AI-agents gaan over hun mogelijkheden. Kan het model betrouwbaar plannen? Kan het zijn eigen fouten herstellen? Kun je het vertrouwen met een handeling die gevolgen heeft?

Dat zijn terechte vragen. Maar het zijn niet de vragen die bepalen of agents de komende jaren op grote schaal worden ingezet, want er is een directere beperking die sneller dichterbij komt. Agents zijn economisch lastig te bedienen, en dat wordt alleen maar lastiger naarmate ze precies de mogelijkheden krijgen die iedereen eraan wil toevoegen.

Een chatbot en een agent zijn verschillende workloads

Een conversatieverzoek bestaat uit één heen-en-terugronde. Je stuurt een prompt in, krijgt tokens terug en sluit de verbinding. Je kunt verzoeken in batches verwerken, de prefix cachen en de doorvoer met één getal inschatten.

Een agentverzoek is een sessie. De agent roept een tool aan, wacht, leest het resultaat, beslist wat hij vervolgens moet doen, roept een andere tool aan en geeft uiteindelijk antwoord. Zelfs een bescheiden taak kan zes of acht modelaanroepen omvatten, met tussendoor wachttijd.

Dat verschil is belangrijk om een reden die niets met intelligentie te maken heeft. Tussen stappen houdt de agent de toestand vast — het gesprek, de uitvoer van de tools en de opgebouwde redenering. Aan de kant van de modelbediening wordt die toestand als KV-cache in het GPU-geheugen bewaard, waar ze gedurende de hele sessie ruimte inneemt, ook in de seconden dat de agent wacht op een API die niet van jou is.

De capaciteit wordt dus niet langer uitgedrukt in ‘verzoeken per seconde’, maar in ‘gelijktijdige sessies die in het geheugen aanwezig zijn’. Een systeem dat met gemak duizend conversatieverzoeken per seconde afhandelt, kan op dezelfde hardware misschien maar enkele tientallen gelijktijdige agentsessies verwerken.

Het wachten is het duurste onderdeel

Dit is het ongemakkelijke aspect: tijdens een toolaanroep doet de agent niets. Er worden geen tokens gegenereerd en er wordt geen rekenkracht gebruikt. Het GPU-geheugen blijft echter bezet, omdat de context verwijderen en later opnieuw berekenen meer zou kosten dan die in het geheugen houden.

Je duurste hardware is gereserveerd voor een verzoek dat op dat moment op een databasequery wacht.

In conventionele gedistribueerde systemen hebben we dit lang geleden al opgelost: je geeft de resource vrij en hervat het werk zodra het antwoord binnenkomt. Voor modelbediening betekent hetzelfde dat je de KV-cache naar het hostgeheugen of een schijf verplaatst en daarna terugzet. De overdrachtskosten zijn zo hoog dat de meeste systemen daar geen moeite voor doen. Hiernaar wordt actief onderzoek gedaan, juist omdat het probleem duur is.

Sequentiële uitvoering maakt het probleem erger dan nodig

Vrijwel elk agentframework voert toolaanroepen na elkaar uit. Het model vraagt om een weersvoorspelling, krijgt die, vraagt om een agenda te controleren, krijgt het resultaat, vraagt om een vlucht te zoeken en krijgt ook dat resultaat.

Vaak zijn die drie aanroepen niet van elkaar afhankelijk. Ze hadden tegelijk kunnen worden uitgevoerd. Sequentiële uitvoering maakt de totale latentie gelijk aan de som van de drie tijden; bij gelijktijdige uitvoering is die gelijk aan de langste tijd.

Dit is geen nieuwe observatie over agents, maar hetzelfde structurele inzicht dat geldt voor elk systeem dat meerdere modellen of services binnen één latentiegrens uitvoert. De totale latentie moet overeenkomen met het langste pad door de afhankelijkheidsgraaf, niet met de som van alle stappen. Voor agents is dit extra belangrijk omdat de sessie gedurende de hele looptijd in het GPU-geheugen blijft. De kloktijd verkorten verbetert dus niet alleen de gebruikerservaring, maar vergroot rechtstreeks het aantal sessies dat op de hardware past.

Halveer de sessieduur en je verdubbelt ongeveer de gelijktijdige capaciteit, met dezelfde GPU’s en zonder het model te veranderen.

Retries stapelen zich op op een manier waar niemand rekening mee heeft gehouden

Agentframeworks nemen de standaardinstellingen voor retries over van de HTTP-bibliotheken waarop ze zijn gebouwd. Meestal zijn dat drie pogingen.

Het model probeert het op zijn eigen manier ook opnieuw. Als een tool een onbruikbaar resultaat oplevert, probeert een redeneermodel vaak een andere aanpak — ook een retry, alleen een die niemand heeft ingesteld.

Stapelt je die twee op elkaar, dan levert een beleid van drie pogingen rond een model dat zelf langs drie andere aanpakken redeneert een beleid van negen pogingen op, zonder dat iemand dat ooit heeft vastgelegd. Elk van die pogingen is een volledige modelaanroep, met eigen tokens en eigen GPU-seconden.

Wanneer een afhankelijkheid trager wordt, zorgt deze versterking ervoor dat een verslechtering uitmondt in een storing. Bovendien liggen de kosten per poging orden van grootte hoger dan bij een herhaalde REST-aanroep.

Hoe die muur er in werkelijkheid uitziet

Geen grens aan de mogelijkheden, maar iets alledaagsers: een probleem met de bedrijfseconomische haalbaarheid dat projecten tegenhoudt bij de overgang van pilot naar productie.

De pilot werkt. Er zijn tien gebruikers, de latentie is acceptabel en de rekening stelt vrijwel niets voor. Vervolgens rekent iemand het door voor tienduizend gebruikers en blijkt de benodigde hoeveelheid GPU’s onrealistisch — niet omdat het model traag is, maar omdat elke gelijktijdige sessie gedurende haar hele looptijd geheugen bezet houdt, en die looptijd ook de wachttijd omvat.

Dit is het punt waarop veelbelovende interne demo’s vaak stilletjes stranden.

Wat de muur opschuift

Niets exotisch, en dit is allemaal infrastructuur, geen modellering:

Voer onafhankelijke toolaanroepen gelijktijdig uit. De grootste afzonderlijke winst die vandaag beschikbaar is en waarvoor geen nieuwe hardware nodig is.

Neem de sessieduur als capaciteitsmaatstaf. Niet het aantal tokens per seconde. Niet de GPU-benutting. Maar hoelang de status in het geheugen blijft en hoeveel sessies daarin passen.

Stel een limiet in voor herhaalpogingen op systeemniveau, niet per aanroep. Een algemene limiet — waarbij herhaalpogingen een klein percentage van het totale verkeer uitmaken — voorkomt de hierboven beschreven opstapeling. Zowel de SRE-praktijk van Google voor het omgaan met overbelasting als de herhaalbudgetten van Envoy passen dit idee toe buiten de AI-stack.

Scheid redeneren van uitvoeren. Gebruik een groot model om te plannen en een veel kleiner model voor de mechanische stappen. Voor het meeste wat een agent doet, is geen grensverleggend model nodig.

Maak het verwijderen van context goedkoop. Een gekwantiseerde KV-cache, gepageerde aandacht en offloadpaden voor inactieve sessies. Op dit moment wordt hier het interessantste werk op het gebied van serving verricht.

De modellen zullen blijven verbeteren. Dat lijkt een zekerheid. Of agents infrastructuur worden of demo’s blijven, hangt af van iets minder glamoureus: of we een workload kunnen verwerken die kostbaar geheugen bezet houdt terwijl die wacht, en of we ophouden de som van een reeks stappen te betalen terwijl we ook alleen het langste pad zouden kunnen betalen.

Ik heb het uitvoeringsmodel achter dat laatste punt gepubliceerd — gelijktijdige uitvoering van afhankelijke modelaanroepen binnen één latentiebudget — in “Asynchrone uitvoering van inferentiegrafieken voor modelroutering in machineleersystemen”, International Journal of Computer Trends and Technology 72(10), oktober 2024. Voor de integratie van generatieve modellen in tijdkritische beslissystemen in het bijzonder, zie “Met LLM’s aangevulde handels- en beslisplatforms: generatieve intelligentie verbinden met financiële beslissystemen”, Journal of Information Systems Engineering and Management 11(1s), 2026.