De rekening van agent-native

OpenAI verandert vanaf 31 maart 2026 de meeteenheid van zijn agent-containers. Tot dan werden die per memory-tier geprijsd, drie cent per gigabyte. Vanaf 31 maart worden ze geprijsd per sessie van twintig minuten, met een eigen teller naast het model. Google kondigde twee weken eerder project-level spending-caps aan in AI Studio, en handhaaft vanaf 1 april maandlimieten per tier. Gemini biedt daarnaast Flex- en Priority-tiers, prijsvarianten op dezelfde inference-meter. Anthropic rekent web search los van tokens, tegen tien dollar per duizend calls, en laat Managed Agents lopen op tokens én op sessieruntime.

Drie labs, drie verschillende ingangen, hetzelfde patroon. De rekening van een agent is geen nummer meer. Het is een stapel.

Dat is geen pricing-detail. Agent-native software arriveert niet als een UX-upgrade bovenop klassieke apps. Ze arriveert als software met een eigen kostenarchitectuur, en die architectuur is elke maand zichtbaarder in de API-docs.

Of die stapel het eindstation is, weet niemand. Pricing-modellen zijn historisch volatiel, CDN’s, storage, serverless hebben hun metertjes meermaals opnieuw getekend. Wat nu gebeurt kan een tussenfase zijn. Over twee jaar kunnen we terug zijn bij platte abonnementen per agent. De vorm van de rekening verandert waarschijnlijk nog. Anthropic ruilde zijn code-execution container-hours recent al in voor sessieruntime op Managed Agents, zelfde soort meter onder een andere noemer. Het bestáán van een meervoudige rekening is wat het betoog hierna aanneemt, en dat aannemen vraagt één voetnoot eerlijkheid.

Wat agent-native software is

Een korte herijking, want het woord wordt te losjes gebruikt.

Klassieke software zet elke stap via de gebruiker. Je klikt, navigeert, vult in, bevestigt. De machine wacht. AI-ondersteunde software voegt daar een adviseur aan toe. Je krijgt een suggestie, een samenvatting, een concept. Je blijft zelf handelen. De machine reikt aan.

Agent-native software is iets anders. Je geeft een opdracht, en het systeem voert die zelf uit. Het breekt de opdracht in stappen, roept tools aan, weegt tussenuitkomsten, beslist wat het vervolgens doet. Waar klassieke software reageert en AI-ondersteund adviseert, daar handelt een agent binnen de opdracht die je hem meegaf.

Klinkt als een gradueel verschil, is een verschuiving in waar de kosten zitten. In klassieke software zijn de bouwkosten hoog en de gebruikskosten laag. Je bouwt een knop een keer, daarna kost elke klik bijna niets. In agent-native software kantelt die verhouding. De bouwkosten kunnen laag zijn omdat veel werk verschuift naar prompts, tools en orchestratie. De gebruikskosten lopen op, omdat elke uitvoering rekent. Modelgebruik, vijf tot twintig tool calls per taak, controlelagen, logging, fallbacks. Elk van die dingen verbrandt iets. En elk van die dingen verschijnt inmiddels als aparte regel op de factuur van de lab.

Het patroon onder de drie labs

OpenAI heeft zijn pricing opgesplitst in meerdere assen. Flex processing en Priority processing zijn prijsvarianten op de bestaande tokenmeter, geen aparte meter. Web search staat wél los, gemeterd op tien dollar per duizend calls, apart van het model. Containers sinds 31 maart als kortdurende sessies, twintig minuten per stuk, met een eigen teller. De echte stapel bij OpenAI is tokens, web search en containers.

Google doet hetzelfde van de andere kant. Gemini heeft maandlimieten voor uitgaven op project- en tier-niveau. Flex inference en Priority inference zijn geen marketingnamen, het zijn expliciete optimalisatielagen in de Gemini-docs, beschikbaar vanaf 1 april 2026. Vertex AI meet grounding apart, op vijfenveertig dollar per duizend grounded prompts in de enterprise-variant.

Anthropic bevestigt het van de derde kant, met een sobere lijst. Tool use voegt extra system-prompt tokens toe. Web search kost tien dollar per duizend calls, bovenop de standaardtokens. Computer use heeft een eigen token-overhead. Claude Managed Agents rekenen op tokens én op sessieruntime. Prompt caching en batch processing, de mechanismen om kosten te beheersen, zijn geen fine print. Ze zijn een hoofdstuk op zich.

Agentisch gebruik is niet meer één modelcall. Het is een gestapelde runtime met aparte meters voor latentie, tools, execution-omgeving en retrieval.

De misvatting die veel teams nog maken

Vraag iemand die een agent-feature in zijn product plakt wat dat architectonisch betekent, en je krijgt meestal een antwoord in termen van capability. De agent kan nu ook tool X aanroepen. De agent kan nu zelf beslissen. De agent kan een formulier invullen. Een uitbreiding van wat de software al deed.

Dat werkt in een demo. Eén gebruiker, één taak, genoeg tokens in de buffer. Onder productiebelasting stort dat frame in. Tien duizend gebruikers, honderd agents per dag per gebruiker, elk agent-run een stapel van tool calls. Je hebt geen feature gebouwd. Je hebt een nieuwe categorie rekening onder je product gelegd, met een unit-economie die niet op de unit-economie van je oude software lijkt.

De misvatting zit in één woord: bovenop. Alsof je agent-native kunt toevoegen als laag, zonder de lagen eronder te herzien.

Dat een agent-SDK technisch op je bestaande backend past, klopt. Dat je daarmee een agent-native product hebt, klopt niet. Je hebt een agent-schil om klassieke software. Die schil werkt tot hij moet opschalen, en dan terug naar de tekentafel.

Bouwen wordt gelijker, aanbieden niet

Er is veel geschreven over hoe AI het maken van software democratiseert. Ideeën komen sneller in werkende systemen. Kleine teams bouwen wat een paar jaar geleden een volledig development-team vroeg. Solo builders leveren prototypes die eerder buiten bereik lagen. Die democratisering is echt. De drempel om te bouwen is omlaag.

Wat minder besproken wordt: die democratisering stopt bij de bouwlaag. Wie iets gemaakt heeft, moet het vervolgens aanbieden. Daar begint een ander economisch regime.

Bij klassieke SaaS lag het zwaartepunt aan de voorkant. Basecamp, Linear, Notion, een paar maanden tot jaren ontwikkelwerk, daarna distributie waarbij een extra gebruiker bijna niets kostte. Dat maakte ruimte voor kleine spelers. Niet alleen om iets te bouwen, ook om er een bedrijf op te bouwen. Schaal werkte in hun voordeel.

Bij agent-native software werkt schaal anders. Elke gebruiker brengt zijn eigen stack van inference-calls mee. Een power user die per dag tien agents draait verbruikt meer dan een casual user die er één per week aantikt, soms met een factor honderd. De unit-economie die klassieke SaaS maakte kleine bouwers rendabel werkt hier niet vanzelf. Je hebt een product dat goedkoper is om te maken, en duurder om te draaien.

Een technisch uitweg bestaat: bring your own key. Laat de gebruiker zelf zijn API-account meenemen. Voor developers en technische power users is dat een elegant model. Cursor begon zo, al faseert het BYOK sinds eind 2025 juist uit voor zijn kernfeatures. Zed AI doet het nog, Raycast AI biedt het als optie. En elk van die producten heeft intussen ook een tier toegevoegd waarin de aanbieder de rekening draagt. BYOK is geen massamodel. De gemiddelde eindgebruiker wil geen keys beheren, geen token-verbruik monitoren, geen tweede relatie aangaan met OpenAI of Anthropic. Hij wil een product. Voorspelbaar, eenvoudig, één prijs.

Wie die prijs wél kan opvangen, heeft structureel voordeel. Een grote softwarespeler voegt AI toe aan een bestaand productpakket met bestaande marges. Hij absorbeert inference-kosten in zijn bestaande P&L, verrekent ze over bestaande klantrelaties, kruissubsidieert ze met producten die al winst maken. Een kleine aanbieder moet zijn volledige business-model op die kosten stellen. Dat verschil zit niet in technologie, het zit in financieringscapaciteit. En het wordt zichtbaarder naarmate agents meer werk gaan doen.

Dat is de spanning onder de democratisering. Software bouwen wordt breder toegankelijk. Software aanbieden op schaal wordt het tegenovergestelde. Kleine spelers kunnen nog steeds, het wordt moeilijker, met minder vanzelfsprekende winstmarges dan klassieke SaaS bood.

De echte tegenwerping

De scherpste criticus van dit betoog zegt niet dat agent-native overschat is. Hij zegt dat ik met het verkeerde rekenmodel kijk.

Zijn argument loopt zo. Beoordeel een agent-call op waarde per afgeronde taak. Kosten per uitvoering is het verkeerde meetpunt. Een agent die in zestig seconden tien contracten leest en drie tegenstrijdigheden vindt, doet werk waar een jurist uren aan besteedt. Tachtig cent runtime voor wat anders tachtig euro menselijk werk kost, dat is geen kostenprobleem. De thesis verwart input-kosten met output-economie.

Die kritiek klopt, en ze scherpt mijn punt aan.

Agent-native is niet per definitie duur. Agent-native heeft ongelijk verdeelde waarde. Sommige stappen in een workflow rechtvaardigen dure intelligentie ruimschoots. Andere lossen prima op met een regel code, een regex, of een lookup. De ontwerpvraag wordt daardoor preciezer. Niet: kan een agent dit doen? Wel: waar levert een agent genoeg waarde om de runtime-, governance- en foutkosten te dragen? Die vraag stel je per stap, niet per product.

Wat open-weight en compliance eraan veranderen

Eén spanning voel ik zelf. Dit betoog mag niet hangen aan de prijslijst van OpenAI, Google en Anthropic. Voor een Nederlandse lezer die bouwt, is self-hosting op eigen GPU-cluster of via een Europese provider geen randgeval. Het is vaak de hoofdroute. Zeker in semi-publieke hoek, gemeenten, zorg, onderwijs, waar data-residency en verwerkersovereenkomsten onder AVG eerder een blokkade zijn dan een preferentie.

Verandert self-hosting het economische punt? De vorm van de rekening wel, het bestaan niet. Variable-per-call schuift naar mostly-fixed-plus-marginal. Je betaalt vooraf voor compute-capaciteit, en betaalt daarna de marginale kost van orchestratie, latentie, operations. Dat is een ander product-economisch regime. Het maakt budget-voorspelbaar. Het maakt de schaalgrens abrupter, je zit onder je capaciteit, of je zit eroverheen en moet bijkopen.

De AVG-dimensie maakt het zwaarder. Een call naar een Amerikaanse frontier-lab die persoonsgegevens raakt vraagt een doorgifte-grondslag die sinds het Schrems II-arrest niet langer vanzelfsprekend is. Het EU-US Data Privacy Framework van 2023 biedt een opvolger, maar juridisch breekbaar, niet het soort fundament waar je een langlopend product op bouwt. Voor een Nederlandse productbouwer is de keuze tussen frontier-API en self-hosting daarom niet alleen een prijsvraag. Het is een juridische keuze die het product fundamenteel vormgeeft.

Op beide regimes blijft het centrale feit staan. Intelligentie tijdens gebruik is een productvariabele, geen infrastructuurdetail. De locatie van de factuur verandert. Het bestaan van een factuur verandert niet.

Wat dit betekent voor ontwerpers

De UI-ontwerper van vijftien jaar geleden dacht in flows, schermen, knoppen. Die vragen blijven bestaan. Ze zijn niet meer genoeg.

De ontwerper die nu agent-native software bouwt moet vier vragen beantwoorden, per stap in een workflow, niet per product.

Wat mag de agent doen? Niet wat hij technisch kan. Waar is hij bevoegd binnen deze stap. Welke tools, welke acties, welke data. Alles erbuiten is gesloten.

Hoe lang mag hij bezig zijn? Een tijdsbudget per taak. Een container van twintig minuten is een ontwerpkeuze, geen technisch detail. Te kort, werk wordt onafgemaakt. Te lang, je betaalt voor een agent in een loop.

Onder welke grenzen? Rate limits, spend caps, auditregels, fallbacks. Wat gebeurt er als een tool call faalt. Wat gebeurt er als de uitkomst niet controleerbaar is. Welke menselijke handtekening hoort bij welke actie. En, voor Nederlandse bouwers, welke data mag hem überhaupt passeren.

Tegen welke prijs? Niet alleen de API-factuur. De kosten van controlelagen, logging, orchestratie, en menselijke tijd om fouten te reviewen. Het totale bedrag dat deze stap elke uitvoering kost.

Dat zijn geen vier policy-vinkjes. Dat is een besliskader dat je per interactie opnieuw invult, omdat elke interactie een andere balans tussen waarde en kosten heeft. Een dropdown hoeft geen agent. Tien contracten doorploegen op tegenstrijdigheden hoort er wel een te zijn. De volgende stap in dezelfde workflow kan weer deterministisch zijn.

Hybride wordt de norm. Goedkope deterministische lagen voor voorspelbaar werk, lichte modellen voor routinebeslissingen, zware modellen alleen waar echt redeneerkracht nodig is. Het routeren tussen die lagen is zelf een ontwerpdiscipline, en die staat nog in de kinderschoenen.

De laag boven de meter

Wie de rekening betaalt, bepaalt uiteindelijk wie kiest. Als gebruikers niet zien wat een agent-actie kost, ontstaat een prikkel om alles agent-native te doen. Het voelt als een gratis capability-upgrade. De rekening komt later, bij de CFO, bij de schaalgrens, bij de compliance-officer. In de komende een tot twee jaar gaan teams tegen muren lopen die hun agent-architectuur niet kan rondrekenen of niet kan verantwoorden. Dat is geen ramp, dat is marktvolwassenheid. Maar het komt.

De winnaars worden niet de teams met de indrukwekkendste demo’s. Het worden de teams die scherp kiezen waar een agent wel en waar hij niet mag meedoen, en die die keuzes vastleggen op een plek waar ze doorwerken in de uitvoering.

Dat laatste is de open vraag. De vier antwoorden, wat, hoe lang, onder welke grenzen, tegen welke prijs, zijn nu nog meestal impliciet, verspreid over code, config, prompts en policy-documenten. Dat werkt niet als je ze per interactie opnieuw moet invullen. Er hoort een laag bij boven de meter, waarin de intentie van de ontwerper toetsbaar is vastgelegd, onafhankelijk van het model eronder. Hoe die laag eruitziet, is nog niet uitgekristalliseerd. Dat de laag er komt, lijkt me onvermijdelijk.

Voor kleine bouwers is die laag geen luxe, hij is existentieel. Zonder expliciete besliskaders per stap wordt elke agent-feature een open rekening. Met zulke kaders blijft ruimte voor indie-builders om producten te maken die ook bij productiebelasting rendabel blijven, en die niet automatisch de waarde terugkoppelen aan de grootste spelers die inference-kosten kunnen opvangen in een bestaande P&L.

De oude ontwerpvraag luidde: wat kan de software? Die vraag staat niet op de voorgrond meer. De nieuwe vraag is anders. Wat mag het. Hoe lang. Onder welke grenzen. Tegen welke prijs.

Wie dat als ontwerpdiscipline behandelt, bouwt producten die productiebelasting overleven, ongeacht hoe groot de speler erachter is. Wie het blijft zien als een feature-laag, bouwt demo’s.

Dat verschil wordt de komende twee jaar zichtbaar.