**
Un'idea architetturale ampiamente diffusa nella comunità AI sta portando molti team fuori strada.
La Conclusione Prima di Tutto
Se stai pensando di assegnare a diversi Agenti AI i ruoli di "Product Manager", "Architetto" e "Ingegnere del Test", e farli collaborare scambiandosi documenti come in un'azienda—per favore, fermati.
Questo modello sembra intuitivo e logicamente valido, ma presenta difetti fondamentali dal punto di vista ingegneristico. Ancora più importante, nessuno dei tre grandi provider—Anthropic, OpenAI e Google—utilizza questo modello quando costruisce i propri sistemi di Agenti.
Non è una coincidenza.
Cos'è l'Architettura "Tre Dipartimenti e Sei Ministeri"?
Questa metafora si riferisce a una classe di idee di progettazione multi-agente molto popolari nella comunità, conosciute con nomi diversi in vari framework e articoli: agenti basati su ruoli, team virtuali, divisione del lavoro in stile CrewAI, o organizzazione in stile MetaGPT. Questo articolo le chiama collettivamente modello "Dipartimentalizzato".
Il modello centrale è: scomporre un compito complesso in diverse funzioni, con ogni Agente che interpreta un ruolo—PM per i requisiti, Tech Lead per l'architettura, Dev per l'implementazione e QA per i test. I compiti fluiscono tra gli Agenti come in una catena di montaggio.
Questo modello è fantastico su un diagramma. Soddisfa l'intuizione umana della "divisione del lavoro" e rende il concetto di "team AI" concreto e spiegabile. Framework come CrewAI hanno accumulato molti utenti proprio per questo.
Il problema è che risolve i colli di bottiglia umani, non quelli dell'AI.
Perché Questa Analogia è Fondamentalmente Sbagliata
Gli esseri umani hanno bisogno della divisione del lavoro perché:
- Una singola persona ha un'attenzione limitata e non può elaborare tutte le informazioni contemporaneamente.
- Gli esseri umani hanno barriere professionali e alti costi di apprendimento/cambio.
- Gli esseri umani hanno bisogno di interfacce per coordinarsi tra loro.
Ma le caratteristiche degli LLM sono completamente diverse:
- Lo stesso modello può scrivere sia PRD che codice; non esistono "confini professionali".
- Il collo di bottiglia per i modelli non è la capacità di attenzione, ma la profondità di ragionamento e l'integrità delle informazioni.
- I modelli non hanno "cultura" e "intesa tacita" per compensare la perdita di informazioni.
Etichettare un Agente come "Product Manager" non lo rende più professionale—lo rende riluttante a superare i confini. Un Agente confinato in un ruolo di "Ingegnere del Test" potrebbe ignorare un problema architetturale perché "non è di mia competenza." Il ragionamento più prezioso avviene spesso ai confini, e il modello Dipartimentalizzato sigilla questa possibilità a livello di sistema.
Il role-playing crea confini fittizi. Questo è il primo problema.
Il Secondo Problema: Le Informazioni Muoiono Durante il Transito
Nel modello Dipartimentalizzato, l'Agente A produce un documento e lo passa all'Agente B.
Questo processo trasmette conclusioni, non il processo di ragionamento.
B riceve il documento, lo re-interpreta e ricostruisce il contesto. L'intento originale decade, le assunzioni implicite vanno perse, e ogni passaggio accumula errori. Più lungo è il flusso di lavoro, più il risultato finale diventa "localmente corretto ma globalmente derivato"—ogni nodo sembra ragionevole, ma l'insieme si è allontanato dall'obiettivo originale.
Le organizzazioni umane si affidano a riunioni, cultura e comunicazione informale per compensare questa perdita di informazioni. Gli Agenti non hanno questi meccanismi.
C'è una replica comune: Le soluzioni dei tre grandi provider (progress.txt, file spec, runbook) non implicano anche loro il "passaggio di file"? Qual è la differenza?
La differenza sta in chi scrive, per chi è scritto e come viene aggiornato.
Il flusso informativo dipartimentalizzato è un passaggio unidirezionale tra ruoli: A finisce e lo dà a B; B non guarda indietro, e A non sa come B ha usato il documento. Le informazioni vengono compresse in conclusioni, il processo di ragionamento viene perso e il passaggio è un punto di rottura.
I file di stato esterni sono log incrementali dello stesso compito: L'entità esecutrice aggiunge allo stesso record a ogni checkpoint, e la sessione successiva legge l'intera cronologia del compito, non la conclusione di output di un precedente "collega". La persona che scrive lo stato e quella che lo leggono sono lo stesso ruolo, solo in momenti diversi. Le informazioni non vengono "compresse e passate"; vengono "continuamente accumulate".
Questa differenza determina se la catena di ragionamento può rimanere continua tra le sessioni.
Un'enorme quantità di token viene sprecata in "file di passaggio" tra Agenti invece che nel ragionamento reale. Ottieni un sistema che simula il comportamento aziendale, non un sistema che risolve problemi.
Come Fanno Realmente i Tre Grandi Provider
È degno di nota che quando Anthropic, OpenAI e Google costruiscono i loro sistemi di Agenti di livello produttivo, i loro documenti ingegneristici non menzionano quasi mai il "role-playing" o la "divisione dipartimentale".
Anthropic: Ingegneria del Contesto + File di Stato Espliciti
Anthropic ha aggiornato il "Prompt Engineering" in "Ingegneria del Contesto": La domanda non è come scrivere un buon prompt, ma quale configurazione di token produce meglio il comportamento desiderato.
Quando hanno costruito i sistemi Claude Code e Research, la loro sfida principale era: gli Agenti devono lavorare in sessioni discrete, e ogni nuova sessione non ha memoria di ciò che è successo prima. La loro metafora sono gli "ingegneri turnisti"—ogni nuovo turno di ingegneri non sa nulla del lavoro del turno precedente.
La soluzione non è far interpretare agli Agenti ruoli diversi, ma:
- claude-progress.txt: Un registro di lavoro tra sessioni che l'Agente aggiorna alla fine di ogni sessione e legge all'inizio della successiva.
- Cronologia Git: Funge da ancoraggio di stato, registrando ogni modifica incrementale.
- Agente Inizializzatore: Viene eseguito solo nella prima sessione per configurare l'ambiente, espandere l'elenco delle funzionalità e scrivere il runbook per tutte le sessioni successive.
Intuizione chiave: La continuità della catena di ragionamento non si basa sul "ricordare" del modello; si basa su uno stato esterno esplicito per ancorarla.
Hanno anche scoperto che codificare rigidamente "assunzioni sulle capacità del modello" nell'harness è pericoloso. Sonnet 4.5 aveva "ansia da contesto"—tendeva a concludere prematuramente quando si avvicinava al limite di contesto, quindi hanno aggiunto un reset del contesto all'harness. Ma in Opus 4.5, questo comportamento è scomparso e il reset è diventato zavorra. Questo dimostra che l'harness deve evolversi con il modello; qualsiasi "soluzione permanente" è solo un compromesso ingegneristico per la fase attuale.
Nei sistemi di Ricerca multi-agente, l'architettura di Anthropic è orchestratore-lavoratore: un agente principale scompone i compiti e coordina i sotto-agenti, che esplorano direzioni diverse in parallelo, con i risultati che fluiscono all'agente principale per la sintesi. Hanno scoperto che il solo consumo di token spiegava l'80% delle differenze di prestazione—il valore dei multi-agenti non è la "divisione del lavoro", ma l'uso di più token per coprire uno spazio di ricerca più ampio.
C'è un punto di confusione qui: i sotto-agenti di Anthropic potrebbero sembrare "divisione del lavoro", ma l'essenza è diversa. La dipartimentalizzazione è una divisione funzionale—ruoli diversi gestiscono tipi diversi di lavoro (PM a Dev a QA). I sotto-agenti di Anthropic sono parallelismo funzionale—più agenti identici cercano direzioni diverse simultaneamente, non c'è "passaggio successivo", e tutti i risultati convergono allo stesso orchestratore. Il primo è una staffetta; il secondo è gettare una rete ampia.
OpenAI: Compattazione + Skills + File Spec Strutturati
I principi di OpenAI per i compiti a lungo orizzonte sono ancora più diretti: pianificare la continuità all'inizio del compito.
Nei loro esperimenti Codex, gli ingegneri hanno dato all'agente un file spec (congelando l'obiettivo per impedire all'agente di creare qualcosa di "impressionante ma nella direzione sbagliata"), gli hanno fatto generare un piano basato su milestone, e poi hanno usato un file runbook per dire all'agente come operare. Questo runbook è anche una memoria condivisa e un registro di audit.
Risultato: GPT-5.3-Codex ha funzionato per circa 25 ore ininterrottamente, completando un intero strumento di progettazione mantenendo la coerenza per tutto il tempo.
La compattazione lato server funge da primitiva predefinita, non da fallback di emergenza. Nei compiti multi-step, previous_response_id permette al modello di continuare a lavorare nello stesso thread invece di ricostruire il contesto ogni volta.
Hanno anche introdotto il concetto di Skills—set di istruzioni riutilizzabili e versionati montati in contenitori, dando agli agenti standard operativi stabili per compiti specifici. Questi non sono "ruoli"; sono strumenti e procedure operative, che è fondamentalmente diverso.
Google: Contesto da 1M + Sviluppo Guidato dal Contesto
La direzione di Google è quella di forzare la finestra: il contesto da 1 milione di token di Gemini è una chiara strategia di differenziazione. La loro logica è che tecniche precedentemente forzate come lo slicing RAG e lo scarto di messaggi vecchi possono essere sostituite da "metti tutto dentro" data una finestra abbastanza grande.
Ma ammettono che nemmeno questo è sufficiente. Google ha lanciato l'estensione Conductor per Gemini CLI, con un'idea centrale identica a quella di Anthropic: spostare l'intento del progetto fuori dalla finestra di chat e in file Markdown persistenti nel codebase. La filosofia: "Non affidarti a una cronologia chat instabile; affidati a file spec e plan formali."
Gemini 3 ha anche introdotto le Thought Signatures: salvare i nodi chiave della catena di ragionamento in sessioni lunghe per prevenire il "deragliamento del ragionamento"—il problema dell'incoerenza logica in contesti lunghi.
Quali Sono i Veri Principi Architetturali?
Dalle pratiche ingegneristiche di queste tre aziende, si possono estrarre diversi principi comuni:
La catena di ragionamento non può essere interrotta; può solo ramificarsi e fondersi. L'uso corretto dei multi-agenti non è una catena di montaggio, ma un agente principale che mantiene l'intento completo, con sotto-chiamate usate per approfondire sotto-problemi, e risultati che fluiscono all'agente principale, non all'agente successivo.
Stato esterno esplicito, non fare affidamento sulla memoria del modello. Che sia progress.txt, cronologia git, file spec o database—la forma non conta. Il principio è: i nodi chiave della catena di ragionamento devono essere esternalizzati in una memoria persistente.
Il valore dei multi-agenti è la copertura parallela, non la divisione del lavoro. La conclusione del sistema di Ricerca di Anthropic è chiara: i guadagni di prestazione derivano dallo "spendere più token", non da una "migliore divisione del lavoro". I multi-agenti sono adatti per compiti ampi—scenari che richiedono l'esplorazione simultanea di direzioni indipendenti. Non sono adatti per scenari che richiedono ragionamento continuo e profonda dipendenza dal contesto.
L'Agente Verificatore è un negatore, non un corridore di staffetta. Se si usano multi-agenti per il controllo qualità, il progetto corretto è avere un Agente che trovi specificamente problemi nel lavoro di un altro, piuttosto che "passare il risultato del lavoro". Test avversariali, non trasferimento in catena di montaggio.
Gli strumenti sono strumenti, non ruoli. Di quali strumenti doti un Agente (bash, I/O file, ricerca, esecuzione codice) è molto più importante di quale etichetta gli applichi. Gli strumenti determinano cosa un Agente può fare; le etichette di ruolo limitano solo ciò che è disposto a fare.
Perché il Modello "Dipartimentalizzato" è Popolare?
Perché è facile da spiegare.
"Questo Agente è il PM, quello è il QA"—chiunque può capirlo. Soddisfa il desiderio umano di spiegabilità dei sistemi AI e l'immaginazione del management di "AI che lavora come un team".
È anche facile da dimostrare. Disegnato come un diagramma di flusso con dipartimenti, frecce e passaggi, è molto intuitivo.
Ma essere facile da spiegare e dimostrare è diverso dall'essere ingegneristicamente valido.
Una ragione più profonda è che la maggior parte dei team che adottano questo modello non ha realmente affrontato il problema della "perdita di contesto durante il trasferimento multi-agente". I loro compiti potrebbero non essere abbastanza complessi, o il problema è mascherato da altri fattori. Una volta che la complessità del compito aumenta e il sistema inizia a mostrare errori "localmente corretti ma globalmente sbagliati", il problema viene esposto.
Consigli Pratici
Il miglior sistema multi-agente non assomiglia a un'azienda. Assomiglia più a più bozze di un pensatore—lo stesso cervello che espande il ragionamento attraverso diverse dimensioni e infine le fonde in una conclusione coerente.
Basandoti su questo principio:
Non chiederti "Di quanti Agenti ho bisogno?"; chiediti "Qual è la struttura delle dipendenze informative di questo compito?"
Se un compito richiede ragionamento continuo e alta dipendenza dal contesto (ad esempio, scrivere un documento di progettazione per una funzionalità complessa), un singolo Agente + una buona ingegneria del contesto è di solito superiore ai multi-agenti.
Se un compito richiede l'esplorazione simultanea di direzioni indipendenti (ad esempio, ricercare 10 concorrenti contemporaneamente), il parallelismo multi-agente è ragionevole—ogni sotto-agente ha un compito indipendente e il costo della perdita di informazioni è minimizzato.
Se un compito si estende su più sessioni, i file di stato esterni sono obbligatori. Un file di stato efficace dovrebbe contenere quattro tipi di informazioni:
- Obiettivo del Compito (Invariante, letto all'inizio della sessione per prevenire la deriva)
- Passaggi Completati (Aggiunti, non sovrascritti, per mantenere la cronologia completa)
- Stato Attuale (Sovrascritto per riflettere l'ultimo progresso)
- Insidie Note (Aggiunte per evitare di ripetere errori nella sessione successiva)
Questi quattro tipi di informazioni, mantenuti separatamente e combinati, forniscono il contesto completo necessario al "sé successivo".
Se aggiungi un passaggio di verifica, fai sì che l'unico compito dell'Agente Verificatore sia trovare problemi, non "prendere il testimone e continuare". Test avversariali, non trasferimento in catena di montaggio.
Infine: Le capacità dei modelli migliorano rapidamente. Le soluzioni alternative necessarie oggi nell'harness potrebbero diventare zavorra tra sei mesi. Anthropic lo ha già dimostrato—l'ansia da contesto di Sonnet 4.5 è scomparsa in Opus 4.5. Mantenere l'evolvibilità architetturale è più importante che scegliere un'"architettura perfetta".
La dipartimentalizzazione è un'illusione che fa stare bene ma è ingegneristicamente costosa. Il suo vero costo non è il fallimento diretto, ma il far degradare il tuo sistema in modi difficili da diagnosticare man mano che la complessità aumenta—dove ogni nodo "sembra funzionare", ma l'insieme sta derivando.
Quando trovi il problema, la catena di montaggio è già molto lunga.
Riferimenti: Anthropic Engineering Blog (Building Effective Agents, Effective Context Engineering, Multi-Agent Research System, Effective Harnesses for Long-Running Agents, Managed Agents); OpenAI Developers Blog (Run Long Horizon Tasks with Codex, Shell + Skills + Compaction); Google Developers Blog (Architecting Efficient Context-Aware Multi-Agent Framework, Conductor: Context-Driven Development for Gemini CLI)
