🧙 Maestro Yoda Cap. 22 · Agenti, tool use, RAG

Puntata 243

Puntata 243 — Multi-agent: supervisori, swarm, orchestrazioni

Livello: 🧙 Maestro Yoda · Capitolo 22 · Agenti, tool use, RAG

“Se un agente è buono, cinque agenti che collaborano saranno cinque volte meglio.” Sembra logico. È quasi sempre falso. Multi-agent funziona, ma in casi precisi e con pattern precisi. Capirli è la differenza tra una “fabbrica di agenti che fanno cose vere” e una “demo di marketing con cinque LLM che si parlano addosso”.

una sala riunioni con 5 figure stilizzate intorno a un tavolo: il “Supervisore” al centro, “Researcher”, “Writer”, “Critic”, “Coder” intorno. Cartelli sopra ognuno. Sul tavolo un “task” scritto. Sotto: “ognuno fa la sua parte. Se lo fanno tutti, è un’azienda. Se nessuno coordina, è il caos”

Cos’è un sistema multi-agent

Sistema in cui più LLM lavorano insieme su un task, ognuno specializzato per ruolo, dominio o capability. Si scambiano messaggi, si delegano sotto-task, condividono memoria.

L’idea ha radici accademiche profonde (MAS — Multi-Agent Systems, anni ‘80). Applicata agli LLM ha avuto due grandi ondate:

  • 2023 (AutoGPT, BabyAGI): prima sperimentazione, molto fragile, molto hype, pochi risultati production.
  • 2024-26 (LangGraph, CrewAI, AutoGen, MetaGPT): pattern più maturi, focus su workflow specifici dove funziona davvero.

Quando multi-agent funziona

Tre condizioni:

a) Decomposizione naturale del task

Il problema si spezza in sotto-problemi di natura diversa. Esempi:

  • Ricerca + scrittura + review (research paper).
  • Coding + testing + debug (sviluppo software).
  • Marketing copy + image gen + scheduling (social campaign).

Se il task è atomico, multi-agent aggiunge solo overhead.

b) Specializzazione utile

Un singolo modello generico fa benino tutto. Più modelli/prompt specializzati fanno meglio ognuno il loro pezzo. Esempi:

  • Coder specializzato (Claude Sonnet o GPT-5 con system prompt code-only) → scrive meglio.
  • Reviewer separato (stesso o altro modello) → critica meglio se non ha scritto il codice.
  • Persuader vs Critic → tensioni costruttive (dialectic reasoning).

c) Verification step richiesta

Un agente esecutore + un agente verificatore = pipeline più robusta. Il secondo cattura errori del primo che lui stesso non vedrebbe (self-criticism bias).

Quando multi-agent NON serve

Anti-pattern comuni:

  1. “Tante voci, una sola persona”: 5 agenti che fanno la stessa cosa con prompt leggermente diversi. Voting? Quasi mai migliore di un singolo agente ben tunato.
  2. Task semplice/atomico: traduzione, riassunto, classificazione. Un agente basta.
  3. Latency-critical: ogni hop tra agenti aggiunge 1-3 secondi.
  4. Costo-critical: 5 agenti = 5-10× costo di 1 agente per stesso task.

Regola: prova con 1 agente + ReAct + tool. Se non basta, 2 agenti (executor + critic). Se ancora non basta, 3-4 (specializzati). Sopra è raro che paghi.

Le 4 architetture multi-agent canoniche

1. Supervisor (Manager) pattern

Un agente “supervisore” riceve il goal, decompone, delega a sub-agent specializzati, aggrega risultati.

[User goal]
     ↓
[Supervisor] ─── decomposes ─── [SubAgent A] (researcher)
     │                          [SubAgent B] (writer)
     │                          [SubAgent C] (critic)
     ↓
[Aggregated response]

Pro: chiaro, predictable, single point of decision. Contro: il supervisor è bottleneck; deve essere capace. Quando: il task ha una struttura nota a priori. Framework: LangGraph supervisor template, CrewAI hierarchical.

2. Sequential pipeline

Catena fissa: agent A → agent B → agent C. Output di uno = input del successivo.

[User] → [Researcher] → [Writer] → [Editor] → [Output]

Pro: semplice, debuggabile. Contro: nessun branching/adaptation; fragile a errori intermedi. Quando: workflow fisso noto (content production pipeline). Framework: CrewAI sequential, LangChain SequentialChain.

3. Network / peer-to-peer (swarm)

Agenti come “rete”, ognuno può parlare con ognuno. Nessun supervisore esplicito.

[Agent A] ↔ [Agent B]
    ↕         ↕
[Agent C] ↔ [Agent D]

Pro: massima flessibilità, emergent behavior. Contro: difficile da debuggare, può divergere, costoso. Quando: research-y, problemi di esplorazione (es. brainstorming, debate simulations). Framework: AutoGen, CAMEL.

4. Specialized actors (esecutore + verificatore + scrittore)

Pattern minimale 2-3 agenti:

  • Actor: esegue.
  • Critic: valuta, segnala errori.
  • (opzionale) Refiner: applica correzioni.

Loop fino a convergenza o max iterations.

Pro: significant quality boost (10-30% su task creativi e coding) per costo 2-3×. Contro: ancora costoso, può loop-are. Quando: production-grade quality su task generativi (codice, scrittura tecnica, design). Framework: LangGraph 2-node loop, MetaGPT, ChatDev.

Pattern di comunicazione

Message-passing strutturato

Ogni messaggio tra agenti ha schema: from, to, task, payload, expects. Riduce ambiguità ma è verboso.

Shared scratchpad

Tutti gli agenti scrivono/leggono da una “lavagna” comune (un file, un buffer). Semplice ma context cresce e diventa caotico.

Topic-based pubsub

Agenti pubblicano su topic (“design_decisions”), si sottoscrivono a topic. Scala meglio per N agenti.

RPC-style call

Un agente chiama un altro come una funzione (writer.generate(brief)), aspetta risposta. Pattern più comune per supervisor + sub-agent.

Sfide pratiche del multi-agent

a) Coordination overhead

Ogni hop tra agenti costa: messaggi, parsing, context re-inject. Per task <1 min, single-agent è quasi sempre più veloce.

b) Error propagation

Errore al step 2 si propaga al step 5, amplificato. La probabilità di success cala col numero di hop (vedi puntata 235).

c) Context bloat

Ogni agente accumula history. Multi-agent → multi-history. Costo esplode.

d) Dialogue infinite loops

Agenti che si rilanciano la palla all’infinito (“io non ho deciso, decidi tu”, “ma tu sei l’expert”). Max-iteration cap obbligatorio.

e) Eval difficile

Come misuri la performance di un team? Per ogni agente? Per il sistema? Spesso solo end-to-end (success rate sul goal).

f) Determinismo basso

Variazioni casuali in un agente si amplificano nel team. Replay esatto è praticamente impossibile.

Framework popolari 2026 (dettaglio)

LangGraph

  • Approccio graph-based: nodi sono agent, edge sono transizioni.
  • Conditional edges per branching.
  • State machine esplicito.
  • Standard de facto per multi-agent production.
  • Production-ready, observability buona.

CrewAI

  • Approccio role-based: definisci agent con role, goal, backstory, tools.
  • 2 modi: sequential o hierarchical.
  • Sintassi pulita, ottimo per prototipi.
  • Maturità migliorata 2024-26.

AutoGen (Microsoft)

  • Approccio conversational: agent si parlano in conversazione, supervisor o gruppo.
  • Forte per pattern di debate/critic.
  • Ricerca-oriented, complesso per production puro.

Smolagents (HuggingFace)

  • Approccio code-generation: l’agent emette codice Python che esegue azioni (incluso chiamare altri agenti). Minimalista.
  • Adatto a research e prototipi.

MetaGPT

  • Multi-agent per software engineering: PM, architect, engineer, QA. Workflow strutturato per generare codebase.
  • Specifico, non general-purpose.

Anthropic Claude Agent SDK

  • Primitive per costruire agenti, con sub-agent support.
  • Strettamente integrato con Claude e MCP.

OpenAI Agents SDK / Swarm

  • Primitive ufficiali OpenAI per multi-agent.
  • Handoff pattern: un agente passa il controllo a un altro.

Caso pratico: ricerca + scrittura tecnica

Use case: “Scrivi un blog post di 1500 parole su ‘Mixture of Experts’”.

Soluzione single-agent: chiedi a Claude/GPT, ottieni qualcosa di passabile in 30 secondi.

Soluzione multi-agent (LangGraph):

[Planner agent]: decompone in: outline + sezioni + esempi + citazioni
        ↓
[Researcher agent]: ricerca paper su arXiv + sintetizza
        ↓
[Writer agent]: scrive ogni sezione
        ↓
[Critic agent]: valuta accuracy, suggerisce fix
        ↓ (loop max 2 iterations)
[Writer agent]: applica fix
        ↓
[Editor agent]: rifinisce stile, controlla flow
        ↓
[Final post]

Outcome: qualitativamente meglio del single-agent (più accurato, citazioni vere). Costo: 5-10× ($0.50-1.50 vs $0.05-0.20). Tempo: 3-8 minuti vs 30 secondi.

Vale la pena? Sì se il valore del post finale giustifica il differenziale. No per contenuti volume-based generici.

Pattern emergenti 2026

Hierarchical multi-agent

Supervisor → sub-supervisor → workers. Strutture a 3-4 livelli per task molto complessi.

Mixture of Agents (MoA)

Più agenti producono risposte indipendenti per la stessa query; un “aggregator” sintetizza. Boost di quality measurato su benchmark (Wang et al., 2024).

Self-evolving teams

Agent che ridefiniscono i ruoli/prompt degli altri agent in base a fallimenti. Frontier research.

Agentic-RAG-as-team

Retrieval agent + reasoning agent + citation agent collaborano. Boost su RAG complessi.

Human-in-the-loop checkpoint

Multi-agent ma con checkpoint umani: l’umano approva ogni transizione critica. Riduce errori, aumenta latency. Standard per workflow ad alto rischio.

Costi e ROI realistici

Multi-agent costa:

  • Token: 3-10× single-agent per stesso task.
  • Latency: 3-10× single-agent.
  • Dev time: 5-20× per costruirlo robusto.
  • Eval & debug: difficile, costoso, continuativo.

ROI positivo quando:

  • Output ha alto valore unitario (>€10/task).
  • Quality requirement molto sopra single-agent baseline.
  • Workflow è ripetuto N volte (ammortizza dev cost).

ROI negativo quando:

  • Output volume-based, basso valore.
  • Single-agent + retry-on-fail risolve.
  • Use case sperimentale (cambia ogni mese).

Glossario lampo

  • Supervisor pattern — un agente coordina N sub-agent specializzati, aggrega risultati.
  • Swarm / network — agenti peer-to-peer senza supervisor esplicito; più flessibile ma più caotico.
  • Mixture of Agents (MoA) — pattern in cui N agenti producono in parallelo e un aggregator sintetizza.
  • Actor-Critic — pattern a 2 agenti: uno esegue, l’altro valuta. Classico in RL, importato in LLM agentici.
  • Handoff — pattern in cui un agente trasferisce esplicitamente controllo a un altro (OpenAI Agents SDK, Anthropic).

Take-away

Multi-agent ha senso quando il task si decompone naturalmente, la specializzazione paga, o serve un verification step. Negli altri casi è overhead camuffato da architettura sofisticata. Inizia sempre con un single agent ben fatto. Se vai multi-agent, parti con 2 (actor + critic) e cresci solo se misuri un vero quality boost. Più agenti ≠ più qualità — più spesso ≠ più caos.

➡️ Prossima puntata: browser e desktop agents — Operator, Computer Use, ChatGPT Atlas.