Il 7 giugno Addy Osmani ha pubblicato Loop Engineering, sulla forma di un agente che lavora da solo per ore. La tesi è che il punto di leva si sia spostato dal prompt al ciclo che lo contiene: “That’s what makes loop design harder than prompt engineering, not easier”.
Nei due mesi precedenti su arXiv erano usciti due lavori che partono dallo stesso problema e arrivano in direzioni opposte. Uno propone di sostituire il ciclo con un grafo dichiarato in anticipo. L’altro misura l’orchestrazione esterna contro il farne a meno, e trova l’orchestratore in svantaggio.
Abbiamo già descritto l’anatomia del ciclo e l’ambiente che lo rende affidabile. La forma da dargli è una decisione di progetto separata.
Il loop, e cosa lo tiene su
Osmani mette la memoria fuori dal contesto: “the model forgets everything between runs so the memory has to be on disk and not in the context. The agent forgets, the repo doesnt”. Ogni esecuzione riparte da una finestra di contesto vuota, quindi lo stato che deve sopravvivere fra due esecuzioni va riletto dai file che l’agente stesso ha scritto.
La seconda scelta è strutturale: “The most useful structural thing in a loop, by far, is splitting the one who writes from the one who checks”, perché il modello che ha scritto il codice è troppo indulgente nel valutarlo. La stessa separazione va applicata alla condizione di arresto, con “a fresh model” che decide se il ciclo è finito al posto di quello che ha fatto il lavoro.
I connettori sono la terza: “the reason the loop can act inside your actual environment instead of just telling you what it would do if it could”.
Osmani mette anche il proprio caveat: “its still early, I’m skeptical and you absolutely have to be careful about token costs (usage patterns can vary wildly if you are token rich or poor)”.
Il grafo, come proposta di ingegneria
Il paper arXiv 2604.11378, From Agent Loops to Structured Graphs, di Hu Wei, depositato il 13 aprile, attacca il loop su tre punti: “implicit dependencies between steps, unbounded recovery loops, and mutable execution history that complicates debugging”.
L’inquadramento è quello della teoria dello scheduling. Il loop viene descritto come “a single ready unit scheduler”, dove al massimo una unità è attiva e la scelta di quale attivare arriva “from opaque LLM inference rather than an inspectable policy”. Da lì la proposta, SGH, che sposta il controllo di flusso dal contesto implicito a un DAG statico, con piani immutabili dentro una versione, tre livelli separati (pianificazione, esecuzione, recupero) e un protocollo di escalation.
Il paper è esplicito su cosa non è: “This is a position paper and design proposal. We provide a theoretical framework, design analysis, and experimental protocol, not a production implementation or empirical results”. Le sue quattro consegne sono un framework, un’analisi di compromesso su 70 sistemi censiti, una specifica formale con garanzie di terminazione e un protocollo sperimentale a sette gruppi lasciato a validazione futura.
Il prompt, con i numeri contro l’orchestratore
Il lavoro opposto è arXiv 2604.27891, di Simon Dennis, Michael Diamond, Rivaan Patil, Kevin Shabahang e Hao Guo, depositato il 30 aprile e rivisto il 5 maggio. Confronta un orchestratore LangGraph con la procedura messa tutta nel system prompt, a parità di modello, su tre domini: prenotazione viaggi a 14 nodi, supporto tecnico Zoom a 14 nodi, gestione sinistri assicurativi a 55 nodi. Duecento conversazioni per condizione, valutate con LLM-as-judge su cinque criteri.
| Misura | In-context | LangGraph |
|---|---|---|
| Punteggio, scala 1-5 | 4,53-5,00 | 4,17-4,84 |
| Fallimenti, viaggi | 11,5% | 24% |
| Fallimenti, Zoom | 0,5% | 9% |
| Fallimenti, sinistri | 5% | 17% |
La conclusione degli autori è temporale: “While external orchestration may have been necessary for earlier models, advances in frontier model capabilities have made it unnecessary for multi-turn conversations following a defined procedure”.
Il metodo va pesato. Il giudice è un modello, i domini sono tre e le procedure sono definite in anticipo, che è la condizione più favorevole all’approccio in-context. Restano numeri su un confronto a parità di modello, con condizioni e criteri di valutazione dichiarati.
Quanto costa il ciclo
Il conto lo ha pubblicato Anthropic descrivendo il proprio sistema di ricerca multi-agente: “agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats”. Da cui la condizione dichiarata: “multi-agent systems require tasks where the value of the task is high enough to pay for the increased performance”.
Le stesse pagine di Anthropic, in Building effective agents, separano workflow e agente. Un workflow è un sistema dove modelli e strumenti sono orchestrati lungo percorsi di codice predefiniti. Un agente è un sistema dove il modello dirige da sé il proprio processo e l’uso degli strumenti.
Cosa ne pensiamo
Le tre posizioni non rispondono alla stessa domanda, ed è il motivo per cui possono essere tutte difendibili insieme.
Dove la procedura è nota in anticipo e i passi sono elencabili, il lavoro di Dennis e colleghi dice che l’orchestratore esterno aggiunge un punto di rottura senza aggiungere qualità, e lo dice con un confronto misurato. Dove la procedura è nota ma serve poterla verificare a posteriori, la posizione di Hu Wei è un’ipotesi di ingegneria coerente, che però al momento è dichiaratamente non validata. Il loop di Osmani è per il caso in cui il percorso non è elencabile in anticipo, ed è lì che le sue due scelte contano davvero.
La memoria su disco e la separazione fra chi scrive e chi controlla non dipendono dalla forma scelta: valgono per un grafo come per un ciclo, e sopravvivono al cambio di framework. Un sistema con la memoria nel contesto perde tutto al primo riavvio, e un sistema che si valuta da solo dichiara finito ciò che ha appena scritto.
Il criterio pratico che ne ricaviamo è di partire dalla forma meno costosa che risolve il compito, e salire solo quando il compito lo impone: procedura in-context finché la procedura è definita, ciclo con memoria e checker separato quando i passi non sono elencabili, coordinamento multi-agente quando il valore del compito copre quindici volte i token di una chat. Il senso della misura di Anthropic è che quel salto va giustificato ogni volta.