Un agente di supporto ha bruciato 10.000$ in 72 ore
8:17 del mattino, lunedì, San Francisco. Jake, CTO di una startup SaaS da 12 persone, apre l'email. Gli si gela lo stomaco.
Nel weekend—72 ore offline, in escursione con il partner—l'agente di supporto clienti ha bruciato 10.237$ in chiamate API. Diecimila dollari. Tre giorni. Per uno strumento pensato per ridurre i costi del supporto.
Ho partecipato al post-mortem quel mercoledì. Non era negligenza. Avevano un budget mensile. Avevano scelto un modello "conveniente" tramite OpenRouter. Avevano aggiunto rate limit. L'agente ha superato ogni controllo. Quando qualcuno ha controllato, era finita.
Se stai costruendo o scalando agenti, non è raro. È normale. E senza le protezioni giuste, è una questione di quando, non di se.
Cosa è successo davvero
Il team di Jake ha costruito l'agente di supporto su AutoGPT, con OpenClaw per il routing e OpenRouter per l'accesso API. Gestiva ticket, recuperava dati ordini da Shopify, generava guide per la risoluzione dei problemi ed escalava i casi complessi.
Hanno impostato un budget mensile di 500$ in OpenRouter e un limite di 10 retry per chiamata a strumento. Sulla carta, coperti.
Hanno trascurato un dettaglio: i limiti erano per chiamata, non per workflow.
L'ordine di un cliente risultava consegnato ma non era mai arrivato. L'agente ha provato a recuperare i dati da Shopify. L'API ha fatto timeout. L'agente ha riprovato 10 volte, come configurato. Tutti falliti. Invece di escalare, ha riavviato l'intero workflow.
Ha ripetuto quel ciclo ogni 8 secondi per 72 ore. 1,2 milioni di token. 147.000 chiamate API. 10k$. Il 99,8% di quelle chiamate non ha risolto nulla. L'agente non ha chiuso un solo ticket.
Perché il controllo dei costi degli agenti è più difficile
Un chatbot ha token prevedibili per richiesta e inizio/fine chiari. Gli agenti decidono da soli. Chiamano strumenti, avviano workflow annidati, riprovano senza chiedere. Questa autonomia è il punto. È anche rischiosa.
Tre motivi per cui i normali strumenti di budget falliscono con gli agenti:
La logica di retry bypassa i rate limit
Gli agenti riprovano le chiamate a strumento fallite. Bene per l'affidabilità. Senza limiti rigidi per azione, workflow e ora, quella logica diventa un loop fuori controllo. Il team di Jake limitava i retry per chiamata ma non per workflow. Ogni 10 retry falliti, l'agente riavviava. Nessuno aveva aggiunto quella protezione.
Le chiamate annidate nascondono il costo reale
Una richiesta utente può scatenare molte chiamate: classifica → recupera dati → genera → controlla → rispondi. Aggiungi agenti annidati e ognuno ha le proprie chiamate e retry. Gli strumenti di costo base spesso non vedono o controllano l'intera cascata.
Lo spend fuori orario resta incontrollato
La maggior parte dei picchi avviene quando nessuno guarda. Notti, weekend. Il team di Jake non aveva alert in tempo reale. Hanno ricevuto un'email al 50% del budget mensile—a quel punto il loop aveva già bruciato 7k$.
Quattro lacune che la maggior parte dei team trascura
1. Uso illimitato degli strumenti
Ogni strumento è un potenziale loop. Lookup database, API, lettura file—se l'agente può chiamarlo un numero illimitato di volte, un errore può spirale. Fix: limiti rigidi per workflow, per ora, per giorno. Nessuna eccezione.
2. Nessun circuit breaker
Un circuit breaker ferma un workflow quando supera una soglia—errori, retry, spend. Esempio: più di 5 retry falliti → workflow si ferma, escalazione a umano. Pochi team li usano per gli agenti. Dovrebbero.
3. Nessun limite di budget per workflow
Un singolo cap mensile è inutile. Un loop può svuotarlo in ore. Ti servono limiti per workflow, per agente, per utente. Es: agente di supporto: max 50$/giorno. Lead gen: 100$/settimana. Singolo ticket: max 0,50$. Se un workflow va male, non può prendere tutto il budget.
4. Nessuna rilevazione di anomalie in tempo reale
Fermare un loop significa intercettarlo all'inizio. Se normalmente fai 10 chiamate/minuto e improvvisamente arrivi a 100, il sistema dovrebbe segnalarlo, avvisare e opzionalmente mettere in pausa. I report mensili sono troppo tardi.
Parte 2: Cinque passi per rendere i tuoi agenti a prova di proiettile →