AI-agentprijzen: wat reken je klanten?

Inhoudsopgave

Gepubliceerd in augustus 2026.

TL;DR: Beprijs een AI-agentbouw niet op uren. Splits het in twee aparte posten: een vaste bouwvergoeding voor het initiële systeem en een maandelijkse onderhoudsretainer om het draaiende te houden. De bouwvergoeding dekt ontwikkeling, testen en integratiewerk. De retainer bestaat omdat agents kapot gaan — prompts driften, API’s veranderen, edge cases duiken op — en “klaar” is geen echte staat voor iets dat een model aanraakt. Sla de retainer over en je doet binnen een maand gratis supportwerk.

[Operatorsperspectief] Ik beheer meer dan 30 agents in productie voor een consultingmerk en Pickleland, een pickleballlocatie in Pflugerville, TX, en ik heb bovenop die ervaring agentbouwwerk voor klanten beprijsd. De meest voorkomende fout die ik zie — bij freelancers én bureaus — is een AI-agent behandelen als een website: offreren, bouwen, opleveren, factuur volledig betaald. Agents zijn geen websites. Het zijn systemen die aandacht blijven vragen omdat de laag eronder (een model, een API, het werkproces van een klant) blijft veranderen. Beprijs die realiteit, of je betaalt de rekening zelf.

Waarom uurfacturering niet werkt voor agentwerk

Uurfacturering straft je voor sneller worden. Hoe meer agentbuilds je oplevert, hoe meer herbruikbare prompts, evals en scaffolding je opbouwt — en hoe sneller de volgende build gaat. Factureer je per uur, dan snijdt elke efficiëntiewinst in je factuur. Dat is achterstevoren.

Het straft ook de klant, in de andere richting. Een klant die iemand inhuurt voor een AI-agent heeft geen manier om te beoordelen of “12 uur” voor een workflow eerlijk, snel of opgeblazen is. Ze kopen een black box, geprijsd op een getal dat ze niet kunnen verifiëren. Die onzekerheid zorgt ervoor dat klanten afdingen, goedkeuring uitstellen, of de goedkoopste uuroffertes kiezen in plaats van de beste.

De oplossing is dezelfde als voor elk geproductiseerd aanbod: prijs op basis van gedefinieerde scope en resultaatwaarde, niet op tijd. Voor agentwerk betekent dat specifiek twee aparte, vastgeprijsde componenten — omdat een build en het onderhoud ervan echt verschillende producten zijn met verschillende kostenstructuren.

De tweedelige structuur: bouwvergoeding + onderhoudsretainer

1. Bouwvergoeding — een eenmalige, vaste prijs voor het ontwerpen, bouwen, testen en uitrollen van de agent. Eenmalig betaald, meestal in twee termijnen (aanbetaling bij start, saldo bij oplevering).

2. Onderhoudsretainer — een terugkerende maandelijkse vergoeding die start de maand na lancering. Dit dekt monitoring, promptfixes wanneer het model of een bovenliggende API verandert, en kleine scope-behoudende aanpassingen.

Deze twee bundelen tot één getal is de grootste prijsfout in deze niche. Een klant die maar één keer betaalt, heeft geen financiële reden om na oplevering nog iets te verwachten, en jij hebt geen financiële reden om een agent in de gaten te blijven houden waarvoor je een maand geleden bent betaald. Door ze te splitsen wordt de prikkel eerlijk: je wordt betaald om iets werkend te houden, dus houd je het werkend.

Dit sluit aan bij het framework dat ik gebruik om te beslissen of ik een automatisering überhaupt bouw — zie AI-agent ROI: is een automatisering het bouwen waard. Die post is geschreven vanuit het perspectief van de koper: hoe een bedrijf moet beoordelen of een agent zichzelf terugverdient. Deze post is de verkoperskant van dezelfde wiskunde — de bouwkosten en de onderhoudsbelasting uit dat framework zijn precies de twee dingen die je hier beprijst.

De bouwvergoeding dimensioneren

Dimensioneer de bouwvergoeding op scopeniveau, niet door uren te gokken. Drie niveaus dekken het meeste klantwerk:

Deze bereiken gaan uit van een gedefinieerde scopegrens, dezelfde discipline als beschreven in hoe je een geproductiseerde dienst bouwt: een schriftelijke lijst van wat inbegrepen is, een schriftelijke lijst van wat niet, en een vast aantal workflows of tool-integraties. Een klant die vraagt om “een AI-agent voor mijn bedrijf” zonder gedefinieerde workflow is nog niet klaar om een build te kopen — die is klaar voor een scopinggesprek, een apart, kleiner deliverable (ik prijs dat als een vast bedrag van $500–$1.000 voor een audit die het scopedocument oplevert waartegen de bouwvergoeding wordt geoffreerd).

Binnen elk niveau beweegt het uiteindelijke getal op drie punten: hoeveel verschillende tools de agent aanroept, hoeveel van het testen tegen echte, rommelige klantdata moet gebeuren in plaats van schone testcases, en hoe vergevingsgezind het faalmodel is. Een agent die een social post concept opstelt voor menselijke review mag af en toe fout zitten tegen lage kosten. Een agent die een bevestigingsmail verstuurt of geld verplaatst kan dat niet — en dat verandert het testbudget veel meer dan de code.

De onderhoudsretainer dimensioneren

Ik stel de retainer in als een percentage van de bouwvergoeding, niet als een vast bedrag, omdat onderhoudskosten schalen met systeemcomplexiteit op dezelfde manier als bouwkosten.

maintenance_retainer_per_month = build_fee × monthly_rate

monthly_rate:
  stable integrations, low API-change risk        → 3–5%
  volatile APIs (social platforms, scraped data)   → 6–10%
  multi-agent systems, custom eval suite to keep up → 8–12%

Voor een build van $6.000 op een redelijk stabiele stack is dat ongeveer $250–$400/maand. Dat getal moet nauw aansluiten bij de onderhoudsbelasting die ik toepas op mijn eigen automatiseringen — een vast tarief van 20% van de bouwkosten per jaar, wat aan de onderkant uitkomt op datzelfde bereik van 3–5% per maand. De klantgerichte retainer zit op dezelfde ordegrootte omdat de onderliggende kostenfactor — promptdrift, veranderingen in bovenliggende API’s, edge cases die na lancering opduiken — niet verandert alleen omdat iemand anders ervoor betaalt.

Wat de retainer expliciet niet dekt: nieuwe workflows, nieuwe integraties of scopewijzigingen. Dat zijn nieuwe bouwvergoedingsoffertes. Een retainer die stilzwijgend “kun je het ook deze andere case laten afhandelen” absorbeert, verandert binnen een kwartaal in onbetaald featurewerk — hetzelfde faalmodel als besproken in waarom geproductiseerde aanbiedingen een harde scopegrens nodig hebben, nu toegepast op lopend werk in plaats van de initiële build.

Anker de prijs aan wat het vervangt, niet aan wat het kost om te bouwen

De bouwvergoeding moet naar de klant toe niet gerechtvaardigd worden met je uren — maar met de handmatige kosten die ze wegneemt. Voer voor de offerte dezelfde berekening van handmatige kosten uit de ROI-methode uit, maar dan aan de kant van de klant:

manual_cost_per_year = time_per_instance × hourly_rate × frequency_per_year
                      + error_cost_per_year

Als het team van een klant 5 uur per week besteedt aan een taak die een agent kan doen, tegen een volledig belast uurtarief van $40, is dat $10.400/jaar aan handmatige kosten. Een bouwvergoeding van $6.000 met een retainer van $300/maand ($3.600/jaar) verdient zichzelf ruim binnen een jaar terug en blijft zich elk jaar daarna terugverdienen. Die vergelijking — handmatige kosten versus bouw-plus-retainerkosten — is de eigenlijke pitch. Leid elk voorstel daarmee in. Een prijs zonder vergelijkingspunt is gewoon een getal; een prijs naast wat hij vervangt, is een argument.

Dit stelt ook een natuurlijk plafond in: als de vervangen handmatige kosten klein zijn, moet de klant geen multi-agentsysteem van $15.000 kopen, en moet jij er ook geen aan hem verkopen. Het niveau afstemmen op de werkelijk verplaatste kosten is wat de prijsstelling in beide richtingen eerlijk houdt.

Contractvoorwaarden die scope creep voorkomen

Vier voorwaarden staan in elk agentbouwcontract dat ik schrijf, naast de prijs:

1. Een schriftelijke definitie van “klaar.” Specifieke testcases waar de agent aan moet voldoen voordat de eindbetaling verschuldigd is — niet “werkt goed”, maar een lijst: “classificeert correct 9 van de 10 voorbeeldleads uit de aangeleverde dataset”, “plaatst succesvol op de gekoppelde Facebookpagina zonder handmatige tussenkomst.” Vage acceptatiecriteria zijn de grootste bron van onbetaald extra werk.
2. Eigendomsvoorwaarden, helder benoemd. De klant bezit de workflowlogica en alle klantspecifieke data. Jij behoudt herbruikbare scaffolding, prompt-templates en eval-harnesses die niet specifiek zijn voor hun bedrijf — hetzelfde IP-hergebruikpunt als in leveringssystemen voor geproductiseerde diensten. Zeg dit vooraf; het voorkomt een ongemakkelijk gesprek later.
3. Een gedefinieerde afhandeling voor opzegging van de retainer. Als de klant het onderhoud opzegt, maak duidelijk wat er gebeurt: de agent blijft draaien zoals hij is zonder verdere fixes, of hij wordt na een opzegtermijn uitgeschakeld. Dit ongedefinieerd laten betekent dat jij verantwoordelijk blijft voor een systeem waar niemand je voor betaalt om het in de gaten te houden.
4. Change requests apart geprijsd, schriftelijk, vóór het werk begint. Niet “we zien wel” — een tarief of een minimum per verzoek, vastgelegd in het contract, zodat een scopewijziging van een klant niet elke keer een onderhandeling wordt.

De twee bezwaren die elke keer terugkomen

“Waarom kost het extra om iets te onderhouden dat al werkt?” Omdat “werkt” een momentopname is, geen staat. De modelleverancier kan het gedrag van een model afschaffen of veranderen, het platform waar de agent op post kan zijn API veranderen, en het bedrijf van de klant zelf kan de workflow veranderen waarrond de agent gebouwd is. Niets daarvan is een bug in wat je hebt opgeleverd — het is het normale verval van elk systeem dat verbonden is met externe, bewegende onderdelen. Ik omschrijf de retainer expliciet als verzekering tegen dat verval, niet als lopende “support” — support impliceert dat er iets kapot is; een retainer betekent dat iemand oplet voordat dat gebeurt.

“Kan ik niet gewoon een no-code tool gebruiken en de bouwvergoeding overslaan?” Soms wel — en dat zeg ik dan ook. Als de workflow echt eenvoudig is (één trigger, één actie, geen custom logica), is een no-code automatiseringsplatform het eerlijke antwoord en verwijs ik een klant daarnaartoe in plaats van een build te offreren. De bouwvergoeding is gerechtvaardigd wanneer er echte logica, integratiewerk of beoordeling bij komt kijken die een drag-and-drop tool niet kan uitdrukken. Het afwijzen van een niet-passende opdracht is wat de opdrachten die je wél aanneemt geloofwaardig maakt.

De tools die ik hiervoor gebruik

Notion — het scopedocument leeft hier: wat inbegrepen is, wat niet, de acceptatietestlijst en de eigendomsvoorwaarden, gedeeld met de klant voordat er een aanbetaling wordt geïncasseerd.

Airtable — één rij per actieve opdracht, met bouwstatus, retainer-factuurdatum en de laatste keer dat de output van elke agent is gecontroleerd.

Claude is waarop ik de meeste van deze agents bouw — de retainerprijzen hierboven gaan uit van een modelstack met redelijk stabiele prijzen en gedrag, wat de volatiliteitsaanname in de maandtarief-formule verandert als je bij een minder stabiele provider zit.

FAQ

Moet de aanbetaling 50% zijn, of iets anders?

50% bij start, 50% bij oplevering tegen de schriftelijke acceptatiecriteria is de eenvoudigste structuur en degene die ik standaard gebruik. Voor grotere multi-agentbuilds (het niveau van $15.000+) splits ik het in drieën: aanbetaling, een mijlpaalbetaling bij een werkend prototype, en het saldo bij oplevering — vooral om te voorkomen dat een grote eindfactuur terechtkomt bij een klant die halverwege het project stil is geworden.

Wat als de klant alleen voor onderhoud wil betalen, zonder dat ik de oorspronkelijke agent heb gebouwd?

Ik neem dit soort opdrachten aan, maar ik prijs de eerste maand hoger om een audit te dekken: de bestaande prompts en code doornemen, de acceptatietests draaien die ik zelf zou hebben geschreven, en documenteren wat ik vind. Je kunt niet verantwoord een onderhoudsretainer toezeggen op een systeem dat je niet zelf hebt gebouwd en niet hebt geverifieerd — de auditmaand is wat een onbekende omzet in een echt getal.

Hoe weet ik of mijn maandtarief-aanname (3–12%) te laag is?

Houd de werkelijke onderhoudsuren een kwartaal lang bij tegenover wat de retainer betaalde. Besteed je consequent meer tijd dan de retainer dekt, verhoog dan het tarief bij verlenging — absorbeer het niet stilzwijgend. De formule is een startpunt, gekalibreerd op dezelfde onderhoudsbelasting-logica die ik gebruik voor mijn eigen agents; je werkelijke API-wijzigingsfrequentie en de tolerantie van je klant voor edge cases zullen het bijstellen.

Heb ik een apart contract nodig voor het scopinggesprek?

Voor alles wat verder gaat dan een kort gesprek, ja — prijs de scopingaudit als eigen klein deliverable met een eigen schriftelijke output (het scopedocument), zelfs als je van plan bent de kosten ervan te verrekenen met de bouwvergoeding als de klant doorgaat. Dit voorkomt dat de scopingfase zelf onbetaald verkoopwerk wordt.

Volgende stappen: Mijn AI Agents for Beginners-cursus behandelt het bouwen van de agents waar dit prijsframework van uitgaat dat je die al kunt leveren. Het cowork-programma is voor operators die een gestructureerde omgeving willen om dit soort werk te bouwen en te beprijzen. Wil je liever eerst de audit en het scopedocument voor je laten bouwen, boek dan een sessie van 30 minuten.