Se avete costruito un agente su Claude Platform con una dozzina di subagent specializzati, probabilmente state già sentendo il peso. Latenza che si accumula, contesto che si perde nei passaggi, ogni team che aggiunge la sua riga al prompt fino a ottenere quello che in Anthropic chiamano ‘il Frankenprompt’. Per questo il team Applied AI ha iniziato a smontare questa architettura — e a scoprire che un singolo agente con skill spesso funziona meglio.
Il pattern è familiare: un classificatore di intent, una pipeline di ragionamento fissa, bucket per segmenti utente, branch di raccomandazione separati, e sopra un orchestratore multi-agente. Il feedback che Anthropic riceve sempre più spesso? Questa struttura fa un lavoro che il modello non ha più bisogno che qualcuno faccia per lui. Un system prompt chiaro, 4-5 tool essenziali per i dati, e guardrail fermi in output coprono la maggior parte dei casi d’uso.
Quando i subagent diventano una copia dell’organigramma
Le grandi aziende vogliono un agente che unisca prodotti e capacità in un’unica interfaccia cliente. Ogni capacità appartiene a un team diverso, quindi la soluzione che sembra più semplice è: ogni team costruisce il suo agente, poi un team centrale costruisce un orchestratore sopra. Struttura orchestratore-subagent, oppure un singolo agente con specialist agent esposti come MCP tool.
Il risultato? Centinaia di subagent sovrapposti senza standard condivisi. Context management che deve decidere cosa scambiare tra agenti, perdendo dettagli a ogni passaggio. Eval locali e non verificati che ogni team aggiunge per il proprio subtask, senza che nessuno possieda o mantenga il set completo. E latenza: un cliente che ha testato il proprio harness multi-agente contro un loop singolo ha visto un runtime circa 2x più veloce con il secondo.
Questo non significa che i subagent siano inutili. Vanno usati quando un singolo loop incontra degrado misurabile delle prestazioni per sovraccarico di contesto, quando più task devono essere affrontati in parallelo con context window fresche che possono essere scartate a task completato, o quando un agente singolo fatica a scegliere i tool appropriati o ci sono istruzioni in conflitto nel prompt di sistema.
Ma troppo spesso le aziende assegnano a ogni team o tipo di problema il proprio subagent. L’architettura dell’agente diventa una copia dell’organigramma — Conway’s law al lavoro.
Progressive disclosure: skill e tool quando servono davvero
L’alternativa che Anthropic sta esplorando nei deployment enterprise è la progressive disclosure via skill e via tool search: l’agente vede descrizioni brevi di skill e tool, che vengono caricati completamente solo quando necessari.
Tre motivi per cui questo approccio funziona:
Contesto condiviso produce risposte migliori. Per agenti che girano più a lungo, vogliamo che il contesto di vari task diversi stia nella context window principale. Un agente che ha visto il risultato di ogni step precedente può connetterli, il che porta a output più ricchi e insight migliori rispetto a un set di riassunti restituiti da subagent. Significa anche meno context window e meno handoff che perdono informazioni.
La progressive disclosure previene il context bloat. Questa tecnica permette ai team di costruire agenti singoli capaci di compiere una vasta varietà di task senza caricare tutto il contesto in un system prompt lungo. Rimuove il motivo principale per cui i team prima dividevano il lavoro tra subagent. Anthropic ha ridotto il system prompt di Claude Code per i modelli più avanzati di oltre l’80% — tagli che includevano progressive disclosure di skill e tool.
I modelli sono più capaci. A partire da Opus 4.5, i modelli gestiscono molto di più in un singolo loop di quanto la maggior parte dei team si aspettasse. Non puoi disattivare il thinking su Opus 5.5 e Fable 5.1, e i modelli recenti narrano sempre più il loro progresso e controllano il proprio lavoro mentre procedono, rendendo ridondanti alcuni elementi dell’harness. Ogni nuovo modello permette di spostare più decisioni dall’harness al modello stesso. Un loop più semplice è anche più facile da portare al modello successivo.
Come ripiegare i subagent nel loop principale
Molti team hanno già un orchestratore e un set di specialist agent in produzione. Il design a loop singolo che Anthropic suggerisce ha questa forma: un modello e una context window che eseguono un tool loop aperto, con limiti — budget di turn e costi, write gate — settati nell’harness.
A ogni turn, il modello emette un batch di tool call. L’harness li esegue in parallelo e restituisce risultati grezzi allo stesso modello, che decide il passo successivo: un altro batch, una domanda all’utente, o una risposta. Il loop si ferma quando il modello risponde o raggiunge un budget. Un goal o verifier check può opzionalmente girare dopo la risposta.
Il modello scrive il suo piano in contesto al primo turn e lo rivede man mano che arrivano i risultati. Questo è il cambiamento principale rispetto al setup orchestratore-specialist: il modello che scrive il piano è anche quello che lo esegue, quindi può cambiarlo a metà turn.
Il contesto viene ancora caricato, ed è gestito dall’agente stesso. Un code step che riscrive il piano da un catalogo di regole non serve più, dato che il modello decide ogni step. Ordinamento e procedura di dominio si spostano nelle skill. Limiti rigidi — validazione, approval gate — e qualsiasi altra cosa emerga a metà conversazione — ad esempio memory lookup — si spostano nei tool.
Task-completion eval: il primo passo
Prima di ripiegare qualsiasi subagent, serve un eval set che possa aiutarti a determinare se ha senso farlo. La struttura che ha funzionato: un set end-to-end condiviso, posseduto da un team centrale, più eval set più piccoli spediti con ogni skill dal team che la possiede. Anche un set di 10 golden example è sufficiente per iniziare.
Valutare il messaggio finale dell’agente contro una rubrica è un buon punto di partenza per tracciare la qualità della risposta. Finché hai ancora un orchestratore, dovresti anche tracciare la routing accuracy — ha scelto il subagent giusto? Una volta ripiegato un subagent, controlla invece se l’agente ha caricato la skill giusta o chiamato il tool giusto.
Ridurre i subagent nel tempo
Evolvere verso un loop singolo significa ripiegare i subagent in tool e skill, fondendoli, chiamandoli come tool, o sostituendoli con skill e tool.
Combinare domain agent. Costruisci un piccolo eval end-to-end prima del primo merge. Poi ripiega partendo da shared context, iniziando dai subagent con più utilizzo. Fondi specialist che si concatenano sull’output l’uno dell’altro, toccano gli stessi dati, o sono spesso chiamati insieme. Se una quota significativa del traffico di produzione è uno specialist seguito da un secondo, sono una coppia strettamente accoppiata — candidata a fondersi in un domain agent.
Subagent chiamati come tool. Quando una delle tre condizioni sopra si applica e mantieni un subagent, fallo chiamare come tool dall’agente principale così questo può continuare a tenere la conversazione con l’utente. Anthropic raccomanda un handoff completo, dove il subagent prende il controllo della conversazione, solo quando deve parlare direttamente all’utente. Tutto il resto può essere una skill più tool nel loop principale.
Ripiegare subagent via skill e tool. Ripiega i subagent nell’agente principale uno alla volta trasformando i prompt di ognuno in skill e le API call in MCP tool. Confronta le performance dell’eval con e senza il subagent, poi decidi quale mantenere.
Quando confronti, non guardare solo lo score finale — guarda quali task sono cambiati. Quando Anthropic ha testato questo su un sample support agent, ripiegare un subagent in un altro ha abbassato la latenza, ma ha anche rotto un processo che prima passava: l’agente principale teneva l’order lookup tool e rispondeva da solo, senza chiedere allo shipping specialist la data di consegna.
Come più team possono contribuire a un singolo agente
Il ragionamento di dominio può essere recuperato da knowledge base, skill, e MCP tool. I singoli team possono spostare la loro ownership da agenti a skill e tool, con un piccolo team centrale che mantiene ownership del system prompt e della qualità end-to-end — verificando nuove skill, tool, ed eval prima che vengano spediti.
MCP tool sono la scelta giusta quando l’agente deve compiere un’azione, leggere dati live da un sistema, o restituire un risultato in una forma fissa. Anthropic raccomanda tool raggruppati per user intent — non un tool per API — perché oltre 30-50 tool definition nel system prompt la scelta del tool tende a degradare.
Skill sono la scelta giusta quando l’agente deve sapere come un team fa il lavoro: gli step, le regole, e le decisioni di giudizio che il prompt di un specialist subagent conteneva prima.
Knowledge base sono la scelta giusta per materiale di riferimento che l’agente ha bisogno solo a volte. Fatti e materiale di riferimento — policy, definizioni di metriche, specifiche di prodotto — possono stare dietro un search o lookup tool che il modello chiama, oppure essere spediti come file di riferimento dentro una skill.
Tool per accelerare il lavoro
Anthropic ha rilasciato un set di skill della Claude API che coprono la maggior parte del lavoro descritto sopra. Il migration kit concatena queste skill in un workflow guidato per valutare e spostare sistemi multi-agente a un loop singolo. Include una demo che puoi provare prima di eseguirlo sulla cosa reale:
/claude-api build-eval crea un primo set end-to-end posseduto dal team centrale o piccoli eval che ogni team spedisce con la sua skill.
/claude-api prompt-audit segnala istruzioni scritte per modelli più vecchi nei tuoi prompt, skill, e descrizioni tool e propone fix come diff.
/claude-api hillclimb migliora iterativamente un’app contro un eval esistente. Utile per il confronto ‘ripiegato vs mantenuto’.
/claude-api cost-optimize profila dove vanno le tue call e propone risparmi da opzioni come prompt caching, trimming di token input e output non necessari, effort, e scelta del modello.
Man mano che i modelli evolvono, le linee guida sulle best practice evolvono con loro. Il che rende qualsiasi architettura meno importante del principio dietro: misura, cambia una cosa alla volta, e mantieni ciò che regge. Costruisci un piccolo eval end-to-end, ripiega un subagent, e mantienilo come subagent solo se la versione ripiegata performa peggio. Poi ripeti.
