Claude Platform, Anthropic: un agente con skill spesso batte i subagenti

Un’azienda aveva messo una dozzina di subagenti specialisti dentro il suo agente per i clienti: mantenere un’esperienza coerente con il marchio diventava difficile e la latenza peggiorava l’uso. È uno degli esempi che Anthropic porta in una pagina pubblicata sul proprio sito, dove presenta un migration kit per chi ha costruito su Claude Platform agenti con più subagenti.

Chi ha un sistema così può farlo girare per capire, secondo l’azienda, quali subagenti inglobare nel ciclo dell’agente principale. Il kit include una demo da provare su un sistema finto prima di toccare il proprio agente.

Cosa fa il kit di migrazione

Secondo Anthropic, il kit esegue un workflow guidato: individua i pattern presenti nel sistema, valuta le alternative e verifica l’approccio migliore. Concatena in un unico percorso le nuove skill di Claude API, quattro in tutto, descritte più sotto.

I subagenti, spiega l’azienda, sono agenti con una propria finestra di contesto, propri strumenti e istruzioni, coordinati da un orchestratore. Restano una componente centrale del design, efficace per verifiche, lavoro in parallelo e permessi modulari. Anthropic li usa in diversi suoi agenti, per esempio nel sistema di ricerca multi-agente.

Perché Anthropic punta su un solo agente

Il team Applied AI dichiara di aver visto, in vari deployment enterprise, che un singolo agente con skill ha spesso superato sia il design con un unico prompt per tutto sia quello a subagenti. Il vantaggio riguarda la qualità e, spesso, costo e latenza per task. Un cliente che ha confrontato il proprio harness multi-agente con un ciclo a singolo agente ha misurato un runtime circa due volte più veloce con il secondo.

Anthropic vede spesso progetti con una scala di strutture: classificatore di intenti, pipeline di ragionamento fissa, gruppi di utenti, rami di raccomandazione e un orchestratore sopra. Il riscontro ricorrente è che gran parte di quella struttura svolgeva un lavoro che il modello non richiede più, e che bastano un prompt di sistema chiaro, quattro o cinque tool sottili per i dati e vincoli fermi sull’output.

Le ragioni indicate sono tre:

• il contesto condiviso nella finestra principale produce risposte migliori dei riassunti restituiti dai subagenti e riduce finestre di contesto e passaggi che perdono informazioni;
• la progressive disclosure (l’agente vede solo descrizioni brevi di skill e tool, caricati per intero quando servono) evita il sovraccarico del prompt; Anthropic dice di aver ridotto di oltre l’80% il system prompt di Claude Code per i modelli più avanzati, anche con tagli legati a questa tecnica;
• i modelli gestiscono più lavoro in un solo ciclo: a partire da Opus 4.5, secondo Anthropic, molto più di quanto i team si aspettassero. L’azienda precisa che il thinking non si può disattivare su Opus 5.5 e Fable 5.1, e che nelle migrazioni seguite le strutture multi-agente rigide hanno spesso impedito al nuovo modello di fare più lavoro.

Come funziona il ciclo a singolo agente

Il design suggerito prevede un modello e una finestra di contesto in un ciclo aperto di chiamate a tool, con limiti (budget di turni e di costo, write gate) impostati nell’harness. A ogni turno il modello emette un gruppo di chiamate, l’harness le esegue in parallelo e restituisce i risultati grezzi allo stesso modello, che decide se proseguire, fare una domanda all’utente o rispondere.

• Il ciclo si ferma quando il modello risponde o raggiunge un budget; dopo la risposta può girare un controllo opzionale di obiettivo o un verificatore.
• Il modello scrive il piano nel contesto al primo turno e lo rivede man mano. Chi pianifica è anche chi esegue, quindi può cambiare piano a metà turno.
• L’ordine delle operazioni e le procedure di dominio passano nelle skill. I vincoli rigidi, come validazioni e approvazioni, e ciò che emerge a metà conversazione, come la memoria, passano nei tool.
• Il codice resta per ciò che è economico e quasi sempre rilevante, ad esempio un passo di entity resolution, e per le parti meccaniche dentro i tool.
• I tool vanno raggruppati per intento dell’utente, non uno per API: oltre le 30-50 definizioni nel prompt di sistema la scelta tende a peggiorare. Precondizioni e permessi per utente stanno nel tool, che restituisce un rifiuto leggibile dal modello.

Le quattro skill del kit

Le skill Claude API che il kit mette in sequenza:

• /claude-api build-eval crea un primo set di eval end-to-end, gestito dal team centrale, oppure piccoli eval da distribuire insieme a ogni skill;
• /claude-api prompt-audit segnala nei prompt, nelle skill e nelle descrizioni dei tool le istruzioni scritte per modelli più vecchi e propone le correzioni come diff, per trovare regole che oggi rendono l’agente più lento o rigido;
• /claude-api hillclimb migliora un’app in modo iterativo rispetto a un eval esistente; Anthropic lo indica per il confronto tra versione inglobata e subagente, per vedere se la prima eguaglia o batte il secondo;
• /claude-api cost-optimize profila dove vanno le chiamate e propone risparmi, come prompt caching, meno token in ingresso e in uscita, livello di effort e scelta del modello, una modifica alla volta.

Quando i subagenti restano la scelta giusta

Anthropic non li archivia. Li indica come adatti quando un singolo ciclo mostra un calo di prestazioni misurabile per eccesso di contesto, quando servono compiti in parallelo con finestre fresche da scartare, o quando un solo agente sceglie male i tool o il prompt contiene istruzioni in conflitto. Tra i buoni candidati cita percorsi di ricerca indipendenti, componenti con interfacce pulite e verifiche black-box.

Il design a singolo agente, avverte l’azienda, richiede disciplina: un prompt di sistema curato, descrizioni di skill e tool che scattano al momento giusto, una gestione deliberata di contesto, memoria e note. Propone che un piccolo team centrale possieda qualità end-to-end e prompt di sistema, vagliando ogni nuovo tool ed eval.

Il rischio è documentato dalla stessa Anthropic. In un agente di supporto di prova, inglobare un subagente in un altro ha ridotto la latenza ma ha rotto un processo che prima passava: l’agente principale rispondeva da solo con il tool di ricerca ordine, senza chiedere la data di consegna allo specialista delle spedizioni. Per questo Anthropic consiglia di guardare quali task cambiano esito, non solo il punteggio finale, e di ripetere ogni task più volte: il difetto è comparso in una sola esecuzione su due.

Come procedere, a tappe

1. Costruire un piccolo eval end-to-end: secondo Anthropic bastano 10 esempi golden. Deve avere un task per ogni catena di agenti usata in produzione e per ogni regola che l’agente non deve violare.
2. Come primo passo senza riscritture, far chiamare i subagenti come tool dall’agente principale, che continua a parlare con l’utente. L’handoff completo è raccomandato solo se il subagente deve parlare direttamente con l’utente. Restano però prompt, contesto, team ed eval separati, riassunti con perdita di informazioni e cicli annidati che aggiungono latenza.
3. Inglobare i subagenti uno alla volta, partendo dai più usati e da quelli accoppiati, cioè che si concatenano, toccano gli stessi dati o vengono chiamati insieme. I prompt diventano skill, le chiamate API diventano tool MCP.
4. Confrontare l’eval con e senza subagente. La regola di Anthropic: tenerlo come subagente solo se la versione inglobata ottiene un punteggio peggiore, poi ripetere.

Leggi anche

• Claude Code su GitHub nel cloud: sessione, pull request e teleport