Cos'è il Loop Engineering
Il loop engineering è la pratica di progettare cicli automatici che fanno ripartire da soli un agente AI, invece di scrivere manualmente un prompt ogni volta che serve un'azione. Non è un nuovo modello di intelligenza artificiale: è una disciplina di ingegneria dei sistemi che decide quando l'agente si attiva, cosa deve verificare e cosa deve ricordare da un ciclo all'altro.
Il termine è diventato virale a metà 2026 dopo che due figure centrali nello sviluppo di agenti AI hanno dichiarato pubblicamente di aver abbandonato il prompting manuale in favore di questo approccio. Per una PMI italiana, il punto pratico è questo: un sistema costruito con loop engineering non aspetta che qualcuno gli scriva istruzioni, verifica da solo se un obiettivo è stato raggiunto e riparte in autonomia quando serve.
Come si è arrivati al Loop Engineering: l'evoluzione in 4 tappe
Il loop engineering non nasce dal nulla: è il quarto stadio di un'evoluzione che parte dal semplice prompt e finisce con sistemi che si auto-dirigono. Capire i tre stadi precedenti è necessario per capire perché il quarto era inevitabile.
1. Prompt Engineering: il system prompt
Il prompt engineering consiste nello scrivere un'istruzione iniziale (system prompt) che dice al modello chi è e come deve rispondere: "sei un avvocato", "sei uno sviluppatore front-end", "sei un assistente per il customer care". Ogni risposta successiva riflette quelle istruzioni. È ancora oggi la base di qualsiasi assistente AI, ma da sola gestisce solo la conversazione, non l'azione.
2. Context Engineering: quando l'AI diventa un agente
Con il context engineering, il modello smette di essere solo un generatore di testo e diventa un agente: può leggere file, cercare sul web, chiamare applicazioni tramite protocolli come MCP (Model Context Protocol). Ogni azione che compie (una ricerca, la lettura di un file, una chiamata a un CRM) va a occupare la sua finestra di contesto, cioè la quantità di testo che il modello può gestire in un colpo solo.
Qui emerge il problema chiamato context rot: più la finestra di contesto si riempie, più le prestazioni del modello peggiorano. Una ricerca di Chroma su 18 modelli di frontiera ha verificato che tutti, senza eccezione, peggiorano man mano che l'input si allunga, un effetto misurabile molto prima di raggiungere il limite massimo dichiarato dal modello.
Claude Sonnet 4.5 e Claude Haiku 4.5 lavorano su una finestra di contesto standard di 200.000 token. Anche nella modalità estesa fino a 1 milione di token, test indipendenti rilevano un degrado misurabile a partire da circa 400.000 token. Fonte: Claude Platform Docs, Anthropic, 2026.
Il context engineering lavora proprio su questo: tenere il contesto il più pulito possibile, ottenere risposte brevi dai tool, e quando la finestra si riempie comunque, riassumere (compaction) per liberare spazio. Il problema è che ogni riassunto perde dettagli, e se il lavoro richiede molti passaggi la compaction va ripetuta più volte, con perdita di qualità crescente.
3. Harness Engineering: la memoria persistente su file
L'harness engineering nasce per evitare il riassunto continuo. Invece di comprimere il contesto dentro la finestra del modello, si costruisce una struttura esterna (l'"harness", termine che richiama i finimenti di un cavallo: il modello è la forza, l'harness è ciò che la incanala) che spezza un task grande in sotto-task, facendo ripartire l'agente da zero a ogni passaggio, ma con la memoria di cosa è già stato fatto scritta su file esterni.
Questi file sono tipicamente in markdown: un CLAUDE.md o AGENTS.md per le istruzioni persistenti del progetto, un memory.md per i fatti di lungo periodo, cartelle con lo storico organizzato per data. L'agente legge e scrive su questi file invece di tenere tutto in memoria attiva, usando il file system come estensione della sua finestra di contesto. È lo stesso principio con cui un agente come un agente AI aziendale mantiene coerenza su compiti che durano giorni invece che minuti.
4. Loop Engineering: il loop sopra il loop
A questo punto ci sono già due cicli in funzione: il modello che chiama i suoi strumenti e riceve risposte (un loop), e l'harness che passa da un sotto-task al successivo finché il task non è completo (un secondo loop). Il loop engineering prende entrambi e li mette dentro un terzo ciclo, quello che decide quando l'intero processo deve ripartire da capo.
La differenza pratica è questa: con l'harness engineering, l'utente definisce comunque il task iniziale. Con il loop engineering, è il sistema stesso a decidere quando agire, sulla base di un trigger (un errore che arriva, una scadenza, un nuovo dato), senza che nessuno debba riscrivere il prompt ogni volta.
"Non prompto più Claude. Ho dei loop che prompt-ano Claude e decidono cosa fare. Il mio lavoro adesso è scrivere loop." Boris Cherny, responsabile di Claude Code in Anthropic, giugno 2026. Fonte: The New Stack, 2026.
Pochi giorni dopo, Peter Steinberger, creatore di OpenClaw, ha scritto lo stesso concetto in un post pubblico: gli sviluppatori non dovrebbero più scrivere prompt manuali ai loro agenti di coding, ma progettare i loop che li prompt-ano al posto loro. Non è una dichiarazione da prendere alla leggera: OpenClaw è il progetto open source più famoso al mondo.
OpenClaw ha superato le 250.000 stelle su GitHub in circa 100 giorni, un traguardo che a React (lanciato 13 anni prima) era servito per raggiungere 243.000 stelle. Fonte: Star History Blog, 2026.
Come funziona un loop AI: trigger, esecuzione, verifica, memoria
Ogni loop, indipendentemente dal caso d'uso, segue la stessa struttura a quattro fasi.
1. Trigger
L'evento che avvia il ciclo: un errore segnalato su un repository, una nuova notizia rilevata via email o API, un orario programmato ("ogni mattina alle 9:00"), oppure una richiesta di un cliente.
2. Esecuzione
Parte l'harness: l'agente esegue i passaggi necessari, chiama gli strumenti, modifica file o codice, interagisce con le app collegate.
3. Verifica
Il sistema controlla se l'obiettivo è stato raggiunto. Questo è il punto più delicato del loop engineering, ed è trattato nel dettaglio nella sezione successiva.
4. Memoria e nuovo trigger
Il risultato viene scritto su file (cosa è stato fatto, cosa ha funzionato, cosa no), e il sistema si prepara al ciclo successivo, che parte al prossimo trigger.
Su Claude Code questi meccanismi sono già disponibili come funzioni native tramite i comandi /loop (esegue un prompt a intervalli regolari, ad esempio ogni giorno o ogni settimana) e /goal (persegue un obiettivo fino a una condizione di arresto, ad esempio un numero massimo di tentativi o un tempo limite). La condizione di arresto non è opzionale: senza un limite di tentativi o di tempo, un obiettivo irraggiungibile manda il sistema in un ciclo infinito che consuma token senza produrre risultati.
I 5 livelli di verifica di un loop (e perché contano per un'azienda)
Un loop funziona solo se il sistema può stabilire, da solo, quando fermarsi. Esistono cinque modi diversi per farlo, in ordine crescente di complessità e di rischio.
| Livello | Come si verifica | Esempio |
|---|---|---|
| 1. Deterministica | Vero/falso, senza ambiguità | "Il codice deve compilare senza errori" |
| 2. Regole e vincoli numerici | Soglia misurabile | "La pagina deve caricare sotto i 100 millisecondi" |
| 3. Verità terrena ritardata | Verificabile solo dopo giorni | "Il post deve raggiungere 300 reazioni su LinkedIn" |
| 4. AI come giudice | Il modello stesso assegna un punteggio | "Migliora l'interfaccia finché non è identica a questa immagine" |
| 5. Checkpoint umano | Una persona valuta e decide | Approvazione manuale prima di ogni pubblicazione |
Il livello 3 (verità terrena ritardata) è quello meno intuitivo ma più utile per il business: riguarda tutti i casi in cui il risultato di un'azione si vede solo dopo giorni, come una campagna pubblicitaria, un post social o un'email di follow-up. Il loop qui non verifica subito: aspetta il dato reale (reazioni, click, risposte), lo confronta con l'obiettivo, e aggiusta il comportamento nel ciclo successivo.
Un esempio concreto di livello 4 (AI come giudice) arrivato dal mondo dello sviluppo: un agente a cui viene chiesto di clonare un'interfaccia web parte da uno screenshot della pagina originale, modifica il codice, rifà lo screenshot, confronta le due immagini e si assegna un punteggio di somiglianza, ripetendo il ciclo finché il punteggio non supera una soglia decisa in anticipo. Lo stesso principio si applica a un caso di ottimizzazione delle performance: in una demo pubblica, uno script di calcolo tra matrici è stato migliorato in dieci iterazioni autonome (da un'implementazione base in float64 fino a un'esecuzione su GPU con calcolo a precisione ridotta sui Tensor Core), ottenendo un salto di velocità di circa 320 volte, con ogni modifica tracciata in un log per garantire la riproducibilità.
Loop Engineering per le PMI italiane: casi d'uso concreti
Il loop engineering nasce in contesti di sviluppo software, ma la logica si applica a qualunque processo aziendale ripetitivo con un obiettivo misurabile. Tre esempi concreti per una PMI italiana:
- Monitoraggio prezzi e contenuti concorrenti: un trigger giornaliero controlla i siti dei competitor, un loop aggiorna automaticamente il listino o i contenuti quando cambia qualcosa, senza intervento manuale.
- Nurturing lead con verità terrena ritardata: un loop scrive sequenze di follow-up, misura il tasso di risposta dopo alcuni giorni, e corregge tono e tempistiche nel ciclo successivo, esattamente come nell'esempio del post LinkedIn.
- Gestione automatica di ticket o richieste ricorrenti: ogni nuova richiesta è un trigger, il loop esegue la stessa procedura di verifica e risposta, scrivendo su file cosa ha gestito, senza dover ripartire da zero ogni volta.
Il progetto Autoresearch di Andrej Karpathy, ricercatore tra i più noti al mondo nel campo dei modelli linguistici, mostra quanto in profondità si può spingere questo approccio anche fuori dallo sviluppo di prodotti: uno script di circa 630 righe che fa girare in autonomia un loop di sperimentazione su un modello linguistico, senza intervento umano tra un esperimento e l'altro.
Nella sua run di due giorni, Autoresearch ha eseguito 700 esperimenti in autonomia, riducendo il tempo del benchmark "Time to GPT-2" da 2,02 a 1,80 ore. Nel primo mese il progetto ha superato le 66.000 stelle su GitHub. Fonte: The New Stack, 2026.
Rischi e limiti: quando il Loop Engineering non va usato
Il loop engineering funziona bene quando l'obiettivo è verificabile in uno dei cinque modi visti sopra. Fuori da questi casi, il rischio concreto è duplice: un sistema che gira senza produrre valore reale (consumando comunque risorse), oppure un sistema che si "convince" di aver raggiunto un obiettivo che in realtà non ha capito bene, perché la condizione di successo era vaga o mal definita.
Per questo un obiettivo come "crea un post che diventi virale" va sempre riformulato in una metrica precisa ("300 reazioni entro 5 giorni"), e ogni loop deve avere una condizione di arresto esplicita (numero massimo di tentativi o tempo massimo), altrimenti un obiettivo irraggiungibile lo manda in un ciclo infinito. Nei casi in cui non esiste una metrica affidabile, il checkpoint umano (livello 5) resta la scelta più sicura, non un ripiego.
Come Ogaia costruisce sistemi di automazione AI basati su loop per le PMI
In Ogaia | Soluzioni AI & Customer Generation per Aziende Italiane progettiamo sistemi di automazione che non si fermano al primo output: definiamo insieme al cliente l'obiettivo misurabile (un tasso di risposta, un tempo di gestione, un numero di lead qualificati), costruiamo il ciclo che lo persegue in autonomia, e mettiamo un checkpoint umano esattamente dove serve, non ovunque per abitudine.
La differenza tra un'automazione che si ferma al primo passaggio e un sistema che si corregge da solo nel tempo è la differenza tra uno strumento e un dipendente digitale che lavora anche quando nessuno lo guarda. Se vuoi capire quali processi della tua azienda hanno un obiettivo abbastanza misurabile da poter essere messi in loop, prenota una call gratuita di 45 minuti: uscirai con una mappa chiara dei tuoi colli di bottiglia, indipendentemente da quello che decidi di fare dopo.