Agent Discussion Arena: analisi multi-prospettiva con agenti AI

Chi lavora con problemi complessi sa che la prima cosa da fare è guardarli da più angolazioni. Un contratto lo leggono sia l’avvocato che lo ha scritto sia quello che deve trovarne i difetti. Una strategia aziendale la valutano il CFO, il responsabile HR e chi gestisce le operazioni. Un caso clinico lo discutono lo specialista e il generalista. Il valore non sta nella singola competenza, sta nel confronto tra prospettive diverse.

Nella realtà, mettere insieme quel tipo di team richiede tempo, coordinamento e risorse che spesso non ci sono, soprattutto quando servirebbero per una valutazione rapida, non per un progetto strutturato. L’alternativa più accessibile oggi è chiedere a un modello AI di “considerare tutti i punti di vista”, ma il risultato è un po’ come chiedere a una persona di fare l’avvocato del diavolo contro sé stessa: può provarci, e a volte è decoroso, ma la tensione dialettica resta simulata.

Una soluzione è l’uso di un sistema di agenti AI, in cui ogni partecipante è un’entità a sé stante con un proprio mandato. Metterli a confronto garantisce un dialogo reale, non simulato.

Esistono già proposte come CrewAI, AutoGen o LangGraph che permettono di orchestrare più agenti AI con ruoli diversi, e i risultati sono interessanti. Il problema è che sono strumenti per sviluppatori, si installano da terminale, si configurano scrivendo codice Python, richiedono familiarità con API e ambienti di sviluppo. Per un professionista che vuole analizzare un contratto da più prospettive o simulare una discussione strategica, non sono una soluzione praticabile.

Agent Discussion Arena nasce per colmare questo spazio. È uno strumento che fa la stessa cosa, mettere più agenti AI a discutere da prospettive definite con un moderatore che tira le conclusioni, ma si usa aprendo un browser e compilando un form. È open source, gira interamente in locale e funziona con qualsiasi provider AI, dai modelli cloud ai modelli che girano sulla propria macchina. Servono solo un file HTML, un piccolo server proxy in Python e un browser. Il progetto è su GitHub.

In questo articolo racconto cos’è, a cosa serve e come è nato. La storia della sua creazione è parte integrante del progetto, perché Agent Discussion Arena è stato costruito interamente attraverso il vibe coding, una conversazione continua tra me e Claude in cui ogni decisione architetturale, ogni scelta di design e ogni riga di codice sono state discusse e prodotte in linguaggio naturale.
In un articolo successivo ho raccolto 5 casi d’uso, questo articolo.

Cosa fa Agent Discussion Arena

Il funzionamento è lineare. Si apre il browser, si configura il provider AI (cloud o locale, selezionando anche il modello da usare), si definisce un tema di discussione e si creano i partecipanti, ognuno con un nome e una prospettiva. Si può anche caricare un documento (un PDF, un’immagine, un file di testo) che tutti i partecipanti useranno come base per le proprie argomentazioni. Poi si aggiunge un moderatore, si sceglie il numero di round e si avvia la discussione.

All’inizio il moderatore propone il tema ed i partecipanti presentano le loro posizioni, da quel momento gli agenti discutono tra loro in modo sequenziale. Ad ogni round successivo ciascun partecipante ha accesso a tutto ciò che è stato detto prima, e può rispondere, contestare o approfondire. Non è un semplice elenco di opinioni giustapposte, è una conversazione in cui ogni intervento tiene conto dei precedenti.

Al termine dei round il moderatore, dopo avere letto tutti gli interventi e avere valutato la qualità degli argomenti, produce un verdetto che sintetizza i punti di forza e di debolezza di ciascuna posizione. Naturalmente la qualità della discussione dipende dal modello AI scelto.

L’interfaccia di configurazione è divisa in due sezioni. Nella prima si sceglie il provider AI e il modello da utilizzare. Nella seconda si definisce il tema della discussione, con un eventuale documento di riferimento, si selezionano i partecipanti (da due a quattro, attribuendogli una personalità), il moderatore e il numero di round (da uno a cinque, con due o tre come punto di equilibrio tra profondità e costi).

Una volta completata la discussione si può scaricare l’intero dibattito come file Markdown, con tutti gli interventi dei partecipanti e del moderatore, con le statistiche di utilizzo (token consumati, tempo, provider e modello usato). Oppure si può lanciare una nuova discussione con la configurazione preservata, modificando solo ciò che serve.

Sul piano tecnico la struttura è volutamente minimale. L’intera interfaccia è contenuta in un singolo file HTML con React e Babel. Il server proxy è uno script Python che usa solo la libreria standard, senza dipendenze esterne da installare. Il proxy ha un unico compito, inoltrare le chiamate API al provider scelto, e si lega esclusivamente a localhost. L’installazione si riduce a tre passaggi: copiare i file sul proprio computer, avviare il proxy con un comando nel terminale, aprire il browser su https://localhost:8080.
Tutti i passaggi sono documentati nelle istruzioni.

A cosa serve davvero: la discussione multi-prospettiva

La domanda più naturale davanti a uno strumento come questo perché non basta chiedere a un singolo modello di analizzare il problema da più punti di vista? La risposta sta in come funzionano i modelli linguistici quando ricevono un compito del genere.

Quando si chiede a un LLM di “considerare le prospettive di un avvocato, un commercialista e un imprenditore“, il modello produce un testo che simula la molteplicità ma resta il prodotto di un unico processo generativo. Per questo, quando genera una posizione su un argomento, in un certo senso sa già come risponderanno le altre “personalità” coinvolte.

In Agent Discussion Arena la dinamica è diversa, ogni partecipante è a sé stante, riceve un prompt di sistema che definisce la sua identità, la sua competenza e il suo punto di vista. Il suo compito non è essere equilibrato, ma è argomentare dalla propria prospettiva nel modo più solido possibile. Quando il partecipante successivo legge quegli argomenti, il suo compito è rispondere, contestare, integrare con il proprio punto di vista. La pressione dialettica non è simulata, è strutturale, perché ogni agente ha un mandato diverso.

Il risultato è una discussione in cui le posizioni si confrontano davvero, i punti di frizione sono più visibili, le debolezze argomentative vengono esposte dall’interlocutore, le assunzioni implicite vengono messe in discussione.

I casi d’uso coprono un arco molto ampio. In ambito legale si può far analizzare un contratto o un provvedimento normativo da prospettive opposte, con un giurista che ne difende la solidità e un altro che ne cerca le vulnerabilità. Nella pianificazione strategica si possono simulare le posizioni del responsabile finanziario, di chi gestisce le persone e di chi si occupa delle operazioni davanti alla stessa decisione. Nell’analisi medica (con modelli locali, dove nessun dato esce dalla macchina) si possono mettere a confronto specialisti di discipline diverse sullo stesso caso clinico.

Ma ci sono anche applicazioni meno ovvie. Un docente può far discutere diverse scuole di pensiero su un tema filosofico o storico per preparare materiale didattico. Chi scrive può sottoporre un testo a un panel di “critici” con sensibilità diverse. Un team di marketing può simulare le reazioni di segmenti di pubblico diversi a una campagna, prima di investire risorse reali nel test.

Due esempi concreti

Per rendere tangibile il tipo di risultato che produce Agent Discussion Arena, ho reso scaricabili due discussioni complete.

Analisi del DDL italiano sull’intelligenza artificiale Un dirigente aziendale e un avvocato specializzato in proprietà intellettuale discutono il DDL 132/2025, la legge italiana sull’uso delle AI generative. Non c’è documento di riferimento allegato, i partecipanti ragionano sulla base delle proprie conoscenze. Il moderatore orienta il dibattito sulle implicazioni pratiche per le aziende. Nel corso di tre round la discussione entra nel dettaglio della responsabilità lungo la filiera, dell’effettività territoriale delle norme e del dovere di diligenza dell’utilizzatore, con l’avvocato che contesta punto per punto le soluzioni proposte dal dirigente. Modello cloud: Claude Opus 4.6 di Anthropic.

Scarica la discussione completa (PDF)

Intelligenze multiple e valutazione scolastica Un insegnante tradizionale e uno sperimentatore discutono un meme famoso (l’immagine degli animali a cui si chiede di scalare un albero come prova d’esame), con un preside come moderatore che deve decidere come affrontare le nuove metodologie didattiche e il riconoscimento delle neurodivergenze. Nel corso di quattro round il dibattito parte dalla valutazione standardizzata e arriva a una proposta articolata di triangolazione valutativa, con le posizioni di entrambi che si evolvono visibilmente ad ogni scambio. Modello locale: gemma3:27b.

Scarica la discussione completa (PDF)

La prima discussione è stata generata con un modello cloud (Anthropic), la seconda interamente in locale con un modello open source, senza che nessun dato uscisse dalla macchina. I PDF contengono l’intero dibattito così come è stato prodotto, senza editing.

Il punto comune è che la struttura della discussione multi-agente forza un’esplorazione più ampia dello spazio argomentativo. Non perché i singoli interventi siano necessariamente migliori di quelli che produrrebbe un modello solo, ma perché il formato stesso impedisce la convergenza prematura verso una posizione “ragionevolmente equilibrata” che in realtà non ha mai affrontato le obiezioni più scomode.

Altri 5 esempi si possono trovare in questo articolo.

Scegli tu con chi parlare: l’approccio multi-provider

Agent Discussion Arena non è legato a nessun provider specifico. Si può usare Claude di Anthropic, GPT-4o di OpenAI, Gemini di Google, DeepSeek, un altro server compatibile con le API OpenAI, oppure qualsiasi modello locale che gira sulla propria macchina attraverso Ollama o LM Studio. La configurazione si fa dall’interfaccia, senza modificare file o scrivere codice.

Questa scelta è una decisione di design che riflette un principio preciso, lo strumento è al servizio dell’utente, non del fornitore. Chi usa Agent Discussion Arena sceglie il modello in base alle proprie esigenze, al proprio budget e al livello di privacy richiesto. Un’analisi strategica che non contiene dati sensibili può utilizzare un modello di Anthropic o di OpenAI senza problemi. Una discussione su un caso medico con dati reali del paziente richiede un modello locale dove nulla esce dalla macchina.

La possibilità di cambiare provider apre anche una prospettiva interessante per chi vuole capire come ragionano modelli diversi. Si può lanciare la stessa discussione, con gli stessi partecipanti e lo stesso tema, su due modelli differenti e confrontare come si sviluppano le argomentazioni. Non è un benchmark quantitativo, è qualcosa di più utile nella pratica per vedere come un modello gestisce il conflitto tra posizioni, quanto è disposto a concedere all’avversario, dove tende a convergere e dove invece mantiene la tensione. Per chi lavora con le AI e deve scegliere quale modello usare nei propri flussi di lavoro, è un modo concreto di valutare le differenze.

Inoltre uno strumento che funziona solo con un provider è uno strumento che smette di funzionare quando quel provider cambia le condizioni, alza i prezzi o modifica il comportamento del modello. Uno strumento che si appoggia a un’interfaccia standard (in questo caso le API compatibili OpenAI, che sono diventate lo standard di fatto del settore) resta utilizzabile indipendentemente da chi fornisce il modello.

Privacy-first, tutto su localhost

La scelta di far girare tutto in locale non è una preferenza estetica, è una risposta a un problema concreto. Molti dei casi d’uso più interessanti per una discussione multi-prospettiva riguardano materiale che non si può caricare su un servizio esterno, come documenti legali riservati, dati clinici, informazioni finanziarie, valutazioni del personale, strategie aziendali non ancora pubbliche.

L’architettura di Agent Discussion Arena è costruita intorno a questo vincolo. Il server proxy accetta connessioni solo da localhost, cioè dalla macchina su cui sta girando, e rifiuta qualsiasi accesso dall’esterno. Le API key vivono solo nella memoria temporanea della pagina, non vengono mai salvate su disco né registrate nei log. Quando si chiude il browser, scompaiono. Non c’è telemetria, non ci sono analytics, non ci sono chiamate esterne se non quelle verso il provider AI scelto dall’utente. Quando si usa un modello locale tramite Ollama o LM Studio, il cerchio si chiude completamente: nessun dato esce dalla macchina, in nessun momento.

Per un avvocato che vuole far analizzare un contratto riservato da prospettive opposte, questa garanzia non è un optional. Per un medico che vuole confrontare interpretazioni diverse di un caso clinico con dati reali del paziente, è un prerequisito. Per un’azienda che vuole simulare una discussione strategica su un’acquisizione prima che diventi pubblica, è una condizione necessaria.

Il codice è open source e l’intera applicazione consiste in circa 350 righe di Python per il proxy e un singolo file HTML per l’interfaccia. Non si tratta di fidarsi di una dichiarazione sulla privacy policy di un servizio: si tratta di poter leggere il codice, verificare che faccia quello che dichiara e decidere autonomamente. Per chi ha le competenze tecniche la verifica richiede pochi minuti. Per chi non le ha, la semplicità dell’architettura (due file, nessuna dipendenza, nessun servizio in background) è di per sé una forma di trasparenza, perché riduce drasticamente la superficie in cui qualcosa potrebbe sfuggire al controllo.

Come è nato: il vibe coding con Claude

Agent Discussion Arena è stato costruito interamente attraverso il vibe coding, un approccio allo sviluppo software in cui il codice viene prodotto dall’AI e diretto dall’umano attraverso il linguaggio naturale. Nessuna riga di codice è stata scritta manualmente. Ogni funzionalità è stata discussa, specificata, implementata e rifinita in una conversazione continua con Claude.

Nel caso di Agent Discussion Arena il lavoro si è diviso in due fasi con due modalità diverse di Claude Desktop. La prima fase, quella di specifica e design, è avvenuta in Chat con Opus 4.6: definizione dell’architettura, scelte di design dell’interfaccia, decisioni su cosa includere e cosa no, struttura del flusso di discussione tra agenti. La seconda fase, l’implementazione, è passata a Code, sempre Opus 4.6, che ha tradotto quelle specifiche in codice funzionante, iterando sulla base dei test e delle revisioni. In Code poi, come capita quando si passa dal progetto alla realizzazione, sono state aggiunte o modificate alcune funzionalità.

Il ruolo dell’umano in questo processo non è scrivere codice, ma non è nemmeno premere un bottone e aspettare. È più simile a quello di un regista o di un direttore d’orchestra, definisce la visione, prende le decisioni architetturali, valuta i risultati e corregge la rotta. Quali provider supportare e come, cosa mostra l’interfaccia e in che ordine, come gestire le API key senza scriverle su disco, quanti round permettere, come strutturare il verdetto del moderatore.

Fare scrivere il codice alla macchina non significa che il processo sia semplice o che chiunque possa costruire software complesso senza alcuna conoscenza. Serve capire cosa si sta chiedendo, saper valutare se il risultato ha senso, riconoscere quando il modello sta prendendo una direzione sbagliata. Ma il tipo di competenza richiesta cambia radicalmente: non è più “so scrivere Python”, è “so cosa voglio costruire e so riconoscere se funziona“.
Per un professionista con un’idea chiara e la capacità di dirigere il processo il
vibe coding, termine coniato da Andrej Karpathy, trasforma progetti che avrebbero richiesto settimane di sviluppo (o la ricerca di uno sviluppatore) in qualcosa di realizzabile in una conversazione.

Agent Discussion Arena è la dimostrazione pratica di questo passaggio. Non è un prototipo, non è una demo, è uno strumento funzionante, rilasciato con licenza MIT, che la gente può scaricare e usare. E il fatto che sia stato costruito in questo modo è parte del suo messaggio, perché mostra che il vibe coding può produrre software reale, non solo esercizi di stile.

Dettagli tecnici e limiti

Lo stack tecnologico riflette la stessa filosofia minimalista del progetto. L’interfaccia è un singolo file HTML che include React 18 e Babel, senza passaggi di build né bundler. Il rendering del markdown nelle risposte degli agenti è gestito da marked.js, l’estrazione del testo dai PDF da pdf.js. Il server proxy è uno script Python che usa esclusivamente la libreria standard, il che significa che su qualsiasi macchina con Python 3.10 o superiore funziona senza installare nulla.

La scelta di non introdurre dipendenze esterne non è pigrizia, è una decisione consapevole. Ogni dipendenza è un punto di rottura potenziale: un pacchetto che cambia API, una versione incompatibile, un ambiente che non si riesce a replicare. Eliminandole tutte il progetto diventa riproducibile ovunque, oggi e tra un anno, senza sorprese.

Questa è la versione 1, e ha limiti dichiarati. Si può allegare un solo documento per discussione. Le risposte degli agenti appaiono complete quando sono pronte, senza streaming progressivo. Non c’è un meccanismo di salvataggio e ripresa delle sessioni. L’esportazione è solo in formato Markdown. Con i modelli locali più pesanti (70 miliardi di parametri e oltre) i tempi di risposta possono allungarsi parecchio, anche se il proxy concede fino a venti minuti per ogni chiamata API.

Sono limiti noti e documentati, non bug. Alcuni verranno affrontati nelle versioni successive, altri sono compromessi accettabili per mantenere la semplicità dell’architettura.

Un nuovo modo di costruire

Agent Discussion Arena è disponibile su GitHub con licenza MIT. Si clona il repository, si avvia il proxy, si apre il browser. In pochi minuti si può lanciare la prima discussione.

Ma al di là dello strumento in sé, questo progetto è anche un esempio di qualcosa di più ampio. Fino a poco tempo fa, se un professionista aveva bisogno di un’applicazione specifica per il proprio lavoro, le opzioni erano due: trovarla già fatta più o meno vicina a quello che gli serviva, oppure pagare qualcuno per svilupparla. Il vibe coding apre una terza strada, costruirsi da soli gli strumenti che servono, dirigendo un’AI attraverso il linguaggio naturale. Non serve saper programmare, serve sapere cosa si vuole e saper valutare se il risultato funziona.

Agent Discussion Arena è nato esattamente così, un’esigenza concreta, una conversazione con Claude e uno strumento funzionante alla fine del processo. Se c’è un problema che nessuna app esistente risolve nel modo giusto, forse la prossima app da costruire è quella.

Il repository è qui: github.com/paolodalprato/agent-discussion-arena