Long-running agents: l'autonomia lunga è meno nuova (e più fragile) di come la raccontano

"Un agente che ha lavorato per sette ore di fila, da solo." È il titolo che ho letto tre volte la settimana scorsa, con qualche variazione: undici giorni, settecentocinquantamila righe, duecento sessioni in autonomia, una migrazione bancaria chiusa mentre il team dormiva. Suona frontiera. Suona 2026.

Poi mi sono ricordato che il termostato di casa mia, settato su 20 gradi, "lavora da solo" da quando l'idraulico l'ha montato nel 2019. E che il pilota automatico di un Boeing tiene una rotta per dodici ore senza supervisione attiva. E che il primo testo formale che descrive un sistema "che mantiene uno stato target nel tempo, riceve segnali, corregge" è del 1948. Un libro di Norbert Wiener, scritto dopo aver provato ad abbattere aerei tedeschi con un calcolatore analogico che mancava il bersaglio.

Il pattern del loop autonomo che opera nel tempo non è una conquista del 2026. È una conquista del Novecento. Quello che è davvero nuovo è il controller — un LLM con varietà operativa abbastanza ampia da affrontare task non strutturati in linguaggio naturale. Con la novità, però, arrivano fragilità nuove, e chi parla di "agente per sette ore" tende a minimizzarle. Vediamole onestamente.

Cosa intendiamo per "long-running agent" oggi

Il termine è abusato. Conviene distinguere quattro casi, che si confondono spesso nelle presentazioni:

• Single prompt: un input, una risposta. Nessuno stato. Non è un agente.
• Chat conversation: lo stato è la storia conversazionale. Non c'è azione sul mondo. Non è un agente.
• Short agentic loop: cinque-cinquanta passi di tool use, qualche minuto, una sola context window. È la sessione tipica di Claude Code interattivo. È un agente, ma corto.
• Long-running agent: ore o giorni, più context window attraversate, stato persistente su file o memoria esterna, decisioni autonome multiple, human-in-the-loop ridotto al minimo.

Anthropic, nel suo Effective harnesses for long-running agents, è esplicita: si tratta di agenti incaricati di task complessi che spaziano su ore o giorni, costretti a lavorare in sessioni discrete, dove "ogni nuova sessione inizia senza memoria di quanto è venuto prima". La definizione si gioca su tre assi: durata wall-clock, numero di context window attraversate, autonomia decisionale.

Tre esempi che il mercato cita spesso, con i numeri puliti:

• Devin (Cognition, performance review 2025): 3-4 ore per una migrazione bancaria che impegnerebbe 30-40 ore umane. PR merge rate cresciuto dal 34% al 67% nell'arco di un anno. SWE-bench end-to-end al 13,86%.
• Anthropic C compiler experiment: circa 2.000 sessioni Claude Code, circa 20.000 dollari di API, 100.000 righe di compiler funzionante. Non è una run sola, è un progetto fatto di tante run incatenate.
• Opus 4.8 Dynamic Workflows (28 maggio 2026): migrazione di 750.000 righe in 11 giorni, 99,8% di test pass rate. Cap formale a 1.000 subagent totali per run, 16 concorrenti.

Numeri reali. Numeri impressionanti. Numeri da leggere con cura — ci torno tra poco.

Il loop autonomo ha 80 anni

Qui sta la firma del pezzo, e voglio dare il credito storico che il marketing non dà mai.

1948 — Wiener, Cybernetics. Prima formulazione moderna del feedback loop come principio generale di controllo. Wiener parte dai servomeccanismi della Seconda Guerra Mondiale (cannoni antiaerei, sistemi di puntamento) e generalizza: retroazione negativa, "l'informazione che torna al centro di controllo tende a opporsi allo scostamento del controllato dal controllante". Il termostato come archetipo: setpoint, sensore, attuatore, errore, correzione. Loop. Ne ho parlato per esteso nel pezzo su Wiener e gli agenti.

Anni '50-'60 — la control theory matura. PID controllers, stabilità di Lyapunov, sistemi a retroazione robusti. La domanda "come fa un sistema a mantenere un obiettivo per ore in presenza di disturbi" ha una risposta ingegneristica solida da settant'anni. Non è una novità del 2026.

1971 — STRIPS (Fikes & Nilsson, Stanford Research Institute). Il primo planner formale dell'AI. Stato iniziale, stato goal, operatori con preconditions ed effects. Il piano è una sequenza di azioni che porta dall'iniziale al goal. Frame problem, planning come search. Più di cinquant'anni fa.

1975 — NOAH (Nets of Action Hierarchies). Earl Sacerdoti. Pianificazione gerarchica: decomporre un task astratto in subtask sempre più concreti. È esattamente lo schema "agent orchestratore che spawna subagent" che oggi raccontiamo come novità.

Anni '80-'90 — HTN planning (Hierarchical Task Networks). Formalizzato in lavori come UMCP di Erol, Hendler e Nau (1994). Tasks compound che si decompongono in tasks primitive. La stessa idea che alimenta i Dynamic Workflows di Opus 4.8. Quarant'anni dopo.

Cosa è davvero nuovo nel 2026:

1. Il controller (LLM) ha una varietà operativa altissima — può ragionare su domini aperti senza un modello formale del mondo. È la Law of Requisite Variety di Ashby finalmente soddisfatta sul dominio del linguaggio naturale.
2. Il sistema può riformulare il proprio piano a metà esecuzione. L'HTN classico era statico: il piano si calcolava prima, poi si eseguiva. Qui si ricalcola di continuo.
3. I tool sono eterogenei e general-purpose: filesystem, browser, API, codice. Non più operatori formali su uno stato proposizionale.

Cosa non è nuovo: l'architettura del loop, la decomposizione gerarchica, il setpoint+feedback, il problema del drift, il problema dell'errore composto. Quest'ultimo, in particolare, era già perfettamente compreso negli anni '40 — e qui arriva il dato perno del pezzo.

Lusser's Law: la matematica che uccide il long-run

Robert Lusser era un ingegnere tedesco che progettò il missile da crociera V-1 durante la Seconda Guerra Mondiale, e che dopo la guerra raggiunse negli Stati Uniti il team di von Braun a Redstone Arsenal. È lì, negli anni '50, che formalizzò una cosa che oggi chiamiamo Lusser's Law, in due righe: l'affidabilità di un sistema in serie è il prodotto delle affidabilità dei suoi componenti. Niente più, niente meno.

Per un long-running agent, ogni step (tool call, decisione, scrittura su file) è un componente in serie. Vediamo cosa succede ai numeri:

Rileggi la terza riga. Anche con un'affidabilità per step del 99% — che per un LLM nel 2026 è ottimistico su tool use generale — su cento step l'affidabilità totale è il 37%. Su una run di sette ore con qualche centinaio di tool call, anche dopo aver migliorato di un ordine di grandezza per-step la reliability media, l'aspettativa di successo end-to-end resta modesta.

Questo non è un'opinione, non è un trend, non è "tra un anno con un modello più grande andrà meglio". È aritmetica. Lusser l'ha scritta per i missili, vale per gli agenti. Il problema dei long-run è geometrico, non incrementale: si moltiplica, non si somma.

C'è di peggio. Negli LLM gli errori non sono sintattici, sono semantici. Lo step 2 produce un output plausibile ma sbagliato. Gli step 3-10 costruiscono sopra quel fondamento con sicurezza. Allo step 15 sei lontano dalla soluzione ma nessun allarme è scattato — perché formalmente ogni step ha "funzionato". È la classe di failure più pericolosa, perché non si manifesta come crash.

Context drift e lost in the middle

Il secondo vincolo è la degradazione del contesto. Due fonti convergenti:

Liu et al. (2023), Lost in the Middle: How Language Models Use Long Contexts (arXiv:2307.03172, TACL 2023). I modelli performano meglio quando l'informazione rilevante è all'inizio o alla fine del context window. Nel mezzo, la performance crolla. La curva è a U.

Chroma Research (2025), Context Rot. Diciotto modelli frontier testati (GPT-4.1, Claude 4, Gemini 2.5, Qwen3). Il risultato è netto: "every model gets worse" all'aumentare dell'input. La performance degrada anche prima del riempimento nominale del context window. I modelli performano peggio con la full conversation history rispetto agli excerpt rilevanti.

Su una run da sette ore con centinaia di tool call, le decisioni iniziali — la specifica, i vincoli, la definition of done — finiscono fisicamente "nel mezzo" del contesto. Perdono peso relativo. L'agente diventa via via più miope, tendendo a ottimizzare il presente locale dimenticando l'obiettivo globale.

È un meccanismo che la control theory classica non aveva: un PID non ha "lost in the middle", la sua memoria è una funzione di trasferimento. Il controller LLM, invece, ha una memoria attentiva che si degrada con la lunghezza. Per questo le architetture serie che funzionano oggi esternalizzano lo stato in file (memoria persistente) invece di affidarsi al contesto.

Costo e debugging: i due vincoli operativi

Anche se Lusser non ti uccidesse, due altri vincoli ti raggiungono comunque.

Costo. L'esperimento del C compiler di Anthropic è il dato pulito che abbiamo: 2.000 sessioni, circa 20.000 dollari di API. Una run da sette ore con tool use intenso costa facilmente 50-200 dollari per esecuzione. Non scala su iterazioni quotidiane. Il valore prodotto può ripagarlo su task strutturati ad alto valore (una migrazione, un compiler), ma diventa proibitivo sull'iterazione quotidiana di un team che ha decine di task piccoli da chiudere ogni settimana.

Debugging post-mortem. Quando una run da sette ore fallisce, come fai a capire dove? I log sono enormi. Non c'è uno stack trace semantico. Il "perché ha deciso X al minuto 240" diventa archeologia. Le ore di run agentico si pagano due volte: una volta in API token, una seconda volta in tempo umano per ricostruire cosa è andato storto. Su run brevi questo costo è gestibile; su run lunghe è strutturale.

Anthropic stessa, nelle sue guide di harness design, lista tra i failure mode primari l'over-ambition ("provare a one-shot l'app") e la premature completion ("marcare una feature come completa senza testarla davvero"). Non sono bug periferici — sono pattern ricorrenti su run lunghe.

Quello che Anthropic dichiara, e quello che capita in media

Mettiamo in fila i due piani onestamente, senza polemica.

Quello che Anthropic dichiara per Opus 4.8 Dynamic Workflows:

• Centinaia di subagent paralleli in una singola sessione.
• Migrazioni "codebase-scale" su centinaia di migliaia di righe.
• 4× meno probabilità di lasciar passare code flaw senza commento.
• "Hours-long interactions" mantenendo focus.
• Caso esibito: 750.000 righe in 11 giorni, 99,8% test pass.

Tutto vero, presumibilmente. Ma è un best case su task altamente strutturato. Una migrazione è, in essenza, una trasformazione pattern-matching su tipi noti: ottima per la parallelizzazione, ottima per la verifica meccanica (i test passano o non passano), terreno favorevole per un agente.

Quello che capita in media sul lavoro vero:

• METR Time Horizon 1.1 (gennaio 2026): Claude Opus 4.6 raggiunge ~14,5 ore al 50% di success rate su HCAST. Attenzione, questo numero si interpreta male spesso: significa che il modello completa autonomamente, nel 50% dei casi, task che a un essere umano richiederebbero fino a 14,5 ore. Non significa che il modello giri per 14,5 ore. Il "tempo" è la complessità del task in unità umane, non la durata wall-clock della run. Il 50% è la mediana: l'altra metà delle volte fallisce.
• Devin: 67% PR merge rate, ma su task selezionati internamente da customer per fit. SWE-bench end-to-end al 13,86% (rilevazioni indipendenti danno 15-30% a seconda della metodologia).
• Anthropic stessa, nei suoi engineering blog: gli agenti "tendono a fare troppe cose in una volta", "dichiarano il job finito" prematuramente, "segnano feature come complete senza testarle".
• Frase chiave dell'enciclica Anthropic sull'agentic coding (qui il commento): "autonomous doesn't yet mean unsupervised".

Detto in modo brutale: i numeri impressionanti sono reali ma su task selezionati per essere ben affrontabili dall'agente. Sul task arbitrario del lavoro quotidiano, l'agente long-running è un pilota che ha bisogno di un copilota umano sveglio. La distribuzione delle run reali ha la moda intorno a 5-30 minuti, supervisionata. Non sette ore.

Il pattern che funziona, oggi, per davvero

Tradotto in pratica — quello che chi scrive codice può adottare la settimana prossima.

Checkpoint frequenti, stato esternalizzato. Lo stato vive in file (CHANGELOG.md, progress.json), non nel context window. Anthropic suggerisce esplicitamente JSON, "resistente a edit accidentali del modello": già questo dice molto sul livello di fiducia. Ne ho parlato nel pezzo sulla memoria degli agenti.

Setpoint chiari. Un CLAUDE.md, un GROUNDING.md, una definition of done esplicita. Senza setpoint un servomeccanismo non sa verso dove correggere. Il grounding md è letteralmente il punto fisso del loop.

Verifica strutturata con fresh-model verifier. Chi fa il lavoro non è chi lo valuta. Un agente fresh, senza context contaminato, tenta di refutare il risultato — è red teaming interno applicato all'output dell'agente principale.

Subagent advisory read-only, non swarm scrittori. Il subagente delega ricerca, lettura, analisi. Non gli affidi il commit. Questa è la lezione del dogma multi-agent: la divisione del lavoro vale quando i task sono read-only e indipendenti, non quando ognuno scrive sul filesystem condiviso. Sull'opportunità di dividere o no, il pezzo dedicato.

Human-in-the-loop per decisioni critiche. Permessi minimi, azioni reversibili preferite a quelle distruttive, human approval su operazioni high-stakes. Non è opzionale — è il fattore che fa funzionare i casi d'uso reali.

Git checkpoint strategy. Snapshot prima di ogni turno agentico, rollback automatico se la validazione fallisce. È la versione moderna di "reversible actions" che Wiener avrebbe riconosciuto come gestione della saturazione del controllore.

Mappando ai concetti teorici: questi sono controlli di stabilità di un sistema in retroazione. Setpoint (definition of done), sensori (verification agents, test), correttori (rollback), saturazione (permessi). Non è coincidenza che funzioni. È control theory applicata, settant'anni di letteratura messa in pratica con un controller nuovo.

Cosa cambia per chi scrive codice oggi

Il messaggio non è "aspettate l'AGI". Non è nemmeno "i long-running agents non funzionano". È più sottile.

L'autonomia lunga non è una conquista architetturale. L'architettura del loop autonomo che mantiene stato e agisce nel tempo ce l'abbiamo da 80 anni — Wiener, Sacerdoti, Erol, Hendler, Nau l'hanno descritta in dettaglio. È una conquista ingegneristica, che si fa step per step, con harness, checkpoint, verifier, definition of done, permessi minimi. La frontiera vera del 2026 non è "quanto a lungo gira", è "quanto bene gira mentre gira". Sono due metriche diverse, e il marketing tende a confonderle.

La domanda utile da farsi davanti al prossimo annuncio non è "quante ore lavora da solo". È: qual è la per-step reliability misurata? Quanti step compone una run tipica? Qual è il costo medio per run completata con successo? Qual è il failure mode dominante? Quanto costa il debugging post-mortem? Queste sono le metriche che separano una demo di una migrazione da un sistema produttivo.

Per chi sviluppa, in pratica: investire in harness vale più che aspettare il modello successivo. La differenza tra un agente affidabile a 100 step e un agente affidabile a 10 step non è il modello — è il sistema di controllo intorno al modello. Setpoint, sensori, correttori, checkpoint. Le stesse quattro parole del 1948.

Wiener avrebbe capito subito. Probabilmente avrebbe scritto un altro libro.

Fonti

1. Anthropic — Effective harnesses for long-running agents
2. Anthropic — Long-running Claude for scientific computing
3. Anthropic — Harness design for long-running application development
4. Anthropic — Building a C compiler with autonomous agents
5. Anthropic — Introducing Claude Opus 4.8
6. METR — Measuring AI Ability to Complete Long Tasks e Time Horizons hub
7. Liu et al. — Lost in the Middle: How Language Models Use Long Contexts (arXiv:2307.03172)
8. Chroma Research — Context Rot
9. Cognition — Devin's 2025 Performance Review
10. Erol, Hendler, Nau — UMCP: A Sound and Complete Procedure for HTN Planning (1994)
11. An Overview of HTN Planning (arXiv:1403.7426)
12. Wikipedia — Cybernetics: Or Control and Communication in the Animal and the Machine
13. Wikipedia — Hierarchical Task Network
14. Towards Data Science — The Math That's Killing Your AI Agent