Sotto-agenti: come gestire una squadra di AI 👥
C’è qualcosa di irresistibile nell’idea di avere una squadra di agenti al lavoro mentre noi facciamo altro. Uno esplora, uno implementa, un altro controlla. La lavagna si riempie di frecce, il lavoro sembra moltiplicarsi e, per qualche minuto, anche la produttività.
Poi arriva il momento meno cinematografico: capire che cosa hanno fatto davvero.
La metafora della squadra è comoda, ma rischia di promettere più di quanto mantenga. Gli agenti non condividono automaticamente una comprensione del progetto, non si accorgono da soli di stare lavorando con presupposti incompatibili e non si assumono la responsabilità del risultato. Possono passarsi file e resoconti; la comprensione e il giudizio, invece, non si trasferiscono con la stessa facilità.
Più agenti, più coordinamento 🔀
Dividere il lavoro non lo fa sparire: cambia forma. Una parte diventa coordinamento, controllo delle sovrapposizioni, ricomposizione dei risultati. Se due agenti affrontano aspetti che sembrano separati ma non lo sono, il parallelismo produce varianti da riconciliare, non tempo guadagnato.
E anche quando i compiti sono davvero separabili, resta una domanda poco glamour: il beneficio vale il costo di spiegare, assegnare, aspettare e verificare? Per un lavoro piccolo, la risposta può essere un no molto efficiente. Aggiungere agenti perché è possibile non è una strategia; a volte è solo un modo sofisticato di moltiplicare le conversazioni.
Il parallelismo accelera il lavoro indipendente. Non rende indipendente ciò che non lo è.
La delega non trasferisce la responsabilità 🧭
Delegare è facile quando il compito è chiaro. Quello difficile è accorgersi che la chiarezza mancava: un risultato plausibile può nascondere un requisito interpretato male, un vincolo ignorato o una decisione architetturale presa senza che nessuno l’abbia davvero presa.
È qui che l’immagine del “lead agent” può trarre in inganno. Sembra un responsabile di squadra, ma non porta il peso delle conseguenze e non risponde a chi userà il software. Quel peso resta a chi ha deciso di delegare e poi integra il risultato. Se la revisione diventa un timbro automatico, non abbiamo costruito un team: abbiamo costruito una catena di produzione di plausibilità.
Quando vale la pena? 🤔
Non c’è un numero magico di agenti, né una regola secondo cui i task complessi vadano sempre spezzati. C’è una valutazione più concreta: le parti sono abbastanza autonome da poter avanzare senza negoziare continuamente? Il risultato di ciascuna si può controllare senza fidarsi del racconto dell’agente? E il tempo risparmiato supera quello necessario a tenere insieme il lavoro?
Se la risposta è no, un solo agente — o una persona che chiarisce prima il problema — può essere la scelta più sensata. Non è un fallimento dell’automazione. È rifiutarsi di scambiare il numero di processi avviati per il valore prodotto.
La domanda interessante, allora, non è «quanti agenti posso mettere al lavoro?». È «quale parte del problema posso davvero separare, e chi si prende la responsabilità di ricomporla?».
La guida pratica al workflow multi-agente entra nel merito di delegazione, isolamento e verifiche. Qui basta tenere a mente il punto meno automatico di tutti: gli agenti possono spartirsi il lavoro; il giudizio sul lavoro resta nostro.
Riferimenti della serie 📚
- Multi-agente, CI/CD e spec-driven — la guida pratica a pattern e workflow multi-agente
- The repository is the contract — AGENTS.md come conoscenza condivisa
- Context engineering — il fondamento della gestione del contesto