Gli agenti LLM sono solo sistemi distribuiti

La comunità AI sta costruendo sistemi multi-agente: team di LLM che si dividono il lavoro, comunicano e collaborano per risolvere problemi che nessun singolo modello riesce a gestire. Un agente 'ricercatore' raccoglie informazioni, un agente 'programmatore' scrive l'implementazione, un agente 'revisore' controlla la qualità, un agente 'coordinatore' gestisce il flusso di lavoro. La promessa è allettante: agenti specializzati che collaborano come un team di ingegneri ben organizzato.

Se suona familiare, non è un caso. I ricercatori di sistemi distribuiti studiano il coordinamento di processi indipendenti da 40 anni. I sistemi multi-agente basati su LLM stanno riscoprendo, partendo da zero, problemi che la comunità dei sistemi distribuiti ha risolto (o dimostrato irrisolvibili) decenni fa. Capire questi parallelismi ti fa risparmiare la fatica di reinventare soluzioni e ti aiuta a evitare sistemi che falliscono in modi prevedibili e ben noti.

La tassa del coordinamento

La prima lezione dei sistemi distribuiti: il coordinamento ha un costo. Due processi che lavorano in modo indipendente su compiti separati sono il doppio più veloci di uno solo. Due processi che lavorano sullo stesso compito e devono coordinarsi sono spesso più lenti di uno solo, perché l'overhead di comunicazione e sincronizzazione supera il vantaggio del parallelismo.

I sistemi multi-agente basati su LLM ci sbattono subito il naso. Un agente 'ricercatore' produce un report. L'agente 'programmatore' ha bisogno di capire il report per scrivere codice. L'agente 'revisore' deve capire sia il report sia il codice per dare un feedback utile. Ogni passaggio di consegne richiede di serializzare il contesto in un prompt, che l'agente ricevente deve analizzare e comprendere. È esattamente il problema dello stato condiviso dei sistemi distribuiti, e peggiora man mano che aggiungi agenti.

Single agent vs. multi-agent for a coding task:
Single agent:
1. Understand the problem         (1 LLM call)
2. Research relevant APIs          (2 LLM calls)
3. Write implementation            (1 LLM call)
4. Review and fix                  (1 LLM call)
Total: 5 LLM calls, full context throughout
Multi-agent (researcher + coder + reviewer):
1. Coordinator describes task      (1 LLM call)
2. Researcher reads and plans      (1 LLM call)
3. Researcher does research        (3 LLM calls)
4. Researcher summarizes findings  (1 LLM call)
5. Coder reads summary             (1 LLM call)  ← context lost here
6. Coder writes implementation     (1 LLM call)
7. Reviewer reads code + summary   (1 LLM call)  ← context lost here
8. Reviewer provides feedback      (1 LLM call)
9. Coordinator synthesizes         (1 LLM call)
Total: 11 LLM calls, context degraded at each handoff
More agents = more communication = more cost = worse context.

Nei sistemi distribuiti, questo è la Legge di Amdahl applicata alla comunicazione: l'accelerazione dovuta al parallelismo è limitata dalla comunicazione sequenziale che non può essere parallelizzata. Aggiungere agenti a un compito che richiede un coordinamento stretto rende il sistema più lento, non più veloce.

Il problema del consenso

Quando più agenti lavorano sullo stesso compito, devono mettersi d'accordo su alcune cose. Quali sono i requisiti? Quale approccio adottare? Questa implementazione è corretta? Nei sistemi distribuiti questo è il problema del consenso, ed è dimostrabilmente difficile: il risultato di impossibilità FLP mostra che il consenso deterministico è impossibile in un sistema asincrono anche con un solo processo guasto.

Gli agenti LLM sono peggiori dei processi distribuiti tradizionali sul consenso, perché non sono deterministici. Fai la stessa domanda allo stesso agente due volte e potresti ottenere due risposte diverse. Due agenti che revisionano lo stesso codice potrebbero non essere d'accordo sulla sua correttezza. Un agente 'coordinatore' chiamato a risolvere il disaccordo potrebbe finire per lanciare una moneta.

I framework multi-agente di solito gestiscono il problema in due modi: designando un agente coordinatore con l'autorità finale (un modello di consenso centralizzato, semplice ma con un single point of failure) oppure con il voto a maggioranza (costoso, perché servono almeno tre agenti per ogni decisione). Entrambi gli approcci funzionano, ma risolvono un problema che esiste solo perché hai suddiviso il lavoro tra più agenti.

Modalità di guasto che dovrebbero sembrarti familiari

I sistemi multi-agente falliscono in modi che gli ingegneri dei sistemi distribuiti riconosceranno subito.

• Guasti a cascata. L'agente A produce un output sbagliato. L'agente B, partendo dall'output di A, produce un risultato ancora peggiore. L'agente C, che revisiona il lavoro di B, non individua l'errore originale perché ha ereditato le ipotesi sbagliate. È l'equivalente, nei sistemi distribuiti, della propagazione degli errori: spazzatura in ingresso, spazzatura in uscita, amplificata a ogni stadio.
• Deadlock. L'agente A aspetta l'output dell'agente B per procedere. L'agente B aspetta il feedback dell'agente A per procedere. Nessuno dei due può avanzare. In pratica si manifesta come cicli infiniti in cui gli agenti si rimbalzano il lavoro senza mai convergere.
• Split brain. Due agenti che lavorano su compiti correlati sviluppano visioni incoerenti del problema. Uno presuppone che l'API restituisca JSON, l'altro presuppone XML. I loro output sono singolarmente corretti ma reciprocamente incompatibili.
• Thundering herd. Un agente coordinatore distribuisce il lavoro a più agenti contemporaneamente. Tutti colpiscono la stessa API, esauriscono lo stesso rate limit o tentano di modificare lo stesso file. Una contesa di risorse che un singolo agente non incontrerebbe mai.

Quando il multi-agente aiuta davvero

Il parallelo con i sistemi distribuiti funziona in entrambe le direzioni. I sistemi distribuiti offrono vantaggi reali per problemi specifici, e lo stesso vale per i sistemi multi-agente, quando vengono usati per problemi che beneficiano davvero della scomposizione.

Compiti imbarazzantemente paralleli. Se devi analizzare 50 codebase alla ricerca dello stesso pattern, 50 agenti che lavorano in modo indipendente sono davvero 50 volte più veloci. Non serve coordinamento: ogni agente lavora su un input separato e produce un output indipendente. È il pattern MapReduce, e funziona con gli agenti LLM tanto bene quanto nell'elaborazione distribuita dei dati.

Prospettive diverse. Chiedere a tre agenti con system prompt differenti di revisionare lo stesso codice può far emergere problemi che una singola revisione non vede. È il pattern della ridondanza, come avere più reviewer su una PR. Il costo è tre volte il calcolo, ma la copertura è più ampia.

Specializzazione con interfacce pulite. Un agente di traduzione che riceve testo e restituisce testo tradotto ha un'interfaccia pulita. Anche un agente di riassunto che riceve un documento e restituisce un riassunto ha un'interfaccia pulita. Componendoli (traduci, poi riassumi) il risultato è buono perché l'interfaccia tra i due è semplice. L'equivalente nei sistemi distribuiti: i microservizi con API ben definite funzionano meglio di microservizi con interfacce complesse e molto verbose.

Lezioni dai sistemi distribuiti

Se stai costruendo sistemi multi-agente basati su LLM, decenni di sapere sui sistemi distribuiti si applicano direttamente.

1. Preferisci pochi agenti più capaci a molti agenti specializzati. Così come un monolite ben progettato supera un'architettura a microservizi mal progettata, un singolo agente capace con un buon prompting supera un team di agenti ristretti nella maggior parte dei casi. Aggiungi agenti solo quando hai dimostrato che un singolo agente non riesce a gestire il carico di lavoro.
2. Definisci interfacce chiare tra gli agenti. Input e output di ogni agente devono essere ben definiti. Passaggi di consegne vaghi ('capisci cosa ha trovato il ricercatore e implementalo') portano a perdita di contesto e fraintendimenti. Contratti di dati strutturati tra agenti funzionano meglio del testo libero.
3. Rendi gli agenti idempotenti. Se un agente fallisce a metà, dovresti poterlo riavviare con lo stesso input e ottenere un risultato corretto. Questo richiede agenti senza stato nascosto e senza effetti collaterali finché non hanno verificato che il proprio output è corretto.
4. Aggiungi osservabilità. Registra ogni messaggio tra agenti, ogni decisione, ogni errore. Quando un sistema multi-agente produce un output sbagliato, devi poter risalire all'agente che ha preso la decisione sbagliata e capire perché. Senza osservabilità, il debugging è un'ipotesi alla cieca.
5. Progetta per i guasti parziali. Qualsiasi agente può fallire, produrre spazzatura o andare in timeout. Il sistema deve gestirlo con eleganza: riprovare, ripiegare su un approccio più semplice o chiedere a un essere umano. Non dare mai per scontato che tutti gli agenti riusciranno.

La verità scomoda

La maggior parte dei sistemi multi-agente basati su LLM funzionerebbe meglio come un singolo agente con un buon prompt. L'overhead di coordinamento, la perdita di contesto e le modalità di guasto delle architetture multi-agente superano quasi sempre i benefici, per i compiti che un singolo modello sa gestire. Man mano che gli strumenti AI evolvono, cresce la tentazione di costruire elaborati sistemi multi-agente, ma la lezione dei sistemi distribuiti è chiara: non distribuire ciò che non ha bisogno di essere distribuito.

Le eccezioni sono reali: compiti imbarazzantemente paralleli, specializzazione genuina con interfacce pulite e problemi che superano la finestra di contesto di un singolo modello. Per tutto il resto, un singolo agente con un prompt ben strutturato, buoni strumenti e una strategia di retry ponderata batterà un team di agenti. È meno entusiasmante dal punto di vista architetturale, ma funziona meglio. Il miglior sistema distribuito è quello che non hai dovuto costruire.