🤖 AI

In-Context Prompting Obsoletes Agent Orchestration for Procedural Tasks

Questo articolo sostiene che, per compiti procedurali multi-turno, una prompting contestuale più semplice in cui il modello si orchestra autonomamente supera i complessi framework di orchestrazione di agenti esterni, rendendo questi ultimi obsoleti per i modelli all'avanguardia.

Autori originali: Simon Dennis, Michael Diamond, Rivaan Patil, Kevin Shabahang, Hao Guo

Pubblicato 2026-05-01

📖 4 min di lettura☕ Lettura da pausa caffè

CC BY 4.0

Autori originali: Simon Dennis, Michael Diamond, Rivaan Patil, Kevin Shabahang, Hao Guo

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di dover completare un compito complesso, come prenotare una vacanza familiare complicata, risolvere un problema con una chiamata Zoom interrotta o presentare una richiesta di risarcimento assicurativo. Nel mondo dell'Intelligenza Artificiale (IA), esistono due modi principali per istruire un computer intelligente su come eseguire queste attività.

Questo articolo sostiene che il metodo "elaborato e complicato" sta in realtà peggiorando le cose, mentre il metodo "semplice e diretto" è molto migliore.

Ecco la spiegazione utilizzando semplici analogie:

I Due Approcci

1. L'Approccio "Manager" (Orchestrazione degli Agenti)
Pensa a questo come a un rigoroso piano di fabbrica. Hai un lavoratore molto intelligente (l'IA), ma hai anche un Manager che gli sta sempre dietro le spalle.

Il Manager possiede un organigramma (una mappa dei passaggi).
Il Manager dice al lavoratore esattamente cosa dire per il Passaggio 1.
Una volta che il lavoratore ha completato il Passaggio 1, il Manager verifica il lavoro, decide se procedere al Passaggio 2 o al Passaggio 3, e poi sussurra le istruzioni per il passaggio successivo.
Il lavoratore non vede mai l'intera mappa; vede solo la minuscola istruzione per il momento attuale.
Il Problema: Il Manager è lento, commette errori nel decidere il passaggio successivo e talvolta dimentica ciò che il lavoratore ha detto tre passaggi prima, perché si concentra solo sull'istruzione corrente.

2. L'Approccio "Autoguidato" (Prompting in Contesto)
Pensa a questo come a fornire allo stesso lavoratore intelligente un manuale di istruzioni completo e una mappa dell'intero viaggio prima che inizi.

Il lavoratore legge l'intero manuale.
Sa esattamente dove si trova, dove deve andare e cosa fare dopo.
Non ha bisogno di un Manager che gli dica cosa fare; si guida da solo.
Il Vantaggio: Vede il quadro generale, ricorda l'intera conversazione e procede naturalmente senza fermarsi a chiedere il permesso ad ogni svolta.

Cosa Hanno Fatto i Ricercatori

Gli autori hanno testato questi due approcci utilizzando un'IA molto intelligente (chiamata "Claude Sonnet") su tre diversi scenari del mondo reale:

Prenotazione di Viaggi: Pianificare un viaggio per un gruppo con un budget specifico e interessi particolari.
Assistenza Tecnica: Risolvere un problema audio su Zoom.
Reclami Assicurativi: Presentare un reclamo dopo aver investito un cervo con un'auto.

Hanno eseguito 200 simulazioni per ogni scenario utilizzando sia lo stile "Manager" che quello "Autoguidato". Successivamente, hanno fatto agire un'altra IA come giudice per valutare le conversazioni in base a criteri quali:

Hanno completato il compito?
Le informazioni erano accurate?
La conversazione sembrava naturale o robotica?
L'IA si è confusa o ha ripetuto se stessa?

I Risultati: Il Lavoratore "Autoguidato" Vince

I risultati sono stati chiari e coerenti in tutti e tre gli scenari:

Migliore Qualità: L'IA "Autoguidata" (In-Context) ha ottenuto punteggi più alti in ogni singolo parametro. Ha completato i compiti più spesso, ha ricordato meglio i dettagli e ha suonato più simile a un essere umano utile.
Meno Errori: L'approccio "Manager" ha fallito molto più spesso.
- Nella prenotazione di viaggi, il Manager ha fallito nel 24% dei casi. L'IA Autoguidata ha fallito solo nell'11,5%.
- Nell'assistenza tecnica, il Manager ha fallito nel 9% dei casi. L'IA Autoguidata ha fallito solo nello 0,5% (quasi mai).
- Nell'assicurazione, il Manager ha fallito nel 17% dei casi. L'IA Autoguidata ha fallito nel 5%.
Perché il Manager Ha Fallito: Poiché il Manager guardava solo un passaggio alla volta, l'IA spesso dimenticava dettagli importanti menzionati dall'utente in precedenza (come il budget essere "per persona" invece che "totale"). Inoltre, rimaneva intrappolata in loop, ponendo la stessa domanda ripetutamente perché perdeva il filo di dove si trovasse nel processo.
Velocità e Costo: L'approccio "Manager" ha richiesto in realtà più potenza di calcolo e tempo, perché il Manager doveva fermarsi e pensare ad ogni singolo punto decisionale. L'approccio "Autoguidato" è stato più veloce e fluido, anche se richiedeva un "manuale" leggermente più lungo da caricare nella memoria dell'IA all'inizio.

La Conclusione

L'articolo conclude che per i compiti che seguono un insieme chiaro di regole (come prenotare un viaggio o presentare un reclamo), non abbiamo più bisogno di un Manager.

In passato, i modelli di IA erano "più stupidi" e avevano bisogno di un Manager per tenerli per mano ad ogni passaggio. Ma i modelli di IA di oggi sono così intelligenti che, se gli fornisci l'intero regolamento all'inizio, possono capire il resto da soli. Aggiungere un Manager in realtà ostacola il processo, causando confusione ed errori.

La semplice conclusione: Se hai una procedura chiara, inserisci l'intera procedura nelle istruzioni dell'IA e lasciala lavorare. Non costruire un sistema complesso per gestirla.

1. Enunciato del Problema

Il documento affronta la crescente complessità e i problemi di affidabilità associati ai Framework di Orchestrazione degli Agenti (ad es. LangGraph, CrewAI, Google ADK, OpenAI Agents SDK). Questi framework impiegano tipicamente un controller esterno (orchestratore) che si posiziona al di sopra del Large Language Model (LLM). L'orchestratore traccia lo stato della conversazione, gestisce un grafo diretto dei passaggi del flusso di lavoro e inietta istruzioni di routing specifiche o prompt specifici per nodo ad ogni turno.

Gli autori sostengono che questa architettura introduca un significativo sovraccarico ingegneristico, errori a cascata, fallimenti di routing e scarsa coerenza tra le diverse prove. Ipotizzano che, per compiti procedurali (conversazioni che seguono un flusso di lavoro definito dall'ingresso alla risoluzione), i moderni LLM all'avanguardia possiedano capacità di ragionamento sufficienti per auto-orchestrarsi quando viene fornita l'intera procedura nel loro contesto, rendendo l'orchestrazione esterna non necessaria e potenzialmente dannosa.

2. Metodologia

Lo studio impiega un confronto empirico controllato tra due condizioni utilizzando lo stesso modello all'avanguardia (Claude Sonnet 4.5) su tre domini distinti con complessità variabile:

Prenotazione Viaggi: 14 nodi, 3 hub decisionali.
Supporto Tecnico Zoom: 14 nodi, 3 hub decisionali (richiede accuratezza tecnica).
Elaborazione Sinistri Assicurativi: 55 nodi, 6 hub decisionali (alta complessità con cicli annidati).

Condizioni Sperimentali:

Condizione A (Orchestrata da LangGraph): Il flusso di lavoro è implementato come un grafo diretto in LangGraph. L'orchestratore gestisce lo stato, prende decisioni di routing tramite chiamate LLM aggiuntive agli hub decisionali e inietta template di prompt specifici per nodo nel prompt di sistema per ogni turno.
Condizione B (Baseline In-Context): Il modello riceve l'intero diagramma di flusso serializzato (tutti i nodi, gli archi, le condizioni e gli stati terminali) nel suo prompt di sistema. Il modello si auto-orchestra, determinando il passaggio successivo e il routing internamente senza tracciamento dello stato esterno o chiamate di routing.

Setup di Valutazione:

Dati: 200 conversazioni simulate per condizione per dominio ( $N=1.200$ totali).
Simulatore: Un simulatore utente (alimentato da Claude Sonnet) genera risposte dinamiche basate sulla cronologia della conversazione, senza conoscenza del diagramma di flusso sottostante.
Giudizio: Le conversazioni sono state valutate da un LLM-as-Judge (inizialmente Claude Sonnet, replicato con GPT-4.1) su cinque criteri:
1. Successo del compito (completamento procedurale)
2. Accuratezza delle informazioni
3. Coerenza (coerenza dello stato)
4. Gestione Elegante (adattabilità ad ambiguità/casi limite)
5. Naturalità (interazione simile a quella umana)

3. Contributi Chiave

Evidenza Empirica di Obsolescenza: Dimostra che, per compiti procedurali, un approccio semplice di prompting in-context supera costantemente i framework complessi di orchestrazione in tutte le metriche di qualità.
Analisi delle Modalità di Fallimento: Identifica che l'orchestrazione introduce specifiche modalità di fallimento strutturale (errori di routing, ragionamento frammentato, conflitti di template) che non esistono nell'approccio in-context.
Analisi dell'Efficienza: Quantifica il compromesso tra l'uso dei token (più alto in-context a causa dell'inclusione della procedura) e l'efficienza delle chiamate API (più bassa in-context a causa della mancanza di sovraccarico di routing).
Controllo di Robustezza: Convalida i risultati utilizzando un giudice indipendente (GPT-4.1) per escludere un bias di auto-preferenza nel giudice principale.

4. Risultati

A. Prestazioni di Qualità

La baseline in-context ha superato significativamente l'orchestratore LangGraph in 15 su 15 confronti (3 domini × 5 metriche) sotto il giudizio di Claude, con tutte le differenze statisticamente significative ( $p < 0.005$ ).

Punteggi: I punteggi in-context sono variati da 4.53 a 5.00, mentre i punteggi LangGraph sono variati da 4.17 a 4.84.
Coerenza e Gestione Elegante: Il divario è stato più marcato qui. Il modello in-context ha mantenuto una coerenza quasi perfetta (4.83–4.99) e adattabilità (4.96–5.00), mentre il sistema orchestrato ha faticato (rispettivamente 4.32–4.55 e 4.38–4.62).
Replica: Utilizzando GPT-4.1 come giudice ha confermato i risultati principali: 11 su 15 confronti hanno favorito il prompting in-context, con zero a favore dell'orchestrazione. Il divario di "Naturalità" si è ridotto nella valutazione di GPT-4.1, suggerendo che il giudice Claude potrebbe avere un bias verso il testo non vincolato.

B. Tassi di Fallimento

Il sistema orchestrato ha fallito significativamente più spesso (definito come Successo del compito $\le$ 3):

Viaggi: 24.0% di fallimento (LangGraph) vs 11.5% (In-Context).
Zoom: 9.0% di fallimento (LangGraph) vs 0.5% (In-Context).
Assicurazioni: 17.0% di fallimento (LangGraph) vs 5.0% (In-Context).
Cause Radice: I fallimenti orchestrati sono stati attribuiti a errori di routing (classificazione errata dello stato della conversazione agli hub decisionali), perdita di informazioni attraverso i confini dei nodi e cicli infiniti causati dal fatto che l'agente perdeva il controllo delle fasi completate.

C. Efficienza e Costi

Chiamate API: L'orchestrazione ha richiesto 1.2x-1.7x più chiamate LLM per conversazione a causa delle decisioni di routing agli hub decisionali.
Utilizzo dei Token: Il prompting in-context ha consumato più token per conversazione (ad es. 68K vs 43K per Assicurazioni) perché la procedura serializzata era inclusa in ogni chiamata API.
Costo: Nonostante un uso più elevato dei token, l'approccio in-context è risultato solo 1.3x–1.4x più costoso per conversazione. Il premio di costo è modesto rispetto ai significativi guadagni in qualità e affidabilità.

5. Significato e Implicazioni

Cambiamento di Paradigma: Il documento suggerisce che, per compiti procedurali ben definiti, l'"impalcatura" fornita dai framework di orchestrazione non è più necessaria per i modelli all'avanguardia. In effetti, questa impalcatura degrada attivamente le prestazioni frammentando il ragionamento del modello e introducendo punti di fallimento.
Raccomandazione Ingegneristica: I praticanti dovrebbero dare priorità al mettere l'intera procedura nel prompt di sistema prima di ricorrere a framework di orchestrazione complessi. Questo semplifica lo stack, riduce la latenza (meno chiamate API) e migliora l'affidabilità.
Limitazioni e Lavori Futuri:
- I risultati si applicano specificamente ai compiti procedurali con flussi di lavoro definiti. Compiti non procedurali (creativi, aperti) o pipeline multi-modello potrebbero ancora beneficiare dell'orchestrazione.
- L'approccio richiede che la procedura rientri nella finestra di contesto del modello (sebbene le procedure da 55 nodi abbiano utilizzato solo circa il 2% di una finestra di 200K token).
- Per la produzione ad alto volume, il costo più elevato dei token del prompting in-context potrebbe motivare il fine-tuning della procedura in modelli più piccoli come alternativa economicamente vantaggiosa.

Conclusione: Gli autori concludono che, man mano che i modelli all'avanguardia migliorano, il valore dell'orchestrazione esterna per i compiti procedurali diminuisce. Il "collo di bottiglia" non è un'orchestrazione migliore; l'orchestrazione stessa è il collo di bottiglia.