---
type: Comparison
title: "Sub-agenti ricorsivi vs team di sub-agenti piatti (2026): annidamento profondo o orchestrazione prevedibile?"
description: "Claude Code 2.1.172 consente cinque livelli di annidamento. Sub-agenti ricorsivi vs team piatti a confronto: costi, tracciabilità, profondità di ragionamento e rischio 2026."
resource: "https://www.contextstudios.ai/it/confronto/recursive-sub-agents-vs-flat-sub-agent-teams"
category: approach
language: it
timestamp: "2026-06-11T11:06:58.958Z"
---

# Sub-agenti ricorsivi vs team di sub-agenti piatti (2026): annidamento profondo o orchestrazione prevedibile?

Claude Code 2.1.172 (giugno 2026) ha introdotto il più grande cambiamento finora nella sua architettura di agenti: i sub-agenti possono ora avviare propri sub-agenti, fino a cinque livelli di profondità. Fino a questa versione la gerarchia era deliberatamente piatta — una sessione principale delegava ai worker, e quei worker non potevano annidarsi. Il modello piatto è tuttora pienamente supportato, il che lascia ai team una vera scelta architetturale: lasciare che gli agenti si ramifichino in alberi profondi e auto-organizzati, oppure mantenere un singolo orchestratore che distribuisce verso un pool piatto di specialisti. Il compromesso contrappone la capacità al controllo. I sub-agenti ricorsivi possono scomporre problemi aperti a profondità arbitraria, ma fanno lievitare il costo in token e rendono più difficile la tracciabilità. I team piatti sono prevedibili, facili da debuggare e più economici, ma limitano quanto a fondo un singolo filo di ragionamento può auto-organizzarsi. Questo confronto valuta i due approcci su profondità di scomposizione, costo, tracciabilità, potenza di ragionamento, rischio di escalation, parallelismo, specializzazione e maturità in produzione.

## Comparison Factors

| Factor | Sub-agenti ricorsivi | Team di sub-agenti piatti | Winner |
|--------|------|------|--------|
| Profondità di scomposizione del compito | I sub-agenti avviano propri sub-agenti fino a 5 livelli e scompongono i problemi aperti a profondità arbitraria | Limitato a un solo livello — un singolo orchestratore distribuisce ai worker che non possono annidarsi | a |
| Costo in token e prevedibilità del budget | Il contesto viene ereditato a ogni livello e amplifica il moltiplicatore di circa 15x dei token multi-agente | Spesa prevedibile e limitata — ogni worker viene eseguito una volta sotto l'orchestratore | b |
| Tracciabilità e debugging | Gli alberi profondi diventano catene opache; difficile risalire a quale livello ha prodotto un risultato | Grafo di nodi chiaro e piatto, con evidenti punti di ispezione e intervento | b |
| Ragionamento multi-fase più arduo | Eccelle quando una sotto-attività deve scomporsi ulteriormente durante l'esecuzione | Solido per il lavoro parallelo, ma un singolo worker non può auto-organizzarsi più in profondità | a |
| Rischio di escalation e raggio d'impatto | Richiede limiti di arresto espliciti, altrimenti un ramo può entrare in ciclo e bruciare il budget | Limitato per progettazione — nessuna esplosione ricorsiva, la gerarchia resta prevedibile | b |
| Throughput parallelo | Si ramifica in profondità; molti rami vengono eseguiti, ma il costo di coordinamento cresce | Si ramifica in ampiezza; worker indipendenti vengono eseguiti in modo pulito e simultaneo | tie |
| Specializzazione e routing del modello per nodo | Ogni nodo annidato può instradare verso un modello diverso (Haiku/Sonnet/Opus) adatto alla sua sotto-attività | I worker instradano per ruolo, ma la specializzazione è larga un livello, non profonda | a |
| Maturità in produzione e prevedibilità | Nuovo in 2.1.172 — potente ma meno collaudato in produzione | La scelta predefinita documentata e deliberata; prevedibile e difficile da rompere | b |

## Key Statistics

- Il sistema di ricerca multi-agente di Anthropic usa circa 15 volte più token di una chat a singolo agente — il moltiplicatore di costo centrale ogni volta che i sub-agenti si ramificano o si annidano
- La stessa architettura multi-agente ha ottenuto il 90,2% di risultati migliori rispetto a un singolo agente nella valutazione interna di Anthropic su compiti di ricerca — il vantaggio che può giustificare il costo in token
- Claude Code 2.1.172 (giugno 2026) consente ai sub-agenti di avviare propri sub-agenti fino a 5 livelli; prima di questa versione l'annidamento era bloccato e la gerarchia deliberatamente piatta
- Con la media di circa 13 $ per sviluppatore al giorno riportata da Anthropic, eseguire 5 agenti contemporaneamente può portare la spesa giornaliera oltre i circa 50 $, e 10 agenti paralleli consumano la quota del piano 10 volte più velocemente
- Gli addetti ai lavori riferiscono di sub-agenti che consumano oltre 25.000 token all'avvio prima di svolgere qualsiasi lavoro — un costo di contesto fisso che si moltiplica a ogni livello annidato
- Prima di 2.1.172, Claude Code documentava i sub-agenti come rigorosamente non annidabili — la gerarchia piatta era intenzionale per mantenere il sistema prevedibile, stabilendo i team piatti come riferimento di stabilità

## Choose Sub-agenti ricorsivi When

- I suoi problemi sono profondi e aperti, dove un worker deve davvero avviare propri assistenti durante il compito
- Affronta i refactoring o le ricerche multi-fase più difficili, dove la profondità di ragionamento conta più dell'ampiezza
- La qualità della risposta domina la decisione e può permettersi il moltiplicatore di token di circa 15x
- Ha impostato limiti di profondità rigorosi, budget di token e limiti di arresto per contenere la ricorsione incontrollata

## Choose Team di sub-agenti piatti When

- Gestisce flussi di produzione in cui costo e latenza prevedibili contano di più
- Ha bisogno di tracciabilità chiara e di punti di intervento umano agevoli in ogni passaggio
- I suoi compiti si parallelizzano naturalmente in sotto-attività indipendenti e ben delimitate
- Vuole la scelta predefinita collaudata, difficile da rompere e facile da debuggare

## Verdict

Non c'è un vincitore universale — l'asse contrappone il tetto di capacità al controllo operativo. I sub-agenti ricorsivi sono la scelta più forte per i compiti più difficili e aperti, dove un worker deve davvero avviare propri assistenti e la profondità di ragionamento conta più dell'ampiezza. Ma ereditano il contesto a ogni livello, amplificano il moltiplicatore di circa 15x dei token che i sistemi multi-agente già comportano e trasformano l'esecuzione in una catena opaca, difficile da debuggare e soggetta a cicli senza limiti rigorosi. I team di sub-agenti piatti restano la scelta predefinita in produzione per buoni motivi: costo prevedibile, tracciabilità chiara, intervento umano agevole e una gerarchia difficile da rompere. Lo schema pragmatico che Context Studios predilige: mantenere i team piatti come impostazione predefinita, instradare ogni nodo al modello capace più economico e ricorrere alla ricorsione solo per i pochi compiti il cui tetto di qualità — Anthropic ha misurato il 90,2% di risultati migliori del multi-agente rispetto al singolo agente — giustifica il costo e la perdita di visibilità.

## FAQ

**Q: Cosa è cambiato in Claude Code 2.1.172 per i sub-agenti?**
A: Prima di 2.1.172, i sub-agenti non potevano avviare propri sub-agenti; la gerarchia era deliberatamente piatta (sessione principale verso worker) per mantenere un comportamento prevedibile. Claude Code 2.1.172 (giugno 2026) consente ai sub-agenti di avviare sub-agenti fino a 5 livelli, abilitando per la prima volta l'orchestrazione ricorsiva. I team piatti funzionano ancora e restano la scelta più sicura per la maggior parte dei carichi di produzione.

**Q: I sub-agenti ricorsivi sono più costosi dei team piatti?**
A: In genere sì. Il sistema di ricerca multi-agente di Anthropic consuma circa 15 volte più token di una chat a singolo agente, e la ricorsione amplifica questo perché ogni livello eredita contesto e costo di avvio — gli addetti ai lavori riferiscono oltre 25.000 token prima di qualsiasi lavoro reale. I team piatti sono più prevedibili. La ricorsione conviene solo quando il guadagno di qualità (Anthropic ha misurato il 90,2% di risultati migliori) giustifica il costo.

**Q: Quando dovrei usare un team di sub-agenti piatto invece dell'annidamento?**
A: Usi i team piatti quando i compiti si dividono in modo pulito in sotto-attività indipendenti, quando servono costo e latenza prevedibili e quando contano tracciabilità e intervento umano. Il modello piatto è la scelta predefinita documentata e collaudata; l'annidamento aggiunge potenza ma anche opacità e rischio di escalation, quindi lo riservi ai problemi che richiedono davvero profondità.

**Q: Come controllo i costi con i sub-agenti ricorsivi?**
A: Imposti limiti di profondità rigorosi (2.1.172 si ferma a 5 livelli) e budget di token, instradi ogni nodo al modello capace più economico (Haiku per le letture, Sonnet per l'implementazione, Opus per il ragionamento difficile) e aggiunga limiti di arresto espliciti affinché un ramo non possa entrare in ciclo. Riservi la ricorsione profonda ai pochi compiti che ne hanno davvero bisogno.