Un Runaway Agent Loop è un agente che entra in un ciclo senza fine – chiama uno strumento, non ottiene il risultato sperato, riprova, richiama, all'infinito – bruciando token e denaro (una bolletta API da migliaia di euro in una notte) o martellando un servizio esterno. È il denial-of-wallet degli agenti, spesso non malevolo ma dovuto a un obiettivo mal definito, un errore che non si risolve, o una prompt injection che lo manda fuori strada.
Le difese sono ingegneria di harness, non prompt:
- budget rigidi: tetto massimo di iterazioni, di token, di tempo, di costo per task – superato il quale l'agente si ferma, punto
- circuit breaker: rilevare le ripetizioni (la stessa azione con lo stesso risultato N volte) e interrompere – un agente che ripete non sta progredendo
- timeout e rate limit sui tool, così un loop non travolge i servizi a valle
- kill-switch e monitoraggio dei costi in tempo reale (observability) con alert sui picchi
- stato/checkpoint che rende visibile e interrompibile il progresso
È lo stesso principio del determinismo nell'impalcatura: i limiti di controllo (loop, budget, retry) vanno codificati nell'harness, non affidati al giudizio del modello – un agente non deve decidere di fermarsi, deve essere fermato quando supera i limiti. Un buon workflow ha sempre un tetto; un cattivo agente lo scopre a bolletta arrivata.