Wat AI-agents echt van infrastructuur nodig hebben: 7 eisen, en waar hosting voor mensen in de weg zit

De meeste hosting is ontworpen rond een mens achter het toetsenbord: een aanmeldformulier, een creditcard, een dashboard, een e-mail als er iets misgaat. Een AI-agent die rekenkracht nodig heeft, past in geen van die stappen. Hij lost geen captcha op, ziet het verschil niet tussen een onderhoudspagina en een kapotte, en merkt niet dat hij dezelfde server veertig keer heeft aangemaakt.

Het is verleidelijk om te zeggen „geef hem gewoon een API”. Dat is de eerste eis, niet de laatste. Hieronder staan er zeven die we belangrijk vinden, op basis van het bouwen van onze eigen MCP-server en REST API voor agents. Bij elke eis: wat er misgaat zonder.

1. Alles wat een agent nodig heeft, is programmeerbaar

Resources aanmaken, inspecteren, schalen en verwijderen moet zonder browser werken. Inclusief de saaie delen: de prijs kennen vóór de aankoop, controleren of een locatie capaciteit heeft, het wachtwoord van een nieuwe machine uitlezen, opzeggen.

Zonder dit: de agent komt 80% van de weg en blijft hangen bij de ene stap die een klik vraagt, en een mens moet het werk alsnog afmaken. Een halve API is vaak erger dan geen, omdat hij uitnodigt tot automatisering die niet kan afronden.

2. Fouten waarop een programma kan handelen

Een agent leest een antwoord en beslist wat de volgende stap is. Een JSON-body met een stabiele code (402 insufficient_balance, 409 sandbox_paused, 429 budget_exceeded met het tijdstip van resetten) is iets waarop hij kan vertakken. Een HTML-foutpagina, of een 500 met een vaag bericht, laat hem gissen — vaak opnieuw proberen wat nooit gaat lukken.

Zonder dit: herhaallussen. De duurste mislukkingen van agents zijn meestal geen verkeerde beslissingen, maar dezelfde mislukte aanroep die duizenden keren wordt herhaald.

3. Betalen zonder mens in de lus

Kaartbetalingen zitten vol stappen die moeten bevestigen dat er een mens aanwezig is: 3-D Secure-codes, bevestigingen in de bankapp, identiteitscontroles. Die zijn goed tegen fraude en onmogelijk voor software. Een prepaid tegoed, vooraf opgewaardeerd (bij ons vaak met stablecoins), laat een agent betalen voor wat hij gebruikt zonder dat een mens elke afschrijving goedkeurt.

Zonder dit: óf een mens keurt elke aankoop goed, wat het doel tenietdoet, óf iemand geeft een agent een creditcard, een risico dat niemand zou moeten nemen.

4. Harde uitgavenlimieten

Een prepaid tegoed beperkt het slechtste geval tot wat erop staat. Dat kan nog steeds veel zijn. Een dag- en maandlimiet in dollars, afgedwongen door het platform in plaats van door de goede bedoelingen van de agent, maakt van een agent in een lus een klein verlies. De limiet moet luid falen, met een fout die de agent herkent, en stoppen of pauzeren wat er draait.

Zonder dit: je ontdekt de lus via het tegoed. Onze sandboxfacturering heeft daarom limieten, en de pagina MCP-beveiligingen stelt voor welke acties überhaupt goedkeuring van een mens zouden moeten vragen.

5. Rekenkracht met de juiste korrel

Agents leveren drie heel verschillende soorten werk:

• Seconden: een gegenereerd fragment draaien, een antwoord controleren, een fix proberen.
• Uren: een evaluatie, een scrape, een lange build.
• Altijd aan: een bot, een API, een geplande worker.

Een platform dat alleen maandservers biedt, maakt de eerste soort absurd duur; een platform dat alleen kortstondige sandboxes biedt, maakt de derde fragiel. Een taak van 20 seconden op een machine die per uur wordt gefactureerd, betaalt 59 minuten niets. Hoe facturering per seconde werkt laat zien waar elk model geen zin meer heeft.

Zonder dit: agents betalen te veel voor kort werk of draaien langlopende diensten op infrastructuur die niet bedoeld was om aan te blijven.

6. Standaard isolatie

Code die een agent schrijft, is code die niemand heeft nagekeken. Die hoort te draaien waar niets van waarde staat: niet op de host van de agent, niet op een server met je sleutels, niet op de machine die je mail verstuurt. In de praktijk betekent dat een aparte VM of microVM per taak, daarna verwijderd. Isolatieniveaus voor onbetrouwbare code vergelijkt de opties; Firecracker-microVM's uitgelegd laat zien waarom een eigen kernel telt.

Zonder dit: de eerste prompt injection die in gegenereerde code terechtkomt, heeft toegang tot alles wat de host van de agent kan bereiken.

7. Zicht en een uitknop

De mens die verantwoordelijk is voor een agent moet kunnen zien wat die deed en hem snel stoppen. Dat betekent gebruik en kosten per resource, een lijst van alles wat de agent aanmaakte en een manier om dat allemaal te verwijderen. Inloggegevens moeten intrekbaar zijn en kort genoeg geldig dat een gelekt token niet eeuwig werkt, met een manier om ze te vernieuwen zonder mens.

Zonder dit: opruimen wordt archeologie. Vergeten resources blijven factureren; een gelekt token blijft werken.

Wat agents niet nodig hebben

Even veelzeggend is wat niet helpt: dashboards gemaakt om bij te verkopen, onboardingmails, tarieven waarvan de echte grenzen in een voetnoot staan, prijzen die pas na aanmelding verschijnen. Niets daarvan is leesbaar voor software, en een deel ervan misleidt actief een model dat tekst letterlijk neemt.

Wat nog onopgelost is

Niet alles hier is een opgelost technisch probleem.

• Verantwoordelijkheid. Iemand is verantwoordelijk voor wat een agent met een account doet. Platforms hebben een manier nodig om geautomatiseerde activiteit aan een verantwoordelijke persoon te koppelen zonder die persoon door elke stap te sturen.
• Misbruik. Open, volledig geautomatiseerde aanmelding is precies wat misbruikers ook willen. Elk platform dat agents bedient, balanceert wrijvingsloze toegang tegen accountfarms en mining, en geen enkel platform heeft een perfect antwoord.
• Lange processen. Agents mislukken nog vaker op processen van tien stappen dan op losse aanroepen. Infrastructuur kan helpen door elke stap idempotent te maken en de status ervan makkelijk opvraagbaar, zodat een nieuwe poging verdergaat in plaats van dupliceert.

Waar wij zijn uitgekomen

We hebben geprobeerd voor deze eisen te bouwen in plaats van eromheen: een MCP-server en REST API voor de hele levenscyclus, machineleesbare fouten, een prepaid tegoed, uitgavenlimieten, code-sandboxes per seconde voor kort werk en maandservers zoals het tarief AI agent voor lang werk. Een doorloop van de sandboxkant staat in sandbox voor AI-agents. Beoordeel de lijst wel op zijn eigen merites: het is een handige checklist voor elk platform waarop je een agent loslaat.