3
L'Architettura dei Team: Manager, Worker e Specialisti 5:12 Miles: Ecco, Eli, parliamo proprio di questo. Perché un solo agente non basta? Se ho GPT-4 o Claude 4.5 con una finestra di contesto enorme, perché non posso semplicemente dargli un libro intero e dirgli "fai tutto tu"?
5:27 Eli: Perché la ricerca, specialmente quella condotta dal team di Chroma, ha mostrato un fenomeno inquietante chiamato "context rot". Anche se un modello può leggere centomila token, la sua capacità di recuperare informazioni specifiche diminuisce drasticamente all'aumentare del rumore. Se nascondi un "ago" in un pagliaio troppo grande, l'IA inizia a confondersi o a dare risposte vaghe.
5:48 Miles: Quindi la soluzione è dividere per governare. Invece di un solo agente sovraccarico, creiamo una gerarchia.
5:55 Eli: Esattamente. Qui entrano in gioco framework come CrewAI o LangGraph. Immagina di voler creare un report di Business Intelligence. Invece di un solo agente, crei un "Equipaggio"—una Crew. C'è l'Agente Ricercatore, che ha solo strumenti per navigare sul web. C'è l'Agente Analista, specializzato nel leggere dati strutturati. E c'è l'Agente Scrittore, che non cerca nulla ma riceve le informazioni dagli altri due e le trasforma in un report perfetto.
6:21 Miles: È affascinante perché ogni agente ha il suo "ruolo", il suo "background" e il suo "obiettivo" specifico. È come un gioco di ruolo, ma per l'automazione aziendale. E il bello è che questi agenti possono parlarsi!
3:21 Eli: Proprio così. Esistono diversi pattern di collaborazione. C'è il modello "Hub-and-Spoke", dove un Manager centrale assegna i compiti e raccoglie i risultati. È perfetto se vuoi un controllo totale e un output coerente. Ma c'è anche il modello "Swarm", o sciame, dove gli agenti operano come pari. Si scambiano messaggi, si correggono a vicenda e arrivano a una soluzione in modo quasi... organico.
6:58 Miles: Ma come si coordinano tecnicamente? Se l'Agente A finisce il suo lavoro, come fa l'Agente B a saperlo?
7:04 Eli: Usiamo delle "Shared Task List", Miles. Immagina un file Markdown o un database condiviso dove ogni agente segna lo stato del suo compito: "In corso", "Completato", "Bloccato". Se l'Agente Tester vede che l'Agente Sviluppatore ha segnato il codice come "Completato", si attiva automaticamente. In Claude Code, ad esempio, questo è gestito in modo nativo: gli agenti si mandano messaggi nelle loro "mailbox" digitali. Se il frontend ha bisogno della struttura delle API, manda un messaggio al backend: "Ehi, mi mandi lo schema JSON?". E il backend risponde.
7:36 Miles: Mi sembra di capire che la chiave sia la specializzazione. Se un agente deve fare troppe cose, diventa mediocre in tutto. Se invece gli diamo un set di strumenti limitato—diciamo massimo dieci strumenti per agente—le prestazioni rimangono altissime.
7:51 Eli: Hai centrato il punto! Se un caso d'uso richiede troppi strumenti, l'architettura corretta prevede di spezzarlo in due o più agenti. È una lezione che arriva direttamente dalla documentazione IBM sulla progettazione di agenti ad alte prestazioni. La modularità non è solo una buona pratica di programmazione, è una necessità biologica per l'intelligenza artificiale.
8:13 Miles: E per chi ci ascolta e usa Python, framework come LangGraph permettono di disegnare letteralmente questi flussi come se fossero dei grafi. Nodo A: Ricerca. Nodo B: Analisi. Se l'analisi fallisce, una freccia riporta al Nodo A per cercare meglio. È un controllo deterministico su un processo probabilistico.
8:32 Eli: Bellissima definizione! "Controllo deterministico su un processo probabilistico". È esattamente quello che serve alle aziende. Nessun CTO accetterebbe un sistema che "forse" fa la cosa giusta. Con i grafi di stato, puoi definire esattamente cosa deve succedere se l'IA incontra un errore o un'ambiguità. Puoi persino inserire un "Human-in-the-Loop"—un momento in cui l'agente si ferma e chiede: "Miles, ho trovato due opzioni, quale preferisci?".
8:59 Miles: Questo toglie molta ansia a chi teme che l'IA "scappi di mano". Ma c'è un altro aspetto tecnico che mi incuriosisce: come fanno questi agenti a lavorare sugli stessi file senza fare un pasticcio? Se due agenti scrivono sullo stesso file contemporaneamente, è un disastro, no?
9:15 Eli: Grande domanda! La soluzione che usano i professionisti sono i "Git Worktrees". Ogni agente lavora su una copia isolata del repository, su un suo branch dedicato. Solo quando il lavoro è finito e verificato, i rami vengono uniti. È la stessa disciplina che usano i team di sviluppatori umani, applicata alle macchine.