Niemand merkte dat de AI agent geld uitgaf

De agent crashte niet, en hij gaf geen foutmelding. Hij bleef het hele weekend doorwerken, en de rekening bij de modelaanbieder bleef groeien tot iemand de factuur opende.

Eén modelaanroep kost weinig. Een agent doet veel aanroepen, en hij bepaalt tijdens de run hoeveel. Dat is het doel van een agent. Het is ook waar het geld naartoe gaat.

Drie patronen komen steeds terug als teams een onverwachte kostenpost beschrijven.

De lus. Een tool geeft een fout terug. De agent probeert het opnieuw en krijgt dezelfde fout. Hij probeert het nog een keer. Bij elke poging gaat het groeiende gesprek vaak opnieuw naar het model, dus latere pogingen kunnen meer kosten dan eerdere. Als dit op een vrijdagavond begint, is de eerste die het ziet misschien degene die de factuur leest.

De stille herhaalpoging. Een stap mislukt, en een instelling voor herhaalpogingen start die stap opnieuw vanaf het begin. In sommige opstellingen wordt de teller die de run zou moeten stoppen bij elke herstart op nul gezet. De run lijkt druk bezig. In zekere zin is hij dat ook.

De uitwaaiering. Een agent kan andere agents starten, en elk daarvan kan er weer meer starten. Niets in het ontwerp is fout. Maar niets erin zegt ook wanneer het moet stoppen.

De gemeenschappelijke oorzaak is geen slecht model. De agent geeft geld uit, en niemand buiten de agent bewaakt de limiet.

Als de rekening komt, toont die vaak een totaal per account of per sleutel. Er staat niet in welke workflow, welke run of welke stap het bedrag veroorzaakte. Een team dat veel agents op één sleutel draait, ziet het totaal stijgen en kan niet zeggen waarom.

Tracingtools helpen, omdat ze laten zien wat elke run deed. Maar vergelijk hun kostencijfers met de eigen rekening van de aanbieder. Een schatting in een dashboard is niet de factuur.

De vragen die u moet beantwoorden, zijn eenvoudig. Welke run kostte deze week het meest? Welke stap binnen die run? Was het een lus, een herhaalpoging, of gewoon werk dat nu eenmaal duur is? Als u die vragen niet kunt beantwoorden, kunt u de kosten niet aanpakken. U kunt er alleen over klagen.

De gebruikelijke reflex is om het kostenprobleem bij de afdeling Financiën neer te leggen. Financiën kan een budget vaststellen en een factuur lezen. Financiën kan niet zien dat een tool 's nachts begon te falen en dat een agent die tool sindsdien aanroept. De mensen die kunnen ingrijpen, zijn de mensen die de agents draaien.

Behandel de kosten van agents dus zoals beschikbaarheid of foutpercentage: iets wat beheer bewaakt, met een eigenaar en een vaste routine. Vier gewoonten maken dat werkbaar.

Weet van wie de sleutel is die betaalt. Elke modelaanroep gaat via een sleutel bij een aanbieder. Als dat één gedeelde sleutel voor alles is, of een sleutel in het account van iemand anders, ziet u de kosten laat, of alleen als een regel op de factuur van een andere partij. Een sleutel per team of per werklast maakt de rekening leesbaar.

Bekijk de kosten per run en per stap. De totale uitgaven vertellen u dat er een probleem is. De kosten per run vertellen u waar het zit. De kosten per stap vertellen u waarom.

Stel limieten in waar de uitgaven ontstaan. Een maandplafond bij de aanbieder beperkt de schade, maar grijpt laat in, en het stopt de goede runs samen met de slechte. Limieten dicht bij het werk grijpen eerder in: een maximumaantal stappen of tool calls per run, een teller voor herhaalpogingen die niet op nul wordt gezet, een maximumaantal agents dat één run mag starten, en een kostenplafond per run. Als een run een limiet bereikt, moet hij stoppen en dat melden, niet opnieuw beginnen. Test de limiet daarna bewust. Een limiet die het verkeerde telt, geeft u een gevoel van veiligheid en verder niets.

Bepaal wie kijkt, en hoe vaak. Een melding die niemand leest, is geen beheersmaatregel. Wijs een persoon aan. Spreek af hoe vaak die persoon de kosten per workflow bekijkt: dagelijks zolang een nieuwe agent nog jong is, wekelijks zodra die stabiel is. Spreek af wat een normale run kost, zodat een afwijkende run opvalt.

Niets hiervan is ingewikkeld. Het is de discipline die teams al toepassen op cloudservers, nu toegepast op een nieuw soort verbruiker. Het verschil is snelheid. Een server die te groot is, kost u langzaam geld. Een agent in een lus kost u snel geld.

Wijs één persoon aan die dit aan het eind van elke week doet.

1. Zoek de duurste run van deze week. Begin bij de rekening van de aanbieder en zoek daarna de run achter het totaal.
2. Zoek de stap binnen die run die de meeste tokens gebruikte.
3. Benoem de oorzaak: een lus, een herhaalpoging, of werk dat nu eenmaal duur is.
4. Controleer de limieten van die workflow: stappen, tool calls, herhaalpogingen en looptijd.
5. Stel een limiet in of verlaag die, en noteer wat een normale run kost, zodat een afwijkende run volgende vrijdag opvalt.

Wat EpicStaff u voor deze review geeft

AI-gebruik in EpicStaff draait op uw eigen sleutels bij de aanbieder, dus de rekening komt bij u en u kunt die bij uw aanbieder zien. EpicStaff legt vast hoeveel tokens elke run en elke agentstap gebruikte; het toont geen geldbedrag. U kunt beperken hoeveel stappen, tool calls en herhaalpogingen een agent elke keer dat hij draait mag gebruiken, en hoe lang een run mag duren. Als een run zijn token- of tijdslimiet bereikt, stopt EpicStaff de run; de reden wordt opgeslagen, maar het scherm toont niet altijd dat een limiet is bereikt. EpicStaff maakt alleen verbinding naar buiten met de aanbieders waarvoor u sleutels instelt. Tools doen wat u ze opdraagt: een tool die u bouwt of inschakelt en die het internet bereikt, is uw keuze en uw configuratie. EpicStaff beperkt niet hoeveel agents één run mag starten, dus tel bij het testen van de flow hoeveel agents een run start. EpicStaff stuurt niemand een melding als een run meer kost dan normaal, dus uw review op vrijdag is de controle.