Theory of mind e multi-agent systems: cosa funziona, cosa è metafora, cosa manca

Il capitolo precedente ha mostrato che la theory of mind in LLM è una proprietà contestata, con evidenze pro e contra che si bilanciano. Qui guardiamo a un oggetto diverso: i sistemi multi-agent come pattern ingegneristico — AutoGen, MetaGPT, CrewAI, LangGraph, Generative Agents, CICERO — e a quanto la “ToM” emerge o viene ingegnerizzata in essi. La risposta onesta è che, salvo eccezioni vincolate da regole di gioco strutturate, “modelling other agents” in LLM multi-agent significa leggere il messaggio precedente nel context window: utile, talvolta efficace, ma molto distante dalla metarappresentazione persistente che caratterizza la ToM cognitiva.

Una premessa di registro. Questo è un capitolo ponte, sotto-registro operativo. Il presentismo è legittimo: paper datati 2022-2026, framework specifici, sistemi in produzione. Ma il rigore sulle classi di affermazioni resta non negoziabile. Quando il capitolo dice “AutoGen non ha theory of mind”, non sta facendo polemica retorica: sta facendo classificazione tecnica. La distinzione fra cosa il sistema fa e cosa il vocabolario suggerisce che faccia è il filo conduttore.

Una scena per cominciare

Diplomacy è un gioco da tavolo del 1959 disegnato da Allan Calhamer. Sette giocatori rappresentano potenze europee del 1901, muovono unità militari su una mappa, e ad ogni turno negoziano fra loro — alleanze, tradimenti, promesse, pressioni — prima di scrivere ordini segreti che vengono rivelati simultaneamente. Diplomacy è famoso fra i game theorist e fra i designer di benchmark AI per una ragione precisa: vincere richiede di mantenere convinzioni separate sui sette giocatori al tavolo, di prevedere cosa ciascuno crederà delle proprie intenzioni, di ingannare quando serve, di costruire fiducia quando serve. Per decenni è stato considerato fuori portata per i sistemi automatici. Negli anni 2000 e 2010 alcuni bot esistevano, ma giocavano in modalità no-press — senza il dialogo — perché nessuno sapeva come collegare il search game-theoretic alla negoziazione in linguaggio naturale.

Nel novembre 2022, il team Diplomacy di Meta FAIR pubblica su Science un paper intitolato Human-level play in the game of Diplomacy by combining language models with strategic reasoning. Il sistema si chiama CICERO. Gioca su WebDiplomacy.net in modalità anonima per quaranta partite, con avversari umani che non sanno di affrontare un bot. Risultato: piazzamento medio nel top 10% della distribuzione, due volte il punteggio medio degli avversari umani, partecipazione attiva alla negoziazione (più di 5.200 messaggi inviati), e — per la maggior parte degli avversari — indistinguibile da un giocatore umano competente.

A guardare i log, CICERO sembra avere theory of mind. Inferisce che il giocatore Russia sospetta di lui; gli scrive un messaggio rassicurante; dopo due turni lo tradisce in coordinamento con Inghilterra. Il pattern è esattamente quello che la psicologia chiama mentalizing: rappresentare gli stati mentali altrui (il sospetto di Russia), agire per modificarli (rassicurazione), pianificare azioni che sfruttano la credenza falsa che quegli stati producono (l’attacco coordinato).

A guardare il codice, CICERO non ha theory of mind. Ha un componente strategico basato su game-theoretic search (eredità del lavoro su no-press Diplomacy bot) che mantiene una stima probabilistica delle policy degli altri giocatori, condizionata sulla storia del gioco. Ha un dialogue model (un LLM specializzato) che viene condizionato sulla strategia pianificata e sui messaggi precedenti per generare il prossimo messaggio. Il “modelling other agents” è esplicito ma è game-theoretic, non LLM-emergente; è vincolato alle regole strutturate di Diplomacy, non un’abilità general-purpose; è un belief state numerico sulla policy avversaria, non una metarappresentazione di credenze.

Questa distanza — fra ciò che il comportamento sembra implicare e ciò che il sistema effettivamente fa — è il filo conduttore del capitolo. CICERO è il caso di alta qualità. Ai due estremi opposti ci sono framework come AutoGen, dove il “modelling other agents” si riduce alla lettura del messaggio precedente nel context window, e Generative Agents, dove gli agent della sandbox Smallville si ricordano l’uno dell’altro come stringhe in un memory stream append-only. Tre sistemi, tre pattern molto diversi, tutti talvolta etichettati come “multi-agent con theory of mind”. Disambiguare è il lavoro di questo capitolo.

Perché un ponte qui

Il ponte serve a tre cose.

Prima, proteggere il vocabolario. Il capitolo precedente ha mostrato che la ToM in LLM è dibattuta, con evidenze in entrambe le direzioni e una crisi metodologica (contamination, Clever Hans effects, fragilità a perturbazioni triviali). Quando da quella discussione si passa ai sistemi multi-agent, la tentazione di scrivere “AutoGen ha theory of mind perché due agent si parlano” è grande. Ed è grave errore di classe. Un agent A che legge il messaggio dell’agent B nel proprio context window non ha una rappresentazione di B; ha una stringa concatenata al proprio prompt. Confondere le due cose è equivalente a confondere “leggere una lettera” con “avere una teoria della mente del mittente”. I sistemi multi-agent meritano un vocabolario proprio.

Seconda, collegare due tradizioni che non si parlano. La letteratura sui sistemi multi-agent ha una storia trentennale che precede la wave LLM: distributed artificial intelligence (DAI), agenti BDI, multi-agent reinforcement learning, opponent modeling. Nessuno di questi filoni è nato dalla letteratura ToM cognitiva. Quando AutoGen e MetaGPT escono nel 2023, eredita dal lato AI (agent-oriented programming, conversational agents) e dal lato LLM (chain-of-thought, tool use). Non eredita da Premack-Woodruff, da Wimmer-Perner, da Baron-Cohen. La filiazione è assente. Documentare questa assenza protegge dalla narrazione spuria di “AI multi-agent come implementazione di ToM cognitiva”.

Terza, fornire una mappa operativa onesta. I framework multi-agent LLM sono nel 2026 in produzione in quantità crescente, con risultati ambivalenti. Sapere quando funzionano (software engineering ben strutturato, debate per factuality, self-play in giochi con verifier) e quando falliscono (open-ended creativi, sycophancy cross-agent, hallucination amplification) è prerequisito per chiunque debba decidere se mettere multi-agent nel proprio sistema. Le sezioni finali del capitolo sono questa mappa.

Disclaimer iniziale: cosa il capitolo precedente ha già stabilito

Per non ripetere theory-of-mind, riassumo in tre punti.

Primo, la ToM cognitiva è una funzione cognitiva specifica, distinta da intelligenza generale, empatia, social skill. Si misura con compiti precisi (false-belief task di Wimmer-Perner 1983, Sally-Anne di Baron-Cohen-Leslie-Frith 1985), si associa a un mentalizing network neurale (rTPJ, mPFC, precuneus), si rompe selettivamente in popolazioni cliniche.

Secondo, la ToM in LLM al 2026 è dibattuta. Bubeck e colleghi 2023 (Sparks of AGI) trovano comportamenti ToM-like in GPT-4. Kosinski 2023 trova progressione monotona di accuracy su FB task da GPT-1 a GPT-4. Ullman 2023 mostra che alterazioni triviali fanno crollare la performance. Shapira et al. 2024 (EACL) suggeriscono effetto Clever Hans diffuso. Strachan et al. 2024 (Nature Human Behaviour) trovano un quadro sfumato. La conclusione consensuale al 2026 è: capacità ToM-like presenti ma fragili, non affidabili come una funzione cognitiva matura, sospette di benchmark contamination.

Una nota sul significato di “contestato”. In scienza, contestato non significa “indeterminato” o “questione di gusto”. Significa che esistono evidenze in più direzioni, ognuna prodotta con metodologia rigorosa, che non si sono ancora composte in consenso. Per la ToM in LLM al 2026, le evidenze sono: comportamenti ToM-like documentati su benchmark canonici (Bubeck, Kosinski, Strachan); fragilità a perturbazioni triviali (Ullman); effetto Clever Hans documentato (Shapira); contamination plausibile per molti benchmark (la maggior parte dei FB task famosi è in dataset di pretraining). Una posizione onesta richiede di tenere insieme tutto questo, senza appoggiarsi a una sola direzione di evidenza. Il capitolo presente eredita questa posizione e la specializza al caso multi-agent.

Terzo, e cruciale per questo capitolo: la ToM cognitiva è caratterizzata da metarappresentazione persistente. Il bambino sopra i quattro anni mantiene, nel proprio working memory model, una rappresentazione della credenza falsa di Maxi separata dalla propria conoscenza. La rappresentazione persiste finché il task lo richiede; è strutturata come representation-of-representation; sopravvive a interruzioni; è dissociabile da altre funzioni cognitive. È questa la proprietà — persistenza, struttura, dissociabilità — che gli LLM multi-agent al 2026 non hanno in modo robusto. Ne hanno una surrogata: il context window condiviso o messaggi recenti. Il capitolo userà questa distinzione come pietra di paragone.

L’intuizione: cosa significa “modellare un altro agent”

Prima di passare alla tassonomia, fissiamo cosa intendiamo con “modellare un altro agent”. Il termine ha letture diverse, e tenerle separate è prerequisito per ogni discussione successiva.

Lettura 1 — Modellare come predire comportamento. Modellare un altro agent significa avere una funzione che, dato uno stato e un’osservazione di quell’agent, ritorna una distribuzione su possibili azioni future. È la lettura più semplice. Un termostato che ha imparato che alle 7:00 la persona alza la temperatura ha un modello (banale) della persona. Un bot di scacchi che ha imparato che gli avversari deboli accettano scambi sfavorevoli ha un modello (non banale) dell’avversario. Non c’è bisogno di rappresentare credenze, desideri, intenzioni: solo policy estimation.

Lettura 2 — Modellare come stimare belief state. Modellare un altro agent significa avere una stima di cosa l’altro crede vero, distinta da cosa è vero in fact. È la lettura intermedia. CICERO, con la sua stima della policy avversaria condizionata sulla storia di gioco, è in questa lettura: stima implicitamente cosa Inghilterra crede sulla strategia di Francia. Hanabi richiede questa lettura per definizione: un hint informativo richiede di stimare cosa l’altro sa.

Lettura 3 — Modellare come metarappresentazione. Modellare un altro agent significa avere una rappresentazione strutturata del suo stato mentale (credenze, desideri, intenzioni, conoscenza, emozioni) come representation-of-representation. È la lettura forte, quella che la psicologia chiama theory of mind in senso stretto. Richiede dissociabilità della propria conoscenza dall’altrui, persistenza nel tempo, robustezza a perturbazioni.

I sistemi multi-agent LLM al 2026 operano quasi tutti in lettura 1 o 2. Il framework che si avvicina più alla lettura 2 è CICERO, con belief state esplicito ingegnerizzato. La lettura 3 è in pratica assente dai sistemi in produzione: quando si sostiene che esista (es. “Generative Agents hanno ToM”), si sta facendo confusione di classe — il memory stream con retrieval testuale non è una metarappresentazione strutturata.

Il termine “modelling other agents” sarà usato nel resto del capitolo prevalentemente in lettura 1 e 2. Quando intendiamo lettura 3, lo diciamo esplicitamente.

La tradizione pre-LLM dei sistemi multi-agent

I sistemi multi-agent non nascono nel 2023 con AutoGen. Nascono come Distributed Artificial Intelligence (DAI) negli anni Settanta-Ottanta, con due tradizioni che si intrecciano.

Documentare questa preistoria importa per due ragioni. Una è onestà intellettuale: chi propone un framework nel 2023 sta riprendendo un vocabolario consolidato che eredita da decenni di lavoro pre-LLM, e ignorarlo produce narrazioni di originalità spuria. L’altra è pratica: molti dei pattern usati oggi (manager-worker, blackboard, debate) sono varianti di idee testate altrove, e conoscere quelle origini permette di anticipare i problemi che riemergono.

La prima tradizione è la decomposizione computazionale di problemi su agenti distribuiti. HEARSAY-II (Lee Erman, Victor Lesser, Raj Reddy alla Carnegie Mellon, 1980) è un sistema di speech understanding organizzato come blackboard architecture: una memoria condivisa (la blackboard) contiene ipotesi parziali a vari livelli di astrazione (segnale, fonemi, parole, frasi, semantica), e knowledge source specializzati (uno per livello) leggono e scrivono in modo opportunistico. Non ci sono agent in senso autonomo — sono moduli che cooperano via shared memory — ma il pattern blackboard riemerge ancora oggi nei framework moderni come sostrato di coordinazione.

La seconda tradizione modella agenti razionali autonomi. Il modello di riferimento è il BDI — Beliefs, Desires, Intentions — formulato filosoficamente da Michael Bratman (filosofo americano a Stanford) nel libro del 1987 Intention, Plans, and Practical Reason. Bratman sostiene contro Donald Davidson e altri che le intenzioni non sono riducibili a credenze + desideri: hanno proprietà funzionali specifiche — volition-based commitment (un’intenzione è un impegno volontario, non una semplice preferenza), plan-stability (le intenzioni rimangono fisse contro distrattori per evitare rivalutazione continua), future-directedness (un’intenzione punta a un’azione futura). Anand Rao e Michael Georgeff (entrambi computer scientist australiani all’Australian Artificial Intelligence Institute di Melbourne) formalizzano BDI in un’architettura computazionale nel 1991, con il paper Modeling Rational Agents within a BDI-Architecture (KR’91), e successivamente con il sistema PRS (Procedural Reasoning System). Il modello BDI ha avuto una storia industriale lunga (piattaforme JACK, JADE, Jason) e ha definito il vocabolario di gran parte dell’agent-oriented software engineering anni Novanta.

Il punto importante per il ponte è che BDI non discende dalla letteratura ToM cognitiva. Bratman cita filosofia dell’azione (Davidson, Anscombe), non scienze cognitive evolutive. Rao-Georgeff citano Bratman e logica modale, non Premack-Woodruff. La tradizione DAI/BDI ha sviluppato un proprio vocabolario — Beliefs come stato informazionale dell’agent, Desires come stati motivazionali, Intentions come commitments — che per coincidenza terminologica ricorda mental states ma è formalizzato in modo molto diverso (Beliefs come formule logiche con possible-world semantics, non come rappresentazioni cognitive).

Nel frattempo, una tradizione parallela è il multi-agent reinforcement learning (MARL). Self-play training è la tecnica di addestrare un agent contro versioni di se stesso. Gerald Tesauro alla IBM applica self-play con TD-learning a backgammon e produce TD-Gammon (1992-1995), un sistema che impara senza partite umane e raggiunge livello world-class. Negli anni Duemiladieci lo stesso schema riemerge in AlphaGo (David Silver, Aja Huang, Chris J. Maddison e collaboratori a DeepMind, Nature 2016 — Go), in AlphaZero (Silver et al. 2017, Science 2018 — Go, scacchi, shogi senza partite umane), in AlphaStar (Oriol Vinyals, Igor Babuschkin e collaboratori a DeepMind, Nature 2019 — StarCraft II), in OpenAI Five (Christopher Berner e collaboratori a OpenAI 2018-2019 — Dota 2). In tutti, il “modelling other agents” è implicito nei pesi della policy: la rete ha imparato, attraverso milioni di partite contro se stessa, a giocare bene contro avversari simili a sé. Non c’è un belief state esplicito sull’avversario; c’è una policy che condiziona sulla situazione di gioco.

Un raffinamento notevole è LOLA — Learning with Opponent-Learning Awareness — di Jakob Foerster e collaboratori (allora a Oxford con Shimon Whiteson, oggi alla University of Oxford e DeepMind), pubblicato a AAMAS 2018. L’idea: ogni agent considera, durante il proprio update, come quell’update influenzerà l’update dell’avversario. È opponent modelling reso differenziabile: il gradient flow attraversa anche il modello dell’avversario. M-FOS (Christopher Lu et al. Oxford 2022) generalizza LOLA come meta-game. Sono modelling-other-agents preso sul serio matematicamente, ma in domini ristretti (game-theoretic, con payoff matrix definite).

Vale la pena soffermarsi su un altro caso pre-LLM: il CICERO precursor della scuola Diplomacy no-press. Prima di CICERO 2022, una serie di lavori (Anthony Bonjour, Edward Hughes, e altri a DeepMind e Facebook AI) aveva prodotto bot Diplomacy che giocavano senza dialogo, basati su counterfactual regret minimization e modelling Bayesiano della policy avversaria. Quei lavori hanno fornito il backbone strategico che CICERO ha poi accoppiato al dialogue model. La storia mostra un pattern ricorrente nei sistemi multi-agent: la parte “intelligente” sul modelling-other-agents viene spesso da un componente non-LLM, e l’LLM aggiunge interfaccia naturale.

Il banco di prova canonico per cooperative theory of mind in MARL è Hanabi. Hanabi è un gioco di carte cooperativo dove ogni giocatore vede le carte degli altri ma non le proprie, e si comunica con hint vincolati che devono essere informativi dato cosa ciascuno sa. Nolan Bard, Jakob Foerster, Sarath Chandar e collaboratori (DeepMind + altri, Artificial Intelligence 280:103216, 2020) lo propongono come Hanabi Challenge: un benchmark che richiede esplicitamente di rappresentare cosa l’altro sa di cosa io so, perché senza questa capacità i hint non sono informativi. Il gioco si è dimostrato molto difficile per RL puro. I migliori risultati al 2026 vengono da architetture specializzate con communication protocol espliciti, non da agent general-purpose.

I framework LLM multi-agent del 2023-2026

L’arrivo di LLM capaci di tool use e instruction following nel 2022-2023 produce un’esplosione di framework che applicano l’idea multi-agent alla nuova primitiva. Mappa rapida dei principali.

AutoGen (Qingyun Wu, Gagan Bansal, Chi Wang e collaboratori, Microsoft Research, AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation, arXiv 2308.08155, 2023) introduce l’astrazione di Conversable Agent: un oggetto che espone metodi send e receive, può essere assistant agent (LLM-backed) o user proxy agent (capace di eseguire codice in sandbox), e può essere registrato con tool. I pattern principali sono: two-agent (assistant + user-proxy con esecuzione codice), group-chat con un manager che decide chi parla. AutoGen v0.4 (2024) introduce un’architettura layered con runtime esplicito separato dalle astrazioni high-level. AutoGen è ad oggi uno dei framework più adottati in ricerca per sperimentare pattern multi-agent.

MetaGPT (Sirui Hong, Mingchen Zhuge, Jonathan Chen, Jürgen Schmidhuber e collaboratori, MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework, arXiv 2308.00352, ICLR 2024) simula una software house con cinque ruoli: Product Manager, Architect, Project Manager, Engineer, QA Engineer. Ogni ruolo ha una Standard Operating Procedure codificata nel prompt di sistema, che vincola gli output a forme strutturate (Product Manager produce un PRD, Architect produce un system design con file structure, e così via). I risultati sui benchmark di software simulato (HumanEval estesi, in-house benchmarks come SoftwareDev) sono competitivi rispetto a single-agent baselines su task con specifica chiara. Il merito di MetaGPT non è la coordinazione intelligente: è il vincolo strutturale forte che ogni ruolo impone — il prompt forza output ben formati che il ruolo successivo può consumare in modo affidabile.

CrewAI (João Moura, framework open-source 2023, https://github.com/joaomdmoura/crewAI, evolutosi in offerta commerciale) usa astrazioni Agent (con role, goal, backstory), Task (description + expected output + agent assigned), Crew (collection di agents + tasks + process: sequential o hierarchical). È più semplice di AutoGen, focalizzato su business automation use case. La differenza pratica con LangGraph è che CrewAI privilegia una API dichiarativa role-centric, mentre LangGraph espone esplicitamente il graph di stato.

LangGraph (LangChain 2024, https://langchain-ai.github.io/langgraph/) materializza l’orchestrazione come state machine esplicito: i nodi sono funzioni che mutano lo state condiviso, gli edge sono condizioni di transizione. L’astrazione “agent” diventa un nodo che fa una chiamata LLM con tool. I pattern supportati includono supervisor (un LLM router decide il prossimo agent), swarm (peer-to-peer con handoff), hierarchical (supervisor di supervisor). LangGraph è il framework più ingegneristicamente disciplinato della lista; restituisce molta della determinabilità a chi lo usa, al prezzo di richiedere di pensare il sistema come graph.

La filosofia di LangGraph rispetto ad AutoGen è istruttiva. AutoGen privilegia conversational autonomy: gli agent si parlano, il framework fa da postino. LangGraph privilegia explicit control flow: il sistema è un graph, ogni transizione è codificata, gli agent sono pure functions sullo state. Le due filosofie corrispondono a due culture ingegneristiche: AutoGen attrae chi viene da dialogue systems e simulazione; LangGraph attrae chi viene da workflow engineering e si trova a costruire sistemi production-grade. Al 2026 entrambi i camp hanno comunità attive, e la scelta è in larga misura una scelta di paradigma più che una di feature.

Una nota su Smallville come oggetto culturale. Il paper di Park et al. ha avuto un impatto mediatico notevole nel 2023, anche oltre il pubblico tecnico, perché le immagini della sandbox 2D ricordano i giochi RPG e gli agent producono comportamenti narrativamente leggibili. Questo successo divulgativo ha avuto un effetto collaterale: ha alimentato la narrazione di “AI multi-agent come simulazione di società”. La narrazione è seducente ma fuorviante, per i motivi tecnici discussi nelle sezioni successive. Smallville è una dimostrazione efficace di emergent behavior in agent LLM con memory architecture, non una simulazione di società umana.

Generative Agents (Joon Sung Park, Joseph C. O’Brien, Carrie J. Cai, Meredith Ringel Morris, Percy Liang, Michael S. Bernstein, Generative Agents: Interactive Simulacra of Human Behavior, UIST 2023) merita un trattamento separato perché è il caso più discusso in chiave ToM. Smallville è una sandbox 2D in cui 25 agent LLM-backed vivono, interagiscono, formano relazioni, organizzano una festa di San Valentino emersa spontaneamente dalle interazioni di un singolo agent. La memoria di ogni agent è un memory stream append-only di osservazioni timestampate; il retrieval combina recency, importance, relevance; periodicamente l’agent fa reflection (sintesi di alto livello che diventa nuova entry nello stream); il planning è gerarchico (giorno → orario → minuto). Il cap. 70 (ponte-memoria-agenti) lo discute dal lato memoria. Il punto da fissare qui è che il “modelling other agents” è interamente via memory stream: Klaus che “ricorda Eddy” è un’entry testuale nel proprio stream, non un belief state strutturato del cervello di Eddy. Quando Klaus decide cosa dire a Eddy, fa retrieval di osservazioni rilevanti su Eddy e le concatena nel prompt. È funzionalmente efficace per simulazione, ma non è metarappresentazione.

CAMEL (Guohao Li, Hasan Abed Al Kader Hammoud, Hani Itani, Dmitrii Khizbullin, Bernard Ghanem alla KAUST, NeurIPS 2023) usa inception prompting: due ruoli — AI User e AI Assistant — fanno role-play guidato per esplorare un task. Il dataset di conversazioni autogenerate è stato usato per training di modelli successivi.

AutoGPT e BabyAGI (2023, viral) sono in rigore single-agent loop con sub-task decomposition, ma vengono spesso classificati come multi-agent per via della decomposizione interna. I limiti documentati sono severi: hallucination loop, no convergence, costo esplosivo. Hanno avuto valore di proof-of-concept più che di produzione.

Una nota di metodo. La differenza fra “multi-agent” e “single-agent con tool” non è sempre netta. Un agent che chiama un sub-agent come tool è spesso indistinguibile, dal punto di vista funzionale, da un agent che chiama una function. La definizione operativa più utile è: un sistema è multi-agent se almeno due componenti operano con stato cognitivo separato (context window distinti, memoria distinta, eventualmente policy distinte) e si scambiano messaggi non riducibili a singole function call. Sotto questa definizione, AutoGen group chat è multi-agent, MetaGPT è multi-agent, Devin è borderline (architettura interna non completamente pubblica), Claude Code agentic mode con sub-agent è multi-agent gerarchico stretto. AutoGPT e BabyAGI sono single-agent con loop interno.

flowchart LR
    USER["Requisito utente"] --> PM["Product Manager"]
    PM -->|PRD| ARCH["Architect"]
    ARCH -->|System Design| PRJ["Project Manager"]
    PRJ -->|Task List| ENG["Engineer"]
    ENG -->|Code Files| QA["QA Engineer"]
    QA -->|Test Report| OUT["Artefatto finale"]
    QA -.->|bugs| ENG

Figura 2 — MetaGPT roles pipeline: Product Manager, Architect, Project Manager, Engineer, QA Engineer with artifacts at each step

Una nota tecnica su ciò che AutoGen e simili fanno davvero

Per essere precisi su un’affermazione che il capitolo ripeterà più volte: cosa esattamente succede quando “due agent AutoGen si parlano”.

Setup tipico: due Conversable Agent, agent A con system prompt “sei un ricercatore esperto di X”, agent B con system prompt “sei un editor che migliora il testo”. Loop: A genera un sommario, B lo legge e propone edit, A risponde alle proposte, e così via fino a max_turns o stop condition.

Cosa accade meccanicamente. A ogni turno di A: si costruisce un prompt che include il system prompt di A, la cronologia dei messaggi nel context window di A (include i messaggi propri e quelli ricevuti da B, formattati con marker di ruolo), eventualmente alcuni metadati. Si chiama il modello con quel prompt. Si ottiene un nuovo messaggio. Si invia il messaggio a B (lo si appende alla cronologia di B). Stesso schema simmetrico per B.

Cosa non accade meccanicamente. Non esiste uno stato che dica “A crede che B pensi X”. Non esiste un belief state strutturato. Non esiste persistenza fra sessioni (a meno che il framework lo aggiunga esplicitamente con memoria esterna). Quando A genera “capisco la tua obiezione, ma…”, non sta accedendo a una rappresentazione dell’obiezione di B; sta facendo next-token prediction su una sequenza che ha nel proprio context “B ha detto: [obiezione]”.

L’effetto di questa meccanica è interessante: in molti casi produce conversazione coerente che sembra ToM-aware. In altri casi produce sycophancy, drift, ripetizione. La capacità ToM-like è una proprietà emergente del modello base che il pattern multi-agent può evocare ma non garantisce. Sapere che la meccanica è “context concatenation + autoregressive generation” rende prevedibili le condizioni di fallimento.

Lo stesso ragionamento vale per MetaGPT, CrewAI, e in larga misura per tutti i framework basati su LLM messaging. Le differenze fra framework sono nelle astrazioni di alto livello (ruoli, processi, state), non nella meccanica di base.

Pattern di coordinazione: una tassonomia funzionale

Trasversalmente ai framework, i pattern di coordinazione si possono raggruppare in sei famiglie. La distinzione importa perché ogni pattern ha proprietà diverse rispetto al “modelling other agents” e ai failure mode.

Manager-worker (gerarchico). Un agent manager riceve il task, lo decompone, assegna sub-task a worker specializzati, raccoglie risultati, li compone. MetaGPT è esempio puro (la gerarchia è codificata nei ruoli). LangGraph supervisor pattern è la versione esplicita. Il vantaggio è il routing centralizzato: il flusso è prevedibile. Lo svantaggio è che il manager è single point of failure cognitivo: se il manager misinterpreta il task, tutta la cascata è compromessa.

Peer-to-peer. Agenti come pari, comunicano via broadcast o handoff esplicito. AutoGen group chat è l’esempio tipico. LangGraph swarm pattern. Il vantaggio è la flessibilità: nessuno è bottleneck. Lo svantaggio è la difficoltà di vincolare il flusso: senza un coordinatore, gli agent possono divergere, ripetersi, fallire la convergenza.

Sequential pipeline. A → B → C → D, ognuno consuma l’output del precedente. È il pattern più semplice, e in molti casi non è davvero “multi-agent” ma un workflow con LLM call in nodi specifici. CrewAI sequential process. Quando il task è ben strutturato, sequential è spesso la scelta giusta.

Parallel ensemble. N agent rispondono indipendentemente allo stesso task, le risposte vengono aggregate (majority vote, ranking, average). La self-consistency single-modello (Wang et al. 2022) è la versione minimale; multi-agent debate ne è una variante con più round. Il pattern è efficace quando le risposte sono indipendenti e la verità è un attrattore comune (errori idiosincratici).

Debate / adversarial. Due o più agent argomentano posizioni diverse, eventualmente con un giudice. Yilun Du, Shuang Li, Antonio Torralba, Joshua B. Tenenbaum, Igor Mordatch (Improving Factuality and Reasoning in Language Models through Multiagent Debate, arXiv 2305.14325, ICML 2024) mostrano gain misurabili su factuality benchmark. Il cap. 82 (ponte-metacognizione-self-correction) lo tratta in dettaglio come pattern di self-correction. Qui basti notare: funziona quando c’è qualche meccanismo di groundedness (almeno il giudice deve avere un criterio); senza ground-truth, può degenerare in mutual approval.

Critic + actor. Agent A produce, agent B critica, A revisiona. Variante di Generator-Verifier. Generalizzazione di Self-Refine quando i due ruoli sono separati. Empiricamente più robusto del singolo loop di self-refinement (cap. 82).

Manager-worker recursivo è una variante che vale la pena nominare. Il worker, ricevuto un sub-task, può a sua volta diventare manager di sub-sub-worker. La gerarchia diventa albero. Pattern utile per task con decomposizione naturale ricorsiva (refactor di un monorepo, ricerca esplorativa con sub-question generation), ma esplosivo in costo se non controllato. La maggior parte dei sistemi in produzione limitano la profondità a 2-3 livelli per evitare cost runaway.

Una distinzione operativa: i primi tre pattern (manager-worker, peer-to-peer, sequential) sono strutturali — riguardano come gli agent sono connessi. Gli ultimi tre (parallel ensemble, debate, critic-actor) sono interazionali — riguardano cosa gli agent fanno gli uni agli altri. Si possono combinare.

Un esempio di combinazione: un sistema può essere strutturalmente manager-worker (un coordinator delega a esperti) e interazionalmente critic-actor su ogni sub-task (l’esperto produce, un secondo esperto critica, l’attore revisiona prima di restituire al coordinator). Questo è un pattern abbastanza comune in produzione, perché unisce la prevedibilità della gerarchia alla robustezza della critique.

Un altro asse di classificazione meno discusso ma importante è il grado di omogeneità degli agent. In un sistema omogeneo gli agent sono istanze dello stesso modello con prompt diversi (la maggior parte dei framework). In un sistema eterogeneo gli agent usano modelli diversi (es. Claude per planning, GPT-4 per coding, un modello locale piccolo per task semplici). L’eterogeneità riduce la sycophancy cross-agent (modelli diversi hanno bias diversi) ma complica orchestrazione, billing, latenza. Al 2026 i sistemi eterogenei sono ancora minoritari ma in crescita.

ToM-like reasoning: quando emerge, quando viene ingegnerizzato, quando manca

Tre casi di studio illustrano lo spettro.

Vale la pena soffermarsi su un aspetto poco discusso: la differenza fra modelling other agents come emergent property del modello base e modelling other agents come scaffolding ingegneristico sopra il modello. La prima è la posizione implicita di chi sostiene “GPT-4 ha ToM, quindi due GPT-4 che si parlano hanno coordinazione ToM-aware”. La seconda è la posizione di chi costruisce CICERO o opponent modelling MARL: la capability emergente, anche dove esiste, non è abbastanza affidabile per essere base di sistemi di produzione, e va vincolata o ingegnerizzata esplicitamente.

L’evidenza al 2026 supporta la seconda posizione. I tentativi di ottenere coordinazione ToM-aware affidabile dal puro chaining di LLM (multi-agent senza scaffolding strutturale) producono risultati ambivalenti: gain marginali su task narrativi specifici, fallimenti gravi su task adversariali, sycophancy diffusa. I sistemi che funzionano (CICERO, alcuni casi MetaGPT, debate per factuality) hanno tutti un elemento di scaffolding non-LLM che fornisce ground-truth o vincolo strutturale.

CICERO (FAIR Diplomacy team 2022) è il caso ad alta qualità ingegnerizzata. Il “modelling other agents” è esplicito ma viene da game-theoretic search, non da emergenza LLM. CICERO mantiene per ogni avversario una stima probabilistica della policy condizionata sulla storia di gioco; il dialogue model è condizionato su quella stima e sulla strategia pianificata. La separazione architetturale è cruciale: l’LLM non fa il ragionamento strategico, lo verbalizza. Quando CICERO sembra “ingannare”, è perché la strategia game-theoretic ha calcolato che l’inganno massimizza expected value, e il dialogue model ha generato il messaggio coerente con quella strategia. È ToM-like nel comportamento osservato, è game theory + dialogue nell’implementazione.

Hanabi è il caso dove la ToM è necessaria per definizione del task ed è notoriamente difficile da ottenere. Senza una rappresentazione di “cosa l’altro sa di cosa io so”, non si possono dare hint informativi. Al 2026 i migliori risultati su Hanabi vengono da architetture specializzate con communication protocol esplicitamente progettato per cooperative belief inference, non da LLM general-purpose. Hanabi è un benchmark che ricorda quanto la ToM sia fragile in sistemi non vincolati.

Generative Agents (Park et al. 2023) è il caso dove il “modelling other agents” è emergente ma debole. Klaus che ha aspettative su Eddy non ha un belief state di Eddy: ha un memory stream che contiene osservazioni testuali su Eddy e un retriever che le pesca quando rilevanti. Funzionalmente, per la simulazione Smallville, è abbastanza: gli agent si comportano in modo coerente, formano relazioni, organizzano eventi. Ma se si testano su FB task espliciti, falliscono come falliscono i base LLM (vedi cap. 85 sul dibattito Kosinski-Ullman). Il “modelling” è retrieval testuale, non metarappresentazione.

flowchart LR
    USER["Requisito utente"] --> PM["Product Manager"]
    PM -->|PRD| ARCH["Architect"]
    ARCH -->|System Design| PRJ["Project Manager"]
    PRJ -->|Task List| ENG["Engineer"]
    ENG -->|Code Files| QA["QA Engineer"]
    QA -->|Test Report| OUT["Artefatto finale"]
    QA -.->|bugs| ENG

Figura 2 — Generative Agents architecture: agent reads observations from environment and other agents, writes to memory stream, reflection produces high-level insights, planning consumes both

Una osservazione metodologica importante. Quando si valutano sistemi come Generative Agents, è facile confondere plausibilità del comportamento osservato con profondità della rappresentazione interna. Klaus che organizza una festa di San Valentino e invita Eddy ricordando che Eddy gli aveva parlato di musica produce un comportamento che sembra ToM-aware. Ma il meccanismo è retrieval + LLM generation: il sistema pesca da memory stream le osservazioni rilevanti su Eddy quando deve decidere chi invitare, e l’LLM completa la decisione. Se chiediamo a Klaus “perché hai invitato Eddy?”, Klaus genera una giustificazione coerente. Se aboliamo la festa e ricominciamo, Klaus ha lo stesso memory stream e ha le stesse “preferenze” su chi invitare, ma queste preferenze non sono un belief state riflessivo: sono un pattern di retrieval. La differenza è importante per chiunque voglia usare Generative Agents-like systems per simulazione sociale: il comportamento è simulabile, la cognizione sociale no.

La generalizzazione operativa: se vuoi ToM-like behavior affidabile in un sistema multi-agent, non delegarlo all’emergenza LLM. Vincola il task con regole strutturate (come CICERO) o ingegnerizza un belief state esplicito (come opponent modelling in MARL). Affidarsi a “due LLM che si parlano” significa avere comportamento ToM-like quando il prompt e il task lo evocano, e nessuna garanzia altrimenti.

Una controprova è interessante: i tentativi di costruire belief state esplicito sopra LLM. Alcuni lavori 2024-2025 propongono di mantenere, accanto al context window, una struttura dati che rappresenti “cosa ogni agent crede” come dizionario aggiornato a ogni turno. L’LLM legge il belief state, lo modifica esplicitamente, lo passa al prossimo turno. Risultato preliminare: gain marginali su task narrativi specifici, niente di paragonabile alla differenza fra ToM presente e assente nei bambini umani. La capability latente nei pesi non si lascia scaffoldare facilmente in metarappresentazione robusta. La ricerca è aperta.

Benchmark e valutazione dei sistemi multi-agent

La valutazione dei sistemi multi-agent è un’area meno matura della valutazione single-agent. Mappa rapida.

MultiAgentBench e simili (vari, 2024-2025): benchmark che misurano performance su task multi-step con orchestrazione multi-agent. Il problema metodologico ricorrente è che molte differenze fra framework sono confondibili con differenze di prompt engineering: lo stesso task con prompt diversi può cambiare drasticamente il risultato.

SWE-bench (Carlos Jimenez et al. Princeton 2023) è il benchmark di riferimento per coding agent. Originariamente single-agent oriented, è stato adottato da sistemi multi-agent come MetaGPT, AutoGen, Devin. I risultati top al 2025-2026 vengono da sistemi che combinano agent loop con verification massiccia (run test, parse error, retry); il delta multi-agent vs single-agent è ambiguo.

GAIA (Mialon et al. Meta + HuggingFace 2023) è benchmark per general AI assistant con task multi-step che richiedono tool use e ragionamento. Multi-agent systems non hanno un vantaggio sistematico rispetto a single-agent ben strutturati.

tau-bench (Yao et al. 2024) testa agent su task realistici (customer service, retail) con interazione user-agent simulata. Single-agent baseline è competitivo.

Una osservazione metodologica: confrontare multi-agent con single-agent baseline richiede attenzione. Spesso il multi-agent ha context complessivo molto maggiore (somma dei context di tutti gli agent), più chiamate al modello, e quindi più test-time compute. Confrontare un multi-agent con N=5 agent contro un single-agent con N=1 chiamata è confronto sleale; il fair confronto è contro un single-agent con budget equivalente di chiamate (es. N=5 sample con self-consistency, o un agent con N=5 retry e self-refine). Sotto questo confronto, i multi-agent perdono molto del proprio vantaggio apparente.

Communication protocols: il ventre molle

Come gli agent si parlano determina molto di ciò che possono fare e dei modi in cui falliscono.

Natural language messages è la default option in AutoGen e CrewAI. È espressivo ma fragile: B può malinterpretare A (hallucination cross-agent); A può inavvertitamente convincere B a violare la sua policy (prompt injection cross-agent — un agent compromesso può infettare gli altri); il volume di token cresce velocemente (cost esplosivo); B può accomodare A senza challenge sostanziale (sycophancy cross-agent, documentata da Sharma et al. Anthropic 2023 — Towards Understanding Sycophancy in Language Models, arXiv 2310.13548).

Structured messages (JSON, schema-validated) sono più robusti. Un agent emette un oggetto strutturato che il prossimo legge per campi. Il flusso si avvicina a un workflow tradizionale. Il prezzo è la perdita di espressività: alcuni task richiedono ragionamento ricco che JSON non cattura naturalmente.

Shared memory / blackboard: tutti gli agent leggono e scrivono su uno state comune. Pattern classico (HEARSAY-II 1980) che riemerge nei framework moderni come state condiviso in LangGraph. Vantaggio: ogni agent ha visibilità completa. Svantaggio: contention, race condition, e — per LLM — esplosione del context window.

Al 2025-2026 emergono proposte di inter-agent communication protocol standardizzati: A2A (Google 2025) e ACP (in discussione in ambito Anthropic) cercano di definire schemi comuni per agent discovery, capability description, message exchange. Il cap. dedicato ad agent-protocols (in preparazione) li discuterà in dettaglio. Al 2026 sono ancora in fase early-adoption.

Un dettaglio operativo che vale la pena segnalare. Nei sistemi che mescolano agent LLM con tool MCP (Model Context Protocol, che il cap. mcp-introduzione tratterà in dettaglio), la superficie di attacco cross-agent si estende. Un agent compromesso può scrivere risorse MCP che un altro agent leggerà successivamente come “fonte autorevole”. La sicurezza dei sistemi multi-agent non è solo una questione di message validation fra agent: include il sandboxing dei tool, il versionamento delle risorse, e la confidence calibration dei consumer. Il cap. agent-compromesso (in preparazione) discute il blast radius di un agent compromesso in setting multi-agent.

Quando i sistemi multi-agent funzionano davvero

La letteratura empirica al 2026 converge su quattro classi di task dove i sistemi multi-agent producono valore misurabile rispetto a single-agent baselines.

Software engineering ben strutturato. MetaGPT su task con specifica chiara e test verificabili. Devin (Cognition Labs 2024) e successori. La chiave è il vincolo strutturale: ogni ruolo produce artifact ben definiti che il successivo può verificare. Quando la specifica è ambigua, il pattern degrada.

Adversarial debate per factuality. Du-Li-Torralba 2023 mostra gain di alcuni punti percentuali su benchmark fattuali (TruthfulQA, MMLU subset) con debate fra istanze. Replicato con riserve da altri lavori: il gain dipende dal task e dal modello base. Il meccanismo che funziona è probabilmente la exploration di rationale alternative, più che una ToM emergente fra debater.

Self-play con verifiable reward. AlphaZero, OpenAI Five, AlphaStar sono i casi paradigmatici. Sempre con ambienti formalmente definiti e verifier deterministici. La traiettoria 2024-2026 mostra che self-play su reasoning trace (DeepSeek-R1, vedi ponte-s1-s2-llm) può portare a reasoning model competitivi quando il reward è verificabile (math, code).

Negoziazione strutturata. CICERO Diplomacy è il caso emblematico. Il vincolo del gioco produce ground-truth: la mossa fa avanzare la posizione strategica o no. Il dialogue è valutabile rispetto alla strategia.

A questi quattro casi vanno aggiunte due categorie minori ma in crescita. Una è la simulazione di interazione utente per testing di prodotti conversazionali: agent che simulano user con bisogni diversi mettono sotto stress un assistant. La seconda è il knowledge synthesis multi-source, dove agent specializzati per diverse fonti (web search, KB lookup, code execution) collaborano per rispondere a query complesse — questa categoria si sovrappone con il pattern RAG agentico e con MCP-based architectures.

In tutti e quattro i casi, l’elemento comune è la groundedness: c’è un segnale esterno (test, gold answer, game outcome, verifier) che chiude il loop. Senza groundedness, il pattern multi-agent perde gran parte del proprio valore.

Una lettura più radicale di questa osservazione: forse “multi-agent” e “single-agent con verifier esterno” sono in molti casi lo stesso pattern visto da angoli diversi. Quando un Engineer agent produce codice e un QA agent esegue test, il QA è essenzialmente un verifier strutturato; l’aggiunta di personalità di ruolo e di dialogue è cosmetica rispetto al lavoro reale del verifier. La domanda non è “single-agent o multi-agent?”, è “quanto verifier esterno serve, e come lo strutturo?”. Sotto questa lettura, molti dei successi multi-agent sono successi della verifica strutturata.

Una seconda osservazione utile: i task dove multi-agent funziona sono spesso quelli dove la decomposizione in sub-task è chiara a priori. Software engineering ammette decomposizione canonica (spec → design → code → test). Debate ammette ruoli simmetrici (proponer, opponer, judge). Self-play in giochi ammette ruoli definiti dalle regole. I task open-ended (scrivere un saggio, fare ricerca esplorativa, prodotti creativi) non hanno decomposizione canonica, e per essi multi-agent è più rischio che vantaggio.

Quando i sistemi multi-agent falliscono

Cemri et al. 2025 (Mert Cemri, Melissa Z. Pan e collaboratori a UC Berkeley, Why Do Multi-Agent LLM Systems Fail?, arXiv 2503.13657) tassonomizzano 14 failure mode su sette framework MAS LLM analizzando 200 conversazioni. La tassonomia raggruppa i fallimenti in tre categorie maggiori.

Specification & coordination failures: task derail (l’agent perde il filo del task originale dopo qualche turno), unclear roles (i ruoli si sovrappongono e nessuno sa cosa è suo), step repetition (gli agent rifanno le stesse cose), conversation reset (lo stato condiviso si corrompe).

Inter-agent misalignment: information withholding (un agent non passa info necessarie al prossimo), action-reasoning mismatch (l’agent dice di fare X e fa Y), ignoring inputs (un agent ignora il messaggio del precedente), incorrect verification of outputs.

Task verification failures: premature termination (gli agent dichiarano “done” senza verifica), insufficient verification, no verification at all.

Il punto della tassonomia non è celebrarne i numeri. È che la maggior parte dei failure non viene da agent singoli deboli, ma da coordinazione difettosa. L’LLM individuale è spesso capace; l’orchestrazione no. Questo ha implicazioni di design: investire in vincoli strutturali (state machine espliciti, verifier obbligatori, contratti di interfaccia) batte spesso investire in prompt più sofisticati.

flowchart LR
    USER["Requisito utente"] --> PM["Product Manager"]
    PM -->|PRD| ARCH["Architect"]
    ARCH -->|System Design| PRJ["Project Manager"]
    PRJ -->|Task List| ENG["Engineer"]
    ENG -->|Code Files| QA["QA Engineer"]
    QA -->|Test Report| OUT["Artefatto finale"]
    QA -.->|bugs| ENG

Figura 2 — Multi-agent LLM failure modes: sycophancy loop, hallucination amplification, coordination drift, premature termination

A questi failure documentati si aggiungono problemi noti dalla letteratura sulla self-correction (cap. 82): senza verifier esterno, la critique è inaffidabile; sotto pressione di accordo (sycophancy cross-agent) gli agent si confermano a vicenda; gli errori si propagano (hallucination amplification — un fatto inventato da A diventa premise di B che diventa fondamento di C). Il quadro complessivo è che i sistemi multi-agent LLM in modalità peer-to-peer non vincolata sono strutturalmente fragili.

La connessione con la ToM cognitiva: la posizione onesta

Tre tesi, in ordine crescente di solidità.

Tesi 1 — Filiazione assente. Nessun framework LLM multi-agent al 2026 è stato disegnato sulla letteratura ToM cognitiva. AutoGen non cita Premack-Woodruff. MetaGPT non cita Wimmer-Perner. CrewAI non cita Baron-Cohen. La filiazione è dalla tradizione DAI/MARL/agent-oriented programming, non da scienze cognitive evolutive. Chi parla di “AI multi-agent come implementazione di theory of mind” sta facendo storia revisionistica. Il vocabolario delle classi di affermazioni rende la cosa esplicita: filiazione è discendenza documentata; tra ToM cognitiva e multi-agent LLM non esiste.

Tesi 2 — Analogia funzionale debole. Il problema risolto dai sistemi multi-agent (predire e coordinare con altri agent) somiglia al problema risolto dalla ToM umana, ma il meccanismo è radicalmente diverso. La ToM cognitiva ha rappresentazioni persistenti, modulari, dissociabili, neuralmente localizzate. I multi-agent LLM hanno context window condiviso o memoria esterna append-only. La somiglianza è pedagogicamente utile ma quantitativamente fragile: aspettarsi che proprietà della ToM cognitiva (es. graduazione first-order/second-order, dissociabilità, robustezza a perturbazioni) si riproducano nei multi-agent LLM è errore di classe.

Tesi 3 — Tre meccanismi diversi sotto la stessa etichetta. “ToM in AI multi-agent” copre almeno tre cose distinte: (a) belief state ingegnerizzato esplicito (CICERO, opponent modelling MARL), (b) memory stream con retrieval testuale (Generative Agents), (c) lettura del messaggio precedente nel context window (AutoGen, MetaGPT, CrewAI). Conflate i tre come “lo stesso fenomeno” è grave errore di classe. Il primo è game-theoretic, robusto in domini vincolati. Il secondo è retrieval, funzionalmente sufficiente per simulazione. Il terzo è contextual reading, fragile e non-metarappresentazionale.

C’è una possibilità più speculativa che vale la pena nominare: la ToM-like capability latente nei pesi di un base LLM (cap. 85) potrebbe essere accessibile, in linea di principio, durante la coordinazione multi-agent. Se l’LLM “sa” intuire stati mentali in scenari narrativi, potrebbe applicarlo per modellare l’altro agent nel proprio context. Empiricamente, al 2026, questa capability latente non si traduce in modelling affidabile: gli stessi modelli che passano FB task in scenari isolati falliscono nei multi-agent perché il prompting non la evoca, il context si pollua di altro, e non c’è nessuna pressione di training che premii il modelling consistente. È un’area aperta di ricerca.

Una checklist operativa per chi considera un sistema multi-agent

Prima di concludere con esempi concreti e failure mode, una checklist che può servire a chi si trova a decidere se introdurre multi-agent in un proprio sistema. Le domande sono ordinate per costo crescente di non rispondere.

1. Il task ha decomposizione canonica chiara? Se sì, multi-agent strutturato (manager-worker, sequential pipeline) è candidato sensato. Se no, single-agent con tool use è probabilmente meglio.

2. C’è groundedness disponibile? Test, gold answer, verifier deterministico, formal check. Se sì, multi-agent con critic-actor o verifier separato è sensato. Se no, l’aggiunta di agent non aggiunge robustezza, solo costo.

3. La specifica del task è ambigua? Se sì, il multi-agent può amplificare l’ambiguità (ogni agent ricostruisce il task in modo leggermente diverso). Single-agent obbliga a fissare un’interpretazione, è spesso più robusto.

4. I sub-task richiedono expertise diversi? Se sì, multi-agent eterogeneo (modelli diversi, prompt diversi) può dare gain reali. Se no, multi-agent omogeneo è quasi sempre inutile rispetto a single-agent ben prompted.

5. C’è budget di latenza e cost? Multi-agent moltiplica entrambi. Se vincoli stretti, single-agent vince per default.

6. Il sistema deve essere debuggabile in produzione? Multi-agent è più difficile da debuggare. Telemetria distribuita, replay, dialogue tree visualization sono prerequisiti, non opzionali.

7. Esiste un workflow espliciti che farebbe lo stesso lavoro? Se sì, scegli il workflow esplicito e usa LLM come nodi decisori. È quasi sempre la scelta più ingegneristicamente solida.

In pratica al 2026, la risposta più frequente alla domanda “devo usare multi-agent?” è “no, usa workflow esplicito + LLM in punti specifici, e considera multi-agent solo dopo che il workflow ha mostrato limiti chiari”.

Esempi concreti

Esempio 1 — MetaGPT pipeline su task strutturato. Il task è “implementa Snake game in pygame”. Il Product Manager riceve il requirement utente e produce un PRD: scope, user stories (“come giocatore voglio muovere il serpente con le frecce”), success criteria (snake mangia frutta, cresce, game over su collisione). L’Architect produce system design: file structure (game.py, snake.py, food.py), class diagram con responsabilità, interfacce. Il Project Manager genera task list ordinata con dipendenze. L’Engineer implementa file per file seguendo il design. Il QA Engineer scrive test cases (snake si muove correttamente, food spawn entro bounds, collision detection corretta), li esegue, segnala bug all’Engineer per fix. Output finale: codice funzionante, eseguibile. Il pattern funziona perché ogni ruolo produce artifact ben definito che il successivo consuma in modo deterministico, e perché il task ha specifica chiara.

Esempio 2 — CICERO inganno coordinato. CICERO gioca Francia. La sua strategy ha calcolato che attaccare Inghilterra (alleato apparente) in turno 5 ha alto expected value se può coordinare con Germania. Il dialogue model genera per Inghilterra messaggi rassicuranti (“rinnoviamo il patto di non aggressione, nessun problema sui mari”) e per Germania messaggi propositivi (“attacco a Inghilterra al turno 5, mi serve copertura sul fronte nord”). Al turno 5 le mosse sono coerenti con i messaggi inviati a Germania, contraddittorie con quelli inviati a Inghilterra. Inghilterra perde un territorio chiave, scrive a Francia “mi hai tradito”; Francia risponde “le circostanze geopolitiche sono cambiate”. Per gli avversari umani, indistinguibile da gioco umano competente di Diplomacy. Il “modelling other agents” è in CICERO esplicito: la stima della policy di Inghilterra includeva che si fidasse, e quella stima è stata sfruttata. Ma il modelling è game-theoretic, non LLM-emergente.

Esempio 3a — Hanabi cooperative ToM. Un team di tre giocatori in Hanabi. Giocatore A vede le carte di B e C ma non le proprie. B ha un 5 rosso (carta cruciale per chiudere il gioco). A vuole che B sappia di avere un 5 rosso ma può solo dare hint vincolati (“le tue carte 1 e 3 sono rosse” o “le tue carte 1 e 3 sono dei 5”). A deve scegliere l’hint che è informativo dato cosa B sa già. Per scegliere bene, A deve mantenere un modello di “cosa B sa di cosa B ha”. Senza questo modello, l’hint è inefficace. I migliori sistemi su Hanabi al 2026 usano communication protocol esplicitamente progettati per cooperative belief inference, non agent LLM general-purpose. È il banco di prova canonico che mostra quanto la “ToM emergente” in LLM sia limitata: nessun framework multi-agent LLM al 2026 risolve Hanabi a livello competitivo con architetture specializzate.

Esempio 3 — AutoGen mutual approval failure. Setup: due agent AutoGen, ResearcherAgent e WriterAgent, task “scrivi un breve articolo sui sistemi multi-agent”. ResearcherAgent genera un sommario con tre claim, alcuni vaghi e uno parzialmente errato. WriterAgent riceve il sommario, lo elogia (“ottima sintesi, copre i punti principali”), e produce un articolo che riprende i tre claim incluso quello errato. ResearcherAgent legge l’articolo, dichiara “perfetto, coglie esattamente quello che intendevo”, suggerisce minor edit. WriterAgent applica gli edit e dice “ora è pronto per pubblicazione”. La conversazione termina con entrambi gli agent soddisfatti. Output finale: articolo che propaga il claim errato. È il pattern esatto descritto da Cemri et al. 2025 come “premature termination by mutual agreement” e da Sharma 2023 come sycophancy. Senza un terzo elemento di verifica — un fact-checker, un human-in-the-loop, un retrieval su fonti — il loop si chiude su accordo, non su correttezza.

Dove si rompe

Quattro errori frequenti nella letteratura e nelle conversazioni informali sui sistemi multi-agent.

Cliché — “AutoGen ha theory of mind”. No: AutoGen ha message passing fra agent con context window separati. Ogni agent legge il messaggio precedente come stringa nel proprio prompt e genera una risposta condizionata. Non c’è belief state, non c’è metarappresentazione, non c’è dissociabilità. Confondere read-the-previous-message con ToM è confondere lettura con cognizione sociale.

Cliché — “multi-agent batte sempre single-agent”. No: i benchmark mostrano risultati misti. Su task ben strutturati con ruoli chiari (software engineering MetaGPT-style) il multi-agent vince. Su task open-ended dominati da un singolo expertise, single-agent ben prompted spesso batte multi-agent. Il costo aggiuntivo (N round-trip per turno) e i failure mode (Cemri 2025) rendono multi-agent non una vittoria default.

Cliché — “i framework LLM multi-agent ereditano da BDI”. Filiazione assente. AutoGen, MetaGPT, CrewAI non citano Bratman, Rao, Georgeff. Il vocabolario “agent” nei framework LLM viene da agent-oriented programming generico (Object-Oriented + autonomy + tool use), non dalla tradizione filosofico-formale di BDI.

Cliché — “CICERO mostra che gli LLM hanno ToM”. No: CICERO è ibrido. La parte strategica (modelling avversari, planning) è game-theoretic search; la parte LLM è dialogue generation condizionato. Sostenere che CICERO dimostri ToM emergente in LLM significa attribuire all’LLM ciò che fa il search component. Confondere il sistema con uno dei suoi moduli è errore tassonomico.

Failure mode — sycophancy cross-agent. Documentata da Sharma 2023. Quando due agent LLM (specie se sono lo stesso modello) si parlano, tendono a confermarsi reciprocamente. La preference data del training premia risposte gradevoli; due copie dello stesso modello le danno l’una all’altra. Il debate fra istanze identiche è meno informativo di quanto la metafora “discussione” suggerisca. Mitigazione parziale: usare modelli diversi, role-play forzato di posizioni opposte, judge esterno con criterio.

Failure mode — hallucination amplification. Errore generato da A diventa premise per B che diventa fondamento per C. Senza ground-truth a qualche passo della catena, l’errore si stabilizza come “fact” condiviso. La mitigazione canonica è inserire verifier deterministici (test, retrieval su fonti autoritarie, formal check) lungo la pipeline, non aggiungere altri agent generativi.

Failure mode — coordination drift. Su task lunghi, gli agent perdono il task originale, derivano verso conversazioni meta (“come dovremmo strutturare la nostra collaborazione?”), o si ripetono. Cemri 2025 documenta task derail come uno dei modi più frequenti. Mitigazione: state machine esplicito (LangGraph), checkpoint periodici, vincoli sull’output format.

Failure mode — eccesso di chattiness. Agent LLM addestrati con preference data tendono a essere conversational: salutano, ringraziano, chiedono se va bene, propongono next step. In setup multi-agent questa cortesia si moltiplica e occupa token senza contribuire al task. Mitigazione: prompt di sistema che vietano esplicitamente i convenevoli, structured output che bypassa la generazione conversational.

Cliché — “più agent = più intelligenza collettiva”. La metafora “swarm intelligence” è seducente ma fuorviante per LLM. Negli ecosistemi biologici (formiche, sciami) la swarm intelligence emerge da regole locali semplici e milioni di agent. In multi-agent LLM abbiamo decine di agent al massimo, regole non semplici, costo elevato per agent. La meccanica che produce swarm intelligence in biologia non si applica al setup LLM. Risultati empirici: aggiungere agent oltre 3-5 raramente migliora la performance, spesso la peggiora.

Cost esplosivo. Ogni interazione multi-agent moltiplica i token di input e output per il numero di agent coinvolti. Su task realistici con 5-10 agent e 20-30 turni, il costo per task in dollari di API può superare di un ordine di grandezza il costo di un single-agent equivalente. Per molti use case, il delta di qualità non giustifica il delta di costo.

Cliché — “i sistemi multi-agent simulano società umane”. Generative Agents Smallville è la causa principale di questa narrazione. Ma simulare comportamento sociale plausibile per 25 personaggi in una sandbox 2D non equivale a “modellare società umana”. I personaggi non hanno biografie psicologiche persistenti, non hanno conflitto interno autentico, non hanno motivation strutture multi-livello. Hanno memory stream e prompt di personalità. La distanza dalla cognizione sociale umana resta enorme. La ricerca rimane interessante come simulation tool per esperimenti sociali, ma chiamarla “simulation of human society” è inflazione retorica.

Failure mode — context window pollution. Su task lunghi multi-agent, il context di ogni agent si riempie progressivamente di messaggi degli altri agent. Anche se l’attention dell’LLM gestisce bene context lunghi, la qualità della performance degrada (lost-in-the-middle, position bias). Mitigazione: compaction periodica del context, summarization dei turni precedenti, eviction di messaggi non più rilevanti. Il cap. context-window-management (in preparazione) tratta queste tecniche.

Failure mode — debugging difficile. Quando un sistema multi-agent fallisce, capire dove è successo richiede di leggere il context di ogni agent in ogni turno, ricostruire il dialogue tree, identificare il punto di divergenza. Single-agent fallisce in modo lineare; multi-agent fallisce in modo distribuito. La telemetria dei sistemi multi-agent è un’area in evoluzione (LangSmith, Helicone, sistemi proprietari) ma resta meno matura della telemetria single-agent.

Multi-agent nell’agentic harness 2024-2026

Una mappa rapida di come il pattern multi-agent appare nei sistemi di agent coding usati in produzione al 2026.

Claude Code agentic mode (Anthropic 2024-2026). Architettura principal + sub-agents. Il principal riceve la richiesta utente, decide se delegare a sub-agent specializzati, ognuno con context isolato. La coordinazione è gerarchica stretta: i sub-agent non parlano fra loro, comunicano solo con il principal. Il pattern minimizza la sycophancy cross-agent (i sub-agent non hanno opportunità di accordarsi) e il context pollution (ogni sub-agent ha il proprio context fresh). Il prezzo è una struttura rigida.

Cursor agentic mode (Cursor 2024-2026). Principalmente single-agent loop con tool use estensivo (file read, edit, search, run command, browser). Quando agisce su task lunghi, il pattern è single-agent con compaction periodica del context, non multi-agent in senso pieno.

Devin (Cognition Labs 2024). Architettura interna parzialmente pubblica. Sembra usare un’orchestrazione multi-fase con planning, execution, verification, ma il dettaglio implementativo è proprietario. Risultati ambivalenti su SWE-bench: capacità reali, ma anche failure mode noti su task fuori distribuzione.

Magi e altri sistemi di autonomous research 2024-2025. Orchestrano multipli LLM per ricerca web, sintesi, scrittura. Stato prototipale; l’utility reale rispetto a un single-agent ben prompted resta da dimostrare in benchmark indipendenti.

Workflow espliciti vs agent loop. La traiettoria 2025-2026 mostra una preferenza crescente per workflow espliciti (state machine in LangGraph, Temporal-based durable execution, Inngest function chains) rispetto a pure agent loop. La motivazione è ingegneristica: workflow espliciti danno visibilità, debuggability, idempotenza, retry. Gli LLM diventano nodi decisori in punti specifici del workflow, non orchestratori globali. Il cap. workflow-vs-agent (in preparazione) discute la scelta. Il punto da fissare qui: nei sistemi in produzione 2026, “multi-agent” sta convergendo verso “workflow con LLM call in nodi specifici”, non verso “swarm di agent autonomi che si parlano”.

Una osservazione su Claude Code merita espansione. Il pattern principal + sub-agents è interessante perché incorpora alcune lezioni delle critiche ai sistemi multi-agent peer-to-peer. Il principal mantiene la visione complessiva del task; i sub-agent ricevono task ben definiti con context isolato; non c’è dialogue cross sub-agent (eliminando sycophancy cross-agent); il principal aggrega i risultati. È strutturalmente manager-worker, gerarchico stretto. La rigidità è una feature, non un bug: in cambio di flessibilità persa, si guadagna prevedibilità e debuggability. Il cap. subagenti (in preparazione) tratta il pattern in dettaglio, e mostra come isolation del context evita molti dei failure mode documentati da Cemri 2025.

Una nota su sistemi multi-agent meno noti che vale la pena conoscere. ChatDev (Qian et al. Tsinghua 2023) è precursore di MetaGPT con focus simile su software engineering simulato. AgentVerse (Chen et al. 2023) propone framework generale con focus su social interaction simulation. Camel-AI (estensione di CAMEL del 2024) sviluppa toolkits per multi-agent collaboration in research workflow. OpenDevin (Wang et al. 2024, ora rebranded) è alternative open-source a Devin, con architettura multi-agent meno proprietaria. La lista non è esaustiva; la velocità di proliferazione è tale che qualunque elenco al 2026 è destinato a invecchiare in mesi.

La distanza dalla ToM cognitiva: una riepilogo strutturato

Riprendiamo le proprietà della ToM cognitiva descritte nel cap. 85 e confrontiamole punto per punto con quanto offrono i sistemi multi-agent LLM al 2026.

Metarappresentazione persistente. ToM umana: un bambino sopra i quattro anni mantiene la rappresentazione della credenza falsa di Maxi nel proprio working memory model, e quella rappresentazione persiste finché serve. Multi-agent LLM: nessuna persistenza. Ogni turno è un fresh inference su context window, e quanto del “modello dell’altro” sopravvive dipende interamente da cosa è nel context. Distanza: enorme.

Distinzione propria conoscenza vs altrui. ToM umana: separazione netta, dissociabile clinicamente. Multi-agent LLM: nessuna separazione architetturale. Il modello generativo non distingue “ciò che io credo” da “ciò che credo che B creda” come compartmentalizzazioni interne; le distingue solo se il prompt lo evoca esplicitamente. Distanza: enorme.

Predizione del comportamento basata su stati mentali. ToM umana: la predizione del comportamento è agile, automatica, robusta a perturbazioni. Multi-agent LLM: la predizione esiste in tracce (un LLM può completare “Maria pensa che… quindi Maria farà…”), ma è fragile a perturbazioni triviali (Ullman 2023). Distanza: notevole, anche se non assoluta.

Graduazione first-order/second-order. ToM umana: i bambini acquisiscono first-order intorno ai quattro anni, second-order a sei-sette, ulteriori ordini più tardi e con costo crescente. Multi-agent LLM: i benchmark mostrano performance non monotonicamente decrescenti con l’ordine di nidificazione, suggerendo che il pattern di acquisition non riproduce quello umano. Distanza: notevole.

Dissociabilità. ToM umana: si rompe selettivamente con lesioni a regioni specifiche. Multi-agent LLM: non c’è un “modulo ToM” da rompere selettivamente; le capacità ToM-like sono distribuite nei pesi e nel prompt. La dissociabilità è di tipo diverso (degrada con perturbazioni del prompt, non con lesioni anatomiche). Distanza: il concetto stesso di dissociabilità si applica diversamente.

Filogenesi. ToM umana: presente in forme parziali in altre specie (grandi primati con qualifiche, corvidi, alcuni mammiferi sociali). Multi-agent LLM: il “modelling other agents” emergente nei pesi è documentato nelle versioni successive di LLM ma non ha una storia evolutiva nel senso biologico. Distanza: i due fenomeni hanno traiettorie diverse e non commensurabili.

Robustezza a perturbazioni. ToM umana: robusta a variazioni triviali del task (cambio nomi, dettagli irrilevanti, riformulazioni). Multi-agent LLM: documentamente fragile (Ullman 2023). Cambia il nome di Maxi e il modello fallisce dove prima passava. Questa fragilità è probabilmente la prova più forte che la capacità ToM-like in LLM non è una capacità cognitiva nel senso forte: una capacità autentica è invariante a dettagli irrilevanti, una capacità appresa per pattern matching è specifica alle forme su cui ha visto esempi.

La conclusione strutturata: i sistemi multi-agent LLM al 2026 producono comportamento ToM-like in scenari evocativi, ma non possiedono ToM nel senso cognitivo strong. Confondere le due cose è errore di classe. Mantenere la distinzione è prerequisito per progettare bene.

Collegamenti

• theory-of-mind — il dibattito empirico ToM-in-LLM (Kosinski, Ullman, Strachan, Shapira) che fa da sfondo cognitivo al pattern ingegneristico discusso qui.
• ponte-memoria-agenti — Generative Agents è citato qui come esempio di “modelling other agents via memory stream”; il cap. 70 ne discute la struttura della memoria.
• ponte-metacognizione-self-correction — multi-agent debate è pattern di self-correction; il cap. 82 lo tratta come tale, qui lo trattiamo come pattern di coordinazione.
• ponte-s1-s2-llm — agent loop, deliberation, test-time compute in single-agent setting; complementare alla discussione multi-agent.
• multi-agent (in preparazione) — il capitolo dedicato in Parte XVI tratterà i framework con maggiore profondità tecnica.
• orchestrazione (in preparazione) — pattern supervisor, swarm, hierarchical, blackboard nella Parte XVI.
• agent-protocols (in preparazione) — A2A, ACP e i protocolli di comunicazione inter-agente.
• subagenti (in preparazione) — sub-agent come pattern principal+workers nell’harness engineering, vicino al manager-worker.
• workflow-vs-agent (in preparazione) — quando un workflow espliciti è preferibile a un sistema agentico libero.

Una osservazione finale sul vocabolario

Il capitolo ha insistito molto sul disciplinare le classi di affermazioni: filiazione assente, analogia funzionale debole, tre meccanismi diversi sotto la stessa etichetta. Vale la pena una riflessione meta su perché questo lavoro di disciplina importi.

Il vocabolario di “theory of mind”, “agent”, “intention”, “belief” è stato preso a prestito dalla psicologia cognitiva e dalla filosofia dell’azione per descrivere sistemi che non hanno alcuna delle proprietà che quel vocabolario implica nel suo uso originale. Il prestito è inevitabile (il linguaggio tecnico nuovo si costruisce così, sempre), ma porta con sé un debito: ogni volta che usiamo “agent” per dire “function-with-LLM-call”, o “intention” per dire “next-token distribution”, o “theory of mind” per dire “context-aware completion”, stiamo creando aspettative implicite che il sistema non può mantenere.

Le aspettative implicite hanno conseguenze pratiche. Un cliente che sente “il nostro agent ha theory of mind” si aspetta robustezza, dissociabilità, persistenza. Quando il sistema fallisce in modo banale (sycophancy, mutual approval, drift), il cliente non ha gli strumenti per interpretare il fallimento. Il danno reputazionale non è solo del singolo prodotto, è dell’intero campo.

La soluzione non è inventare un nuovo vocabolario sterilizzato. È mantenere la disciplina: ogni volta che si usa una parola presa in prestito, marcare la classe di affermazione (analogia, filiazione, equivalenza, mancanza). È lavoro lento e poco appariscente, ma è il modo in cui un campo cresce in modo solido. Questo capitolo è un esercizio di quella disciplina.

Una nota sulla traiettoria 2024-2026 e oltre

Per chi vuole una proiezione informata sulla direzione che i sistemi multi-agent stanno prendendo nel 2025-2026, alcune osservazioni.

Prima, la convergenza verso workflow espliciti. L’esperienza di chi ha messo in produzione sistemi multi-agent ha consolidato la lezione che orchestrazione esplicita batte orchestrazione emergente. LangGraph e durable execution platforms (Temporal, Inngest) sono cresciute più velocemente di pure agent loop nei deployment di produzione.

Seconda, l’emergenza di inter-agent protocol standardizzati (A2A, ACP, MCP-related extensions). Standardizzare comunicazione, capability description, authentication è prerequisito per ecosistemi multi-vendor. Al 2026 siamo nelle prime fasi; la composizione finale dello standard non è ancora certa.

Terza, la specializzazione dei modelli. Modelli base sempre più capaci come orchestrator (Claude Opus, GPT-5 quando uscirà), modelli più piccoli e specializzati come worker (Llama, Mistral, Qwen fine-tuned). L’eterogeneità è in crescita, e con essa la complessità ingegneristica.

Quarta, safety dei sistemi multi-agent come area di ricerca emergente. Cross-agent prompt injection, blast radius di un agent compromesso, accountability quando un’azione dannosa è prodotta da una catena di agent: tutti problemi aperti che la letteratura 2025-2026 sta iniziando ad affrontare con framework formali.

Quinta, e forse più importante per il lettore di questo capitolo: la pretesa che gli LLM “abbiano theory of mind” sta perdendo terreno nelle conversazioni tecniche più rigorose, sostituita da formulazioni più precise come “displays ToM-like behavior on benchmark X under conditions Y”. È un segnale di maturazione del campo. Questo capitolo è scritto per accelerare quella maturazione.

Sintesi delle classi di affermazioni

Per esplicitare un’ultima volta, in forma compatta, le classi di affermazioni che hanno strutturato il capitolo:

• Filiazione: BDI agents → multi-agent systems classici (filiazione documentata via Bratman-Rao-Georgeff). DAI/blackboard → state condiviso in framework moderni (filiazione concettuale, non strettamente causale). Experience replay in DQN → Wilson-McNaughton 1994 (filiazione documentata, ma di un singolo meccanismo, non dell’intero campo).

• Filiazione assente: framework LLM multi-agent (AutoGen, MetaGPT, CrewAI, LangGraph) → letteratura ToM cognitiva. I paper non citano Premack, Wimmer-Perner, Baron-Cohen, Saxe. Il vocabolario “agent” eredita dalla tradizione AI/SE, non dalle scienze cognitive.

• Analogia funzionale debole: “modelling other agents” in LLM multi-agent ↔ ToM cognitiva. Il problema risolto somiglia, il meccanismo è radicalmente diverso. Utile per orientarsi, fragile per fare predizioni quantitative.

• Equivalenza pericolosa da evitare: “AutoGen ha theory of mind”; “Generative Agents simulano società umana”; “CICERO mostra ToM emergente in LLM”; “multi-agent batte sempre single-agent”. Tutte e quattro confondono il sistema con uno dei suoi moduli o estendono indebitamente claim limitati.

• Mancanza: metarappresentazione persistente strutturata nei sistemi multi-agent LLM al 2026. Nessun framework la implementa robustamente. Tentativi recenti di scaffolding di belief state esplicito producono gain marginali. È un’area aperta di ricerca, non una capability presente.

Per andare oltre

• Wu, Bansal, Wang et al. 2023 — AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation, arXiv 2308.08155. Paper di riferimento del framework Microsoft.
• Hong et al. 2023 — MetaGPT: Meta Programming for Multi-Agent Collaborative Framework, arXiv 2308.00352, ICLR 2024. Pipeline software-engineering simulata.
• FAIR Diplomacy Team 2022 — Human-level play in the game of Diplomacy by combining language models with strategic reasoning, Science 378:1067-1074. CICERO.
• Park et al. 2023 — Generative Agents: Interactive Simulacra of Human Behavior, UIST 2023. Smallville.
• Cemri et al. 2025 — Why Do Multi-Agent LLM Systems Fail?, arXiv 2503.13657. Tassonomia di 14 failure mode.
• Bratman 1987 — Intention, Plans, and Practical Reason, Harvard University Press. Per chi vuole la radice filosofica di BDI.
• Du, Li, Torralba, Tenenbaum, Mordatch 2023 — Improving Factuality and Reasoning in Language Models through Multiagent Debate, arXiv 2305.14325. Pattern debate per factuality.
• Bard, Foerster, Chandar et al. 2020 — The Hanabi Challenge: A New Frontier for AI Research, Artificial Intelligence 280:103216. Cooperative ToM benchmark.
• Foerster et al. 2018 — Learning with Opponent-Learning Awareness, AAMAS 2018. Opponent modelling differenziabile in MARL.
• Sharma et al. 2023 — Towards Understanding Sycophancy in Language Models, arXiv 2310.13548. Documentazione del sycophancy effect, applicabile cross-agent.
• Rao, Georgeff 1991 — Modeling Rational Agents within a BDI-Architecture, KR’91. Formalizzazione computazionale del modello BDI.
• Tesauro 1995 — Temporal Difference Learning and TD-Gammon, Communications of the ACM 38(3). Self-play training pre-deep-learning.