In demo è gratis. In produzione parte il contatore
Un agente AI passa la demo sull'accuratezza. In produzione a decidere se sopravvive è il costo per pratica: token, tool call, retry e un loop che si può avvitare.
Quasi tutti i piloti di agenti AI passano la demo. Non è il segnale che il sistema è pronto: è il segnale che la demo era economica da far girare. Gira poche volte, sul percorso felice, con qualcuno pronto a correggere la rotta. Nessuno guarda il costo, perché su una manciata di esecuzioni il costo si arrotonda a zero. La produzione è l'opposto: lo stesso agente gira migliaia di volte al giorno, su input veri, senza nessuno nella stanza. E a quella scala a decidere se l'agente sopravvive non è l'accuratezza. È un numero che la demo non ha mai messo a schermo: il costo per pratica.
Cosa fa girare il contatore
Ogni passo di un agente è denaro. Ogni chiamata al modello sono token da pagare; ogni chiamata a un tool è tempo di calcolo e, spesso, un'altra API a consumo. Finché i passi sono pochi e prevedibili, il conto è banale. Ma un agente non è un percorso fisso: possiede il proprio flusso di controllo. Decide da solo quando ripianificare, quando richiamare un tool, quando riprovare. È esattamente ciò che lo rende utile, ed è anche ciò che trasforma il costo da riga di listino a variabile.
Un compito che sul percorso felice costa un centesimo, davanti a un input ambiguo può ripianificare tre volte, richiamare gli stessi tool, e in un caso limite entrare in un loop che si avvita finché qualcosa non lo ferma. Cento esecuzioni normali e una che va in loop possono pesare uguale. E a differenza di un processo che va in crash, un loop costoso non solleva un'eccezione: torna un risultato plausibile, ben formato, e prosegue. Il costo cresce in silenzio, che è il modo più pericoloso in cui un costo possa crescere.
Non è il modello, è l'ingegneria intorno
La parte rassicurante è che nessuna di queste cose riguarda l'accuratezza del modello, e nessuna richiede una svolta. È ingegneria ordinaria di sistemi distribuiti, la stessa disciplina che applicheresti a qualunque servizio che chiama altri servizi a consumo. Un budget per pratica, con un tetto rigido che ferma il loop invece di lasciarlo avvitare. Una cache su ciò che si ripete, perché ricalcolare la stessa risposta è costo puro. Il routing dei passi facili verso un modello più piccolo, tenendo quello costoso solo dove guadagna davvero il suo prezzo. E, sopra tutto, l'osservabilità: il loop va reso leggibile non solo nel suo esito ma nel suo consumo — quante chiamate, quali tool, quanti token, attribuiti alla singola pratica. Non puoi controllare un costo che non vedi, e quasi tutti strumentano la risposta lasciando al buio il contatore.
Il numero che conta è il costo per pratica riuscita
Per una software house .NET questo è un problema di margine prima che tecnico. In demo il costo non si vede, ma un contratto a prezzo fisso lo rende reale: se quoti un servizio senza sapere quanto costa farlo girare sotto carico, la variabile la assorbi tu. Il costo di esercizio va progettato prima del preventivo, non scoperto in fattura tre mesi dopo.
E la metrica onesta non è il costo medio: è il costo per pratica riuscita. Gli errori, i retry a vuoto e i loop che non portano a nulla vanno contati, perché sono ciò che separa un prodotto con un margine da una perdita lenta che sembra funzionare. L'accuratezza fa approvare l'agente nell'ultima riunione prima del lancio. Il costo per pratica riuscita decide se, sei mesi dopo, quell'agente è ancora in produzione — o se stava costando più della cosa che ha sostituito.
Se domani il vostro agente gestisse dieci volte il volume, sapreste dire quanto costa — o solo che funziona?