Se hai valutato Microsoft AutoGen negli ultimi due anni e poi hai perso di vista il progetto, potresti esserti perso una frattura significativa. Il repository originale di AutoGen si è diviso in fork — e due progetti distinti si contendono oggi lo stesso nome. Per qualsiasi team che debba decidere dove costruire un sistema multi-agente, quella scissione non è una nota a margine: cambia concretamente su quale codebase ti stai impegnando.
Questo articolo fa chiarezza. Spieghiamo cosa è successo, cosa fa bene ciascun ramo e diamo un verdetto diretto su se AutoGen o il suo fork AG2 appartengano a una build in produzione oggi — in particolare all’interno di un’infrastruttura IT fortemente orientata ad Azure o Microsoft.
Cosa è successo davvero: AutoGen, AG2 e il Microsoft Agent Framework
AutoGen è nato come progetto di Microsoft Research. L’idea centrale — far conversare tra loro più agenti basati su LLM per risolvere problemi in modo collaborativo — era genuinamente innovativa al lancio, e la comunità di ricerca l’ha abbracciata rapidamente.
Il fork è avvenuto perché le ambizioni di Microsoft per il progetto hanno superato le origini da laboratorio di ricerca. A fine 2024, una parte significativa dei contributori originali di AutoGen ha lasciato il progetto e lo ha rilanciato con il nome AG2 (distribuito anche con il nome del pacchetto ag2 e il dominio community ag2ai). L’obiettivo dichiarato: mantenere una struttura di governance aperta e guidata dalla community, indipendente da qualsiasi roadmap aziendale.
Nel frattempo, Microsoft ha ricostruito ciò che rimaneva della linea originale di AutoGen. Il risultato immediato è stato AutoGen 0.4 — una riscrittura completa con internals asincroni ed event-driven, rilasciata a gennaio 2025. Ma la storia non finisce qui: nell’ottobre 2025 Microsoft ha portato AutoGen 0.4 in modalità manutenzione (solo bug fix e patch di sicurezza, nessuna nuova funzionalità) e ha lanciato il Microsoft Agent Framework come successore ufficiale, unendo AutoGen e Semantic Kernel in un unico SDK. L’Agent Framework ha raggiunto la v1.0 nell’aprile 2026 ed è ora il percorso attivo supportato da Microsoft. AutoGen 0.4+ è quindi un framework deprecato e con funzionalità congelate al momento della stesura di questo articolo. Sul lato gestito, questi concetti confluiscono in Azure AI Agent Service e nel più ampio stack di Azure AI Foundry.
Quindi quando qualcuno dice “sto usando AutoGen”, potrebbe intendere:
- AG2 (il fork community): Il framework Python più attivamente mantenuto, più vicino per spirito al modello originale di conversazione multi-agente. Si trova su
github.com/ag2ai/ag2. - Microsoft AutoGen 0.4: Internals riscritti, integrazione Azure più stretta, superficie API divergente. Ora in modalità manutenzione — nessuna nuova funzionalità. Si trova su
github.com/microsoft/autogen. - Microsoft Agent Framework (v1.0, aprile 2026): Il successore attivo di Microsoft, che unisce AutoGen e Semantic Kernel. Python e .NET (C#) supportati come linguaggi di prima classe equivalenti. Il target di build da usare se sei impegnato nell’ecosistema Microsoft.
- Azure AI Foundry Agent Service: La direzione hosted/managed di Microsoft, alimentata dall’Agent Framework, che è una categoria di prodotto completamente diversa.
Per la maggior parte dei decision-maker che valutano questo per una build in produzione, la domanda pratica è: AG2 o la linea AutoGen mantenuta da Microsoft? Non sono più la stessa cosa.
Dove la conversazione multi-agente eccelle — e dove AutoGen/AG2 ha aperto la strada
L’intuizione originale dietro AutoGen era importante: molti task di AI non banali sono meglio gestiti da una conversazione strutturata tra agenti specializzati piuttosto che da un unico generalista sovraccarico. Un agente planner scompone un obiettivo, un agente coder scrive lo script, un agente reviewer lo controlla, un agente executor lo esegue e riporta i risultati. Ogni agente ha un ruolo definito, e il protocollo di conversazione li coordina.
Questo modello si adatta bene a:
- Workflow di ricerca e analisi — sintesi di più fonti, verifica incrociata dei risultati, iterazione sulle bozze
- Assistenza allo sviluppo software — task di coding multi-step con cicli di revisione e test
- Q&A interne con accesso agli strumenti — agenti che possono interrogare database, chiamare API, poi ragionare sui risultati prima di rispondere
L’architettura conversazionale a message-passing significa che ottieni catene di ragionamento osservabili e debuggabili. Puoi vedere cosa ha detto ogni agente agli altri e perché è stata presa una decisione. Per i settori regolamentati o le operazioni attente al rischio, quella tracciabilità conta. Vedi il nostro articolo sui sistemi multi-agente per uno sguardo più ampio su quando questa architettura ha senso.
AG2 vs Microsoft AutoGen: su quale ramo costruire oggi
Ecco un confronto diretto sulle dimensioni che contano per una build aziendale:
| Dimensione | AG2 (fork community) | Microsoft Agent Framework |
|---|---|---|
| Stabilità delle API | Più stabile; più vicina all’API originale | v1.0 da aprile 2026; 0.4 aveva breaking change |
| Attività della community | Alta; i maintainer core originali | Supportato da Microsoft; la community AutoGen 0.4 migra all’Agent Framework |
| Integrazione Azure | Manuale; porta i tuoi connettori | Supporto di prima classe per Azure OpenAI e AI Foundry |
| Strumenti per la produzione | In miglioramento ma ancora limitati | Ottimizzato per lo stack Microsoft |
| Supporto linguaggi | Solo Python | Python e .NET (C#) come linguaggi di prima classe equivalenti |
| Supporto LLM non-Azure | Buono | Possibile ma chiaramente non primario |
| Opzione hosted/managed | Nessuna | Azure AI Foundry Agent Service |
Il verdetto: se stai costruendo su Azure e la tua infrastruttura IT è centrata su Microsoft, il Microsoft Agent Framework — o Azure AI Foundry Agent Service — è il percorso pragmatico. Integrazione più stretta, un vero modello di supporto e un SDK in sviluppo attivo. Nota che AutoGen 0.4 è entrato in modalità manutenzione; se stai avviando una nuova build, punta direttamente all’Agent Framework.
Se vuoi un framework Python neutro per workflow multi-agente e non sei vincolato ad Azure, AG2 è il progetto più attivo e ha preservato meglio l’intento di design originale.
AutoGen / AG2 è davvero pronto per la produzione?
È qui che una valutazione onesta richiede di separare “puoi costruire qualcosa che funziona” da “è temprato per le operazioni aziendali.”
Dove entrambi i rami faticano al confine della produzione:
- Affidabilità su catene di conversazione lunghe. Le conversazioni multi-agente possono andare alla deriva, ciclare o produrre output incoerenti man mano che le finestre di contesto si riempiono. I guardrail richiedono un lavoro di ingegneria esplicito — non vengono fuori dalla scatola.
- Osservabilità. Tracciare cosa è successo su cinque agenti durante un run fallito è più difficile di quanto dovrebbe essere. AutoGen 0.4 ha introdotto il tracciamento basato su OpenTelemetry come funzionalità di prima classe, un miglioramento reale rispetto alla v0.2. In pratica, la documentazione sull’instrumentazione copre solo la Core API di livello inferiore; le astrazioni a livello AgentChat mancano di documentazione dedicata al tracciamento, e le configurazioni multi-componente possono generare conflitti tra provider. Per una build in produzione, aspettati di investire nella configurazione dell’osservabilità oltre quanto documentato.
- Recovery dagli errori. Quando un passaggio di un agente fallisce a metà workflow — un timeout API, una risposta errata di uno strumento — nessuno dei due rami ha una logica di retry e compensazione robusta integrata. La costruisci tu.
- Pattern di deployment. AutoGen e AG2 sono framework, non piattaforme. Non c’è uno scheduler integrato, nessuna coda gestita, nessun deployment target. Porti la tua infrastruttura.
Confronta questo con il test di production-readiness che applichiamo a tutti i framework per agenti: osservabilità, recovery dagli errori, gestione dello stato, deployment e controlli di sicurezza. Su quella rubrica, entrambi i rami di AutoGen ottengono buoni risultati sul livello di ragionamento e conversazione, e scarsi risultati sul livello operativo.
Non è una squalifica. Significa che costruisci il scaffolding operativo sopra — o usi un framework più opinionato che lo include.
Chi dovrebbe davvero considerare AutoGen o AG2
Adatto a:
- Team già investiti nell’ecosistema Microsoft/Azure, dove Azure AI Foundry Agent Service — costruito sul Microsoft Agent Framework — aggiunge infrastruttura gestita attorno ai workflow multi-agente
- Applicazioni vicine alla ricerca — sintesi di conoscenza interna, task di analisi di lungo periodo, revisione di documenti complessi — dove il modello di agente conversazionale si adatta naturalmente al workflow
- Team di sviluppo Python-native che vogliono un controllo granulare sul design della conversazione degli agenti e sono a proprio agio nel costruire il proprio livello di deployment
- Organizzazioni che pilotano il ragionamento multi-agente prima di impegnarsi in un framework di orchestrazione più pesante come LangGraph
Non adatto a:
- Team che hanno bisogno di una piattaforma di agenti production-ready con scheduling, osservabilità e deployment integrati senza un significativo lavoro di infrastruttura custom
- Progetti che richiedono integrazione TypeScript o JavaScript — AG2 è solo Python, e il Microsoft Agent Framework supporta Python e .NET (C#) ma non TypeScript o JavaScript direttamente
- Automazione di task semplici che non necessita di ragionamento multi-agente — il sovraccarico non ne vale la pena
- Organizzazioni senza footprint Azure che vogliono hosting gestito — non esiste un’opzione gestita neutrale per AG2
Per un confronto più ampio tra i framework Python, la nostra shortlist di framework open-source per agenti copre come AutoGen/AG2 si posiziona accanto a LangGraph, CrewAI e altri. Se stai valutando specificamente le opzioni multi-agente basate su Python, CrewAI vs LangGraph è una lettura complementare utile.
Il caso specifico Azure: quando lo stack Microsoft colma il divario
Uno scenario in cui il Microsoft Agent Framework diventa genuinamente convincente: la tua organizzazione usa già Azure OpenAI Service, Azure AI Foundry, e ha deployment di Microsoft 365 Copilot in corso. In quel contesto, Azure AI Foundry Agent Service — costruito sul Microsoft Agent Framework — ti offre:
- Esecuzione degli agenti gestita con il profilo di conformità e sicurezza di Azure
- Connettività nativa ai modelli Azure OpenAI senza configurazione aggiuntiva
- Integrazione con la gestione di identità e accessi Microsoft
- Un percorso verso Copilot Studio per gli utenti meno tecnici per interagire con la stessa infrastruttura di agenti
Per una PMI svizzera o europea con requisiti stringenti di residenza dei dati e un accordo Microsoft EA esistente, questo non è un vantaggio trascurabile. I data center europei di Azure e le certificazioni di conformità contano, e il costo di integrazione che altrimenti spenderesti su un framework neutro viene parzialmente compensato dal supporto Azure di prima classe.
La cautela: sei ora su una roadmap di prodotto Microsoft, e il tasso di cambiamento in questo stack è stato elevato — tre principali transizioni di framework in meno di tre anni. Quello che si trova sotto Azure AI Foundry Agent Service oggi potrebbe apparire sostanzialmente diverso tra dodici mesi. Costruisci sulle interfacce, non sugli internals del framework.
La domanda chiave da porsi prima di scegliere un framework
La selezione del framework raramente merita il peso strategico che gli ingegneri le attribuiscono. Le domande più importanti sono:
- Cosa deve fare concretamente l’agente, e il modello di conversazione multi-agente si adatta a quel task?
- Quale infrastruttura abbiamo già, e quali lacune operative crea il framework?
- Quanta parte della nostra capacità ingegneristica va nel plumbing del framework rispetto al problema reale che stiamo risolvendo?
AutoGen e AG2 rispondono bene alla domanda uno per i task di ragionamento collaborativo. Lasciano le domande due e tre in gran parte a te.
Quell’overhead ingegneristico è reale. In Orange ITS, la scelta del framework segue il caso d’uso e i requisiti operativi — non il contrario. Una società di servizi professionali da 50 persone non ha lo stesso calcolo di una fintech con un team MLOps dedicato.
Parla del tuo progetto agente prima di impegnarti in un framework
Scegliere tra AG2, la linea Microsoft AutoGen, LangGraph o lo sviluppo custom dipende dal tuo stack, dalla capacità del tuo team e da quanta infrastruttura operativa vuoi gestire internamente.
Se sei nella fase di valutazione, una chiamata di 30 minuti con il team di Orange ITS può farti risparmiare settimane di sperimentazione con i framework. Analizzeremo il tuo caso d’uso, la tua infrastruttura esistente, e ti daremo una visione diretta di quale approccio ha più probabilità di arrivare in produzione e quale rischia di bloccarsi.