AI-agents hebben vooral een goede werkomgeving nodig
Kernantwoord: een agent is geen prompt, maar een werker met context
Veel AI-teams beginnen bij agents met dezelfde vraag: welk model is slim genoeg? Die vraag is logisch, maar vaak te smal. Zodra een agent meer moet doen dan antwoorden formuleren, ontstaat een tweede laag die minstens zo bepalend is: waar werkt die agent eigenlijk? Een agent die code moet aanpassen, bestanden moet vergelijken, een browser moet gebruiken of meerdere stappen moet onthouden, heeft een omgeving nodig waarin dat veilig en herhaalbaar kan.
Een prompt kan instructies geven, maar geen betrouwbare werkplek vervangen. In een chatvenster kun je een taak beschrijven. In een echte agent-workflow moet er ook iets gebeuren: een bestand openen, een test draaien, een tussenresultaat opslaan, een fout herstellen, een nieuwe poging starten en uiteindelijk aantonen wat er is veranderd. Dat vraagt om meer dan modelintelligentie. Het vraagt om agent-compute: de combinatie van geïsoleerde uitvoering, state, tooling, toegangsgrenzen, resourcebeheer en observability.
De praktische verschuiving is belangrijk voor technische beslissers. Een agent wordt niet automatisch bruikbaar omdat hij autonoom klinkt. Hij wordt bruikbaar wanneer het werkontwerp klopt. Welke taak krijgt de agent? Welke data mag hij zien? Welke acties mag hij uitvoeren? Wanneer stopt hij? Hoe wordt het resultaat gecontroleerd? En hoe voorkom je dat experimenten op de laptop van één developer blijven hangen, terwijl het team eigenlijk reproduceerbare evaluaties nodig heeft?
Van losse code-uitvoering naar een stateful sandbox
Een eenvoudige code-execution box kan nuttig zijn voor kleine taken: voer dit script uit, geef de output terug, klaar. Maar veel agenttaken gedragen zich niet zo netjes. Ze bestaan uit meerdere stappen, gebruiken tijdelijke bestanden, installeren afhankelijkheden, openen documentatie, bewaren context en corrigeren onderweg fouten. Als elke stap in een lege, stateless omgeving begint, moet de agent voortdurend opnieuw opbouwen wat hij net heeft gedaan. Dat maakt workflows fragiel en lastig te beoordelen.
Daarom wordt de stateful sandbox zo belangrijk. Stateful betekent niet dat een agent onbeperkt alles mag bewaren. Het betekent dat de omgeving bewust kan onthouden wat voor de taak nodig is: bestanden, configuratie, sessiestatus, logs en tussenresultaten. Sandbox betekent tegelijk dat die omgeving begrensd is. De agent krijgt een eigen werkruimte, niet onbeperkte toegang tot het hele netwerk, alle systemen of alle data.
Voor AI-teams levert dit concrete ontwerpvragen op. Wat mag de agent downloaden? Mag hij dependencies installeren? Mag hij bestanden wijzigen of alleen voorstellen doen? Hoelang blijft state bewaard? Wordt de omgeving na afloop gewist, bevroren of opnieuw gebruikt? Kan een reviewer exact zien welke stappen zijn uitgevoerd? Dit zijn geen randdetails. Ze bepalen of een agentworkflow controleerbaar genoeg is om verder te komen dan een demo.
Schaal gaat niet alleen over meer CPU’s of GPU’s
Zodra agents parallel gaan werken, verandert de infrastructuurvraag. Eén agenttaak die lokaal draait is overzichtelijk. Honderden tijdelijke taken, evaluaties of browserruns zijn iets anders. Dan gaat het niet alleen om ruwe rekenkracht, maar om planning, isolatie, opstarttijd, cleanup en limieten. Een omgeving die voor één experiment acceptabel voelt, kan onhandig worden wanneer meerdere teams, pipelines of evaluaties tegelijk draaien.
De neiging is om schaal direct te vertalen naar meer hardware. Dat is te simpel. Agents hebben vaak piekachtig gedrag: veel tijdelijke omgevingen starten kort op, doen een afgebakende taak en verdwijnen weer. De architectuur moet daarom niet alleen krachtig zijn, maar ook elastisch en opruimbaar. Instant startup, dynamische resources en duidelijke quota zijn dan praktische voorwaarden, geen luxe.
Voor een team dat agents serieus test, is de vraag: wat gebeurt er als tien taken tegelijk draaien, en wat gebeurt er bij honderd? Blijft logging bruikbaar? Worden omgevingen netjes afgesloten? Is duidelijk welke run bij welk resultaat hoort? Kan een mislukte taak opnieuw worden uitgevoerd met dezelfde beginstate? Als het antwoord daarop onduidelijk is, heb je geen schaalprobleem maar een werkontwerpprobleem.
Waarom evaluaties andere eisen stellen dan demos
Een demo mag indrukwekkend zijn, maar evaluatie vraagt herhaalbaarheid. Als een agent een taak oplost, wil je weten of dat toeval was, of het opnieuw lukt en onder welke voorwaarden het faalt. Dat is alleen zinvol wanneer de testomgeving consistent genoeg is. Dezelfde opdracht, vergelijkbare beginstate, gecontroleerde data, gelogde stappen en een meetbare uitkomst vormen samen de basis.
Bij evaluaties en trainingsachtige workflows kunnen veel tijdelijke omgevingen nodig zijn. Niet omdat elk bedrijf direct massale agentinfrastructuur moet bouwen, maar omdat betrouwbaar meten vaak meerdere runs vereist. Je wilt varianten vergelijken, fouten categoriseren, regressies zien en voorkomen dat een agent alleen goed lijkt te presteren in een rommelige testopzet.
Dit maakt observability onmisbaar. Een agent die een eindantwoord geeft zonder spoor van zijn stappen, is moeilijk te verbeteren. Welke tool gebruikte hij? Welke bestanden zijn aangemaakt? Waar ontstond de fout? Welke actie duurde te lang? Zonder die informatie blijft evaluatie subjectief. Met goede logging kun je agentgedrag terugbrengen tot concrete verbeterpunten: betere instructies, strakkere tools, kleinere taken of strengere stopregels.
Besturingssystemen, browsers en bestanden zijn geen bijzaak
Veel echte taken spelen zich niet af in één nette API. Ze gebruiken browsers, bestandsmappen, command line tools, documentatie, formulieren of legacy-systemen. Daardoor wordt de werkomgeving van de agent belangrijker dan vaak wordt gedacht. Soms is een Linux-achtige omgeving voldoende. Soms wil een team juist testen hoe een agent zich gedraagt in een browseromgeving of op een specifiek besturingssysteem. Niet omdat dat hip is, maar omdat de taak daar plaatsvindt.
De valkuil is dat teams te vroeg abstraheren. Ze bouwen een generieke agentlaag voordat duidelijk is welke omgevingen echt nodig zijn. Beter is om te beginnen met één herhaalbare taak. Bijvoorbeeld: controleer een set documenten, voer een technische test uit, vergelijk outputs of verzamel gestructureerde informatie uit een gecontroleerde bron. Pas als die taak aantoonbaar waarde heeft, wordt het zinvol om de infrastructuur te verbreden.
Ook security hoort hier thuis. Een agent die kan browsen, downloaden en code uitvoeren, heeft grenzen nodig. Welke domeinen zijn toegestaan? Welke secrets zijn beschikbaar? Welke acties vragen menselijke goedkeuring? Welke bestanden mogen nooit worden gewijzigd? Een sandbox is pas waardevol als hij zowel vrijheid geeft om te werken als grenzen stelt om schade te voorkomen.
Praktisch besliskader voor AI-teams
Wie agent-compute wil beoordelen, kan beginnen met een nuchtere checklist. Eén: isolatie. Kan elke agenttaak draaien zonder andere taken of productiesystemen te beïnvloeden? Twee: state. Is duidelijk wat wordt bewaard, gewist of opnieuw gebruikt? Drie: startup. Kan een omgeving snel genoeg starten voor experimenten en evaluaties? Vier: logging. Kun je achteraf zien wat de agent deed? Vijf: resource-limieten. Kun je voorkomen dat een taak onbeperkt tijd, CPU, geheugen of netwerk gebruikt?
Daarna volgen de organisatorische vragen. Wie mag agenttaken starten? Wie beoordeelt uitkomsten? Welke taken zijn geschikt voor autonomie en welke blijven advieswerk? Hoe worden fouten vastgelegd? Wanneer wordt een agentworkflow stopgezet omdat de beheerlast groter is dan de opbrengst? Deze vragen klinken minder spannend dan autonome agents, maar ze bepalen of een team verantwoord kan opschalen.
De beste start is meestal klein. Kies één taak die vaak terugkomt, duidelijke input heeft en achteraf controleerbaar is. Bouw daarvoor een afgebakende omgeving met logging, cleanup en evaluatie. Meet niet alleen of de agent het één keer kan, maar of het proces herhaalbaar genoeg is om op te vertrouwen. Pas daarna wordt de vraag relevant welke infrastructuur je standaardiseert. Zo voorkom je dat agentontwikkeling blijft hangen in losse experimenten, maar voorkom je ook dat je te vroeg een platform bouwt voor werk dat nog niet scherp genoeg is gedefinieerd.
