AI-agent prijzen: waarom we vaste contracten schrappen

Het contract was drie pagina's en zag er strak uit. Discovery, build, launch, twee weken bugs fixen, oplevering. Vaste prijs, betaalbaar in drie tranches. We hadden veertien websites op dit sjabloon opgeleverd en ze waren allemaal in de plus geëindigd.

Dit was een chat agent voor een Nederlandse veerdienst. Acht weken later waren we voorbij oplevering, het model was halverwege het project uitgefaseerd, de klant had een edge case voor het refundbeleid toegevoegd die niemand in de scope had genoemd, en de timeout op de booking-API at tien procent van de gesprekken op. We hielden ons aan de prijs. We verloren veertig uur senior tijd. De klant was dolblij. Wij niet.

Dat was project drie van 2025. Bij project zes schreven we geen vaste prijscontracten meer voor iets dat een klant raakt via chat, voice of e-mail.

Klantgerichte agenten zijn geen websites

Een website gaat live en blijft daarna grotendeels staan. Copy wordt aangepast, een sectie komt erbij, maar de hoeveelheid 'wat er mis kan gaan' wordt begrensd door de pagina's die je hebt gebouwd. Je kunt het scopen.

Een klantgerichte agent heeft drie eigenschappen waar vaste prijscontracten niet tegen bestand zijn.

Het model beweegt onder je voeten. Tussen januari en november 2025 leverden we op vier verschillende Claude-versies en drie OpenAI-versies. Elke migratie betekende prompts herschrijven die weken hadden gekost om te kalibreren. Anthropic publiceert een uitfaseringsschema, en daar wordt zich aan gehouden, maar een venster van twaalf maanden blijft een venster van twaalf maanden. Je contract loopt zes.

De randgevallen zijn oneindig. Een boekingsflow heeft, royaal geteld, twintig benoemde states. Een klant die een vraag typt heeft er nul. Elke week brengt een soort input die niemand had ingeschat. 'Mag ik mijn hond meenemen als hij in een bench zit maar de bench staat in de auto?' was een echte vraag bij de veerdienst. De agent moest het leren.

Vertrouwen bouw je na de lancering, niet bij de lancering. De eerste maand van een live agent is de enige maand die telt voor toon, escalatie en hoe de agent vragen weigert. Dat is precies het moment waarop vaste prijscontracten al zijn uitbetaald en het team is doorgeschoven.

Model één: vaste prijs per milestone

Dit probeerden we als eerste, op drie van de zes projecten. Verdeel het werk in discovery, build, integratie en stabilisatie. Factureer aan het einde van elke fase.

Het voelt veilig. Het is niet veilig. De eenheid waar je voor factureert ('integratie klaar') is geen ding dat je objectief kunt meten bij een agent. Klaar volgens spec, prima. Klaar tegen het echte gedrag van klanten, nee. Bij de veerdienst haalden we oplevering op alle drie de milestones. De agent hallucineerde in week tien nog steeds refundbedragen.

Vaste milestones zetten ook het verkeerde werk vooraan. Discovery wordt een papieren exercitie omdat je de agent nog niet kunt zien. De echte spec komt in week drie boven als je je eerste honderd transcripten leest. Tegen die tijd is het contract al getekend.

Model twee: prijs per opgelost gesprek

Dit testten we op twee projecten. €0,40 per opgelost gesprek, €0 per escalatie. De pitch is moeilijk te weigeren: de klant betaalt alleen voor waarde, we zijn aligned op kwaliteit.

De pitch verbergt drie problemen.

Ten eerste: 'opgelost' is een label dat de agent zichzelf toekent. We probeerden menselijke review, sampling en downstream-signaal (mailde de klant binnen 48 uur opnieuw?). Alle drie waren te verdedigen. Geen ervan was goedkoop. De labelingkosten op één project waren achttien procent van de regel.

Ten tweede: de unit economics zijn meedogenloos aan het begin. De eerste duizend gesprekken bevatten de prompt-herschrijvingen, de hallucinatiepatches en de gotcha-fixes. Per gesprek factureren betekent dat je dat allemaal voor eigen rekening neemt voordat er omzet binnenkomt. We rekenden het door op project vijf en zagen dat we zeventien weken live traffic nodig hadden om alleen al uit te komen op het prompt engineering werk.

Ten derde: klanten haten het. Niet het model zelf. De factuur. Een rekening die maand op maand dertig procent fluctueert, gekoppeld aan traffic die ze niet direct kunnen sturen, geeft meer wrijving op de financiële afdeling dan de besparing rechtvaardigt. Twee klanten vroegen binnen zestig dagen om terug te gaan naar een vast tarief.

Model drie: wekelijkse retainer met een cap

Dit is waar we op zijn uitgekomen, en wat draait op alle vier de agenten die we in Q4 hebben opgeleverd. De structuur is klein.

Een vaste wekelijkse retainer dekt het lopende werk: prompt-iteratie, transcriptreview, integratiepatches, modelmigraties. Een cap op uren per week, vooraf afgesproken, waarboven we ofwel heronderhandelen of doorschuiven naar de volgende sprint. Een aparte eenmalige fee dekt de initiële build, met als scope 'eerste versie live op staging'.

Drie dingen die dit oplost.

De cadans past bij het werk. Klantgerichte agenten veranderen wekelijks omdat klantgedrag wekelijks verandert. Een wekelijks factuurritme maakt dat zichtbaar voor de financiële afdeling van de klant in plaats van het te verstoppen in een nieuwe vaste prijsofferte per kwartaal.

De cap beschermt beide kanten. Zonder cap glijden retainerafspraken af naar 'we zijn altijd beschikbaar', wat voor ons niet rendabel is en bij de klant passieve afhankelijkheid creëert. Met een cap heeft elke partij een echt getal om mee terug te duwen wanneer de scope kruipt.

De build-fee dekt de build. De initiële opzet is echt vaste prijswerk: infrastructuur aanleggen, de system prompt schrijven, de booking-API integreren, naar staging brengen. Dat deel vast prijzen is eerlijk. De volgende twaalf maanden klantcontact vast prijzen is dat niet.

Hoe het contract er nu uitziet

Twee pagina's. Drie getallen: build-fee, weektarief, urencap per week. Twee clausules: wat er gebeurt als we de cap raken (doorgeschoven, opnieuw onderhandeld of geëscaleerd), en wat er gebeurt als het onderliggende model wordt uitgefaseerd (gedekt onder de retainer, geen aparte change order).

De vorm hebben we geleend van de Shape Up-aanpak van Basecamp voor begrensd werk, al cappen wij de week in plaats van de cyclus. Klanten die tekenen zijn meestal de klanten die al snappen dat een agent software in productie is, niet software die je oplevert en afsluit.

Een patroon dat we breder zien

Het patroon is niet uniek voor ons. Elke studio die in 2025 productieagenten opleverde heeft hetzelfde experiment gedaan, in een of andere volgorde. We publiceren het resultaat omdat het vaste prijscontract voor een agent veruit de meest voorkomende reden is waarom we andere bureaus stilletjes zien stoppen met agentwerk na één of twee projecten. De economics breken, de klantrelatie verzuurt, en het team concludeert 'agenten zijn niets voor ons'. Het lag aan de prijsstelling, niet aan de agenten.

Toen we de veerdienst-agent onder de nieuwe structuur opnieuw bouwden, liepen we ertegenaan dat financiële afdelingen de cap-clausule twee keer uitgelegd wilden hebben voordat ze tekenden. We hebben dat opgelost door bovenaan het contract een korte samenvatting in gewone taal te zetten. Het werk zelf gaat beter, sneller en op een marge die we kunnen verdedigen. Ben je nu klantgerichte AI-agenten aan het scopen, dan is dit het stuk dat meer uitmaakt dan welk model je kiest.

Een audit van vijf minuten

Open het laatste contract dat je tekende voor een AI-agent. Zoek de sectie die regelt wat er gebeurt als het onderliggende model wordt uitgefaseerd. Staat dat er niet, of zit het verstopt in een algemene 'change order'-clausule, dan draag je het uitfaseringsrisico zelf. Dat is het kleinste wat je deze week kunt oplossen.