Chiedi al tuo assistente AI di fare una ricerca sul prodotto di un concorrente, riassumere i risultati, redigere un documento comparativo e inviarlo via email al tuo team. Un singolo agente può fare ciascuno di questi passaggi — ma farli bene, in sequenza, mantenendo il contesto su tutti e quattro i compiti, spinge contro i limiti di ciò che una singola sessione di agente gestisce con disinvoltura. La finestra di contesto si riempie. L'agente perde traccia dei passaggi precedenti. La qualità dell'output finale degrada perché il modello sta gestendo troppe cose contemporaneamente.
Questo è il problema che gli swarm di agenti risolvono. Invece di un agente che fa tutto, un agente coordinatore suddivide il compito in sotto-compiti e delega ciascuno a un agente specializzato. L'agente di ricerca cerca sul web e restituisce risultati strutturati. L'agente di scrittura prende quei risultati e redige il documento. L'agente email invia il risultato. Ogni agente opera nel proprio container, con la propria finestra di contesto, concentrato su una cosa sola.
L'idea non è nuova — CrewAI e AutoGen esplorano pattern multi-agente da oltre un anno. Ciò che distingue l'approccio di NanoClaw è che ogni agente nello swarm gira nel proprio container isolato, il che significa che le garanzie di sicurezza e isolamento che si applicano alle conversazioni con un singolo agente si estendono automaticamente ai workflow multi-agente.
Come funzionano gli swarm in NanoClaw
L'architettura a swarm di NanoClaw è costruita su una primitiva semplice: un agente può generare altri agenti. Quando Claude Code gira all'interno di un container, uno degli strumenti disponibili è la delega ad agenti — la capacità di descrivere un sotto-compito e far sì che NanoClaw avvii un nuovo container per gestirlo. L'agente padre riceve il risultato quando l'agente figlio completa.
L'orchestrazione avviene naturalmente attraverso il ragionamento di Claude. Non devi definire un grafo di workflow né configurare ruoli degli agenti in un file YAML. Descrivi cosa vuoi, e Claude decide se gestirlo direttamente o delegare parti a sotto-agenti. La decisione si basa sullo stesso ragionamento che rende Claude bravo a scomporre problemi complessi — riconosce quando un compito ha componenti indipendenti che beneficerebbero di attenzione focalizzata.
In pratica, questo appare come un albero di container. Il container radice riceve il tuo messaggio, decide che ha bisogno di ricerca web e scrittura di documenti, genera due container figli, attende i loro risultati e sintetizza una risposta finale. Ogni container figlio ha il proprio contesto CLAUDE.md, il proprio workspace montato e il proprio set di strumenti. L'agente di ricerca ha la navigazione web abilitata; l'agente di scrittura ha accesso in scrittura al workspace condiviso. Nessuno dei due può accedere al contesto o agli strumenti dell'altro.
Perché l'isolamento tramite container è importante per gli swarm
La maggior parte dei framework multi-agente esegue tutti gli agenti nello stesso processo. Gli agenti di CrewAI condividono un runtime Python. Gli agenti di AutoGen condividono un thread di conversazione. Funziona per le demo, ma crea problemi su scala che sono difficili da risolvere a posteriori.
Il primo problema è il raggio d'esplosione. Se un agente in uno swarm incontra una prompt injection — un sito web malevolo che tenta di dirottare il comportamento dell'agente — l'iniezione è contenuta in quel singolo container. Non può influenzare l'agente padre, non può accedere ai contesti degli altri agenti figli e non può leggere la cronologia della conversazione dell'utente originale. Il container compromesso viene smontato quando completa, e l'agente padre riceve qualsiasi output abbia prodotto (che il padre può valutare per qualità prima di usare).
Il secondo problema è la contesa delle risorse. Gli agenti in un processo condiviso competono per la stessa finestra di contesto, la stessa memoria e la stessa CPU. In NanoClaw, ogni container ha le proprie risorse. Un agente di ricerca che naviga pagine web pesanti non rallenta un agente di scrittura che sta redigendo un documento. I container girano concorrentemente su thread separati, e la gestione delle risorse dell'host si occupa dello scheduling.
Il terzo problema è lo scoping delle credenziali. Un agente di ricerca ha bisogno di accesso web ma non dovrebbe avere permessi di scrittura su file. Un agente di gestione file ha bisogno di accesso al disco ma non dovrebbe avere accesso web. In un framework a processo condiviso, applicare questi confini richiede controlli di permesso a livello applicativo che possono essere aggirati. In NanoClaw, i confini sono mount dei container — l'agente di ricerca letteralmente non può scrivere su disco perché nessun percorso scrivibile è montato nel suo container.
Pattern pratici degli swarm
I pattern che emergono dall'uso reale sono più interessanti dell'architettura teorica. Il più comune è il pattern ricerca-e-sintesi: un agente padre genera 3-5 agenti di ricerca per investigare diversi aspetti di una domanda in parallelo, raccoglie i loro risultati e produce una risposta sintetizzata più approfondita di quanto un singolo agente potrebbe produrre in un solo passaggio.
Il secondo pattern comune è bozza-e-revisione. Un agente scrive una prima bozza, poi genera un agente revisore con istruzioni di criticarla. Il feedback del revisore torna all'agente originale (o a un nuovo agente di redazione) per la revisione. Questo produce un output notevolmente migliore rispetto alla generazione in un singolo passaggio, perché l'agente revisore ha una finestra di contesto fresca e può valutare la bozza senza il carico cognitivo di averla scritta.
Il terzo pattern è la specializzazione degli strumenti. Alcuni compiti richiedono strumenti costosi o rischiosi — navigazione web, esecuzione di comandi shell, modifiche al filesystem. Un agente padre può delegare queste operazioni ad agenti figli con accesso specifico agli strumenti, mantenendo il proprio contesto pulito e i propri permessi minimi. Il padre non tocca mai direttamente il filesystem o la rete; elabora solo i risultati che gli agenti figli restituiscono.
I limiti degli swarm
Gli swarm non sono gratuiti. Ogni agente figlio è una chiamata API Claude separata, il che significa costi di token separati. Uno swarm che genera cinque agenti di ricerca costa circa cinque volte tanto quanto un singolo agente che fa tutta la ricerca. Per domande semplici — "che tempo fa?" o "traduci questa frase" — gli swarm sono puro overhead.
Anche la latenza si accumula. Anche con l'esecuzione parallela, l'agente padre deve attendere il figlio più lento prima di poter sintetizzare i risultati. Uno swarm di cinque agenti dove uno impiega 30 secondi per navigare un sito web lento significa che l'utente attende 30 secondi più il tempo di sintesi, indipendentemente da quanto siano stati veloci gli altri quattro.
NanoClaw gestisce questo in modo pragmatico. Claude decide quando usare gli swarm in base alla complessità del compito — le domande semplici ottengono risposte dirette, le richieste complesse multi-parte vengono delegate. L'utente non configura il comportamento dello swarm; fa semplicemente domande, e il sistema scala il suo approccio per adattarsi alla complessità. L'obiettivo non è usare gli swarm ovunque — è usarli dove producono genuinamente risultati migliori di quanto un singolo agente potrebbe fare.
Il futuro multi-agente non riguarda la sostituzione dei singoli agenti. Riguarda il dare ai singoli agenti la capacità di chiedere aiuto quando ne hanno bisogno, in un modo sicuro, isolato e trasparente. Il modello container-per-agente di NanoClaw rende questo possibile senza i compromessi di sicurezza che derivano dall'esecuzione di più agenti in un ambiente condiviso.