Wenn Sie Microsoft AutoGen in den letzten zwei Jahren evaluiert haben und das Projekt danach aus den Augen verloren haben, ist Ihnen möglicherweise ein bedeutender Bruch entgangen. Das ursprüngliche AutoGen-Repository wurde geforkt — und zwei eigenständige Projekte konkurrieren nun um dieselbe Bekanntheit. Für jedes Team, das entscheiden muss, wo es ein Multi-Agenten-System aufbauen will, ist diese Spaltung keine Fussnote. Sie verändert, auf welche Codebasis man sich tatsächlich festlegt.
Dieser Artikel schafft Klarheit. Wir erklären, was passiert ist, was jeder Zweig gut macht, und geben ein klares Urteil darüber ab, ob AutoGen oder sein Fork AG2 heute in einer Produktions-Build — insbesondere in einem Azure-lastigen oder Microsoft-zentrierten IT-Umfeld — seinen Platz hat.
Was wirklich geschah: AutoGen, AG2 und das Microsoft Agent Framework
AutoGen entstand als Microsoft-Research-Projekt. Die Kernidee — mehrere LLM-gestützte Agenten miteinander kommunizieren zu lassen, um Probleme kollaborativ zu lösen — war bei der Veröffentlichung genuell neuartig, und die Forschungsgemeinschaft adaptierte sie schnell.
Der Fork entstand, weil Microsofts Ambitionen für das Projekt über seinen Forschungsursprung hinauswuchsen. Ende 2024 verliess ein erheblicher Teil der ursprünglichen AutoGen-Beitragsleistenden das Projekt und relaunchte es unter dem Namen AG2 (auch als Paketname ag2 und unter der Community-Domain ag2ai verfügbar). Das erklärte Ziel: eine offene, community-gesteuerte Governance-Struktur unabhängig von einer einzelnen Unternehmens-Roadmap zu erhalten.
Parallel dazu baute Microsoft den verbliebenen Teil der ursprünglichen AutoGen-Linie neu auf. Das unmittelbare Ergebnis war AutoGen 0.4 — eine vollständige Neuentwicklung mit asynchronen, event-driven Internals, veröffentlicht im Januar 2025. Damit war die Geschichte aber nicht zu Ende: Im Oktober 2025 überführte Microsoft AutoGen 0.4 in den Wartungsmodus (nur Bugfixes und Sicherheits-Patches, keine neuen Features) und lancierte das Microsoft Agent Framework als offiziellen Nachfolger, der AutoGen und Semantic Kernel in einem einzigen SDK zusammenführt. Das Agent Framework erreichte im April 2026 die v1.0 und ist nun der aktive, von Microsoft unterstützte Pfad. AutoGen 0.4+ ist zum Zeitpunkt dieses Artikels damit ein veraltetes Framework mit eingefrorenen Features. Auf der Managed-Seite fliessen diese Konzepte in den Azure AI Agent Service und den übergeordneten Azure AI Foundry-Stack ein.
Wenn also jemand sagt „Ich nutze AutoGen”, kann das bedeuten:
- AG2 (der Community-Fork): Das aktivere gepflegte Python-Framework, am nächsten am Geiste des ursprünglichen Multi-Agenten-Konversationsmodells. Verfügbar unter
github.com/ag2ai/ag2. - Microsoft AutoGen 0.4: Neu geschriebene Internals, engere Azure-Integration, abweichende API-Oberfläche. Jetzt im Wartungsmodus — keine neuen Features. Verfügbar unter
github.com/microsoft/autogen. - Microsoft Agent Framework (v1.0, April 2026): Microsofts aktiver Nachfolger, der AutoGen und Semantic Kernel zusammenführt. Python und .NET (C#) werden als gleichwertige Erstklasssprachen unterstützt. Das Build-Ziel, wenn Sie sich auf das Microsoft-Ökosystem festlegen.
- Azure AI Foundry Agent Service: Microsofts Hosted/Managed-Richtung, angetrieben durch das Agent Framework — eine völlig andere Produktkategorie.
Für die meisten Entscheidungsträger, die dies für eine Produktions-Build evaluieren, lautet die praktische Frage: AG2 oder die von Microsoft gepflegte AutoGen-Linie? Sie sind nicht mehr dasselbe.
Wo Multi-Agenten-Konversation glänzt — und wo AutoGen/AG2 Pionierarbeit leistete
Die ursprüngliche Erkenntnis hinter AutoGen war bedeutend: Viele nicht-triviale KI-Aufgaben werden besser durch ein strukturiertes Gespräch zwischen spezialisierten Agenten gelöst als durch einen einzigen überlasteten Generalisten. Ein Planner-Agent zerlegt ein Ziel, ein Coder-Agent schreibt das Skript, ein Reviewer-Agent prüft es, ein Executor-Agent führt es aus und berichtet die Ergebnisse. Jeder Agent hat eine definierte Rolle, und das Konversationsprotokoll koordiniert sie.
Dieses Modell passt gut zu:
- Recherche- und Analyse-Workflows — Synthese mehrerer Quellen, Gegenprüfung von Ergebnissen, iteratives Überarbeiten von Entwürfen
- Softwareentwicklungs-Assistenz — mehrstufige Coding-Aufgaben mit Review- und Test-Schleifen
- Internes Q&A mit Tool-Zugriff — Agenten, die Datenbanken abfragen, APIs aufrufen und dann über die Ergebnisse nachdenken, bevor sie antworten
Die konversationale Message-Passing-Architektur liefert Ihnen beobachtbare, debuggbare Reasoning-Chains. Sie können sehen, was jeder Agent den anderen mitgeteilt hat und warum eine Entscheidung getroffen wurde. Für regulierte Branchen oder risikobewusste Betriebe ist diese Nachvollziehbarkeit relevant. Lesen Sie unseren Beitrag über Multi-Agenten-Systeme für einen breiteren Überblick, wann diese Architektur sinnvoll ist.
AG2 vs. Microsoft AutoGen: Auf welchem Zweig heute aufbauen?
Hier ist ein direkter Vergleich entlang der Dimensionen, die für eine geschäftliche Build relevant sind:
| Dimension | AG2 (Community-Fork) | Microsoft Agent Framework |
|---|---|---|
| API-Stabilität | Stabiler; näher an der ursprünglichen API | v1.0 seit April 2026; 0.4 hatte Breaking Changes |
| Community-Aktivität | Hoch; ursprüngliche Core-Maintainer | Microsoft-gestützt; AutoGen-0.4-Community migriert zum Agent Framework |
| Azure-Integration | Manuell; eigene Konnektoren | Erstklassige Unterstützung für Azure OpenAI und AI Foundry |
| Produktions-Tooling | Verbessert sich, aber noch begrenzt | Optimiert für den Microsoft-Stack |
| Sprachunterstützung | Nur Python | Python und .NET (C#) als gleichwertige Erstklasssprachen |
| Nicht-Azure-LLM-Support | Gut | Möglich, aber klar nicht primär |
| Hosted/Managed-Option | Keine | Azure AI Foundry Agent Service |
Das Urteil: Wenn Sie auf Azure aufbauen und Ihr IT-Umfeld Microsoft-zentriert ist, ist das Microsoft Agent Framework — oder Azure AI Foundry Agent Service — der pragmatische Weg. Engere Integration, ein reales Support-Modell und ein aktiv weiterentwickeltes SDK. Beachten Sie, dass AutoGen 0.4 selbst in den Wartungsmodus gewechselt ist; wenn Sie einen neuen Build starten, zielen Sie direkt auf das Agent Framework ab.
Wenn Sie ein neutrales Python-Framework für Multi-Agenten-Workflows suchen und nicht an Azure gebunden sind, ist AG2 das aktivere Projekt und hat die ursprüngliche Design-Absicht besser bewahrt.
Ist AutoGen / AG2 wirklich produktionsreif?
Hier erfordert eine ehrliche Einschätzung, „kann man etwas bauen, das funktioniert” von „ist es für den Geschäftsbetrieb gehärtet” zu trennen.
Wo beide Zweige an der Produktionsgrenze schwächeln:
- Zuverlässigkeit bei langen Konversationsketten. Multi-Agenten-Gespräche können abdriften, in Schleifen geraten oder inkonsistente Ergebnisse liefern, wenn sich die Kontextfenster füllen. Guardrails erfordern explizite Engineering-Arbeit — sie sind nicht im Lieferumfang enthalten.
- Observability. Nachzuvollziehen, was über fünf Agenten während eines fehlgeschlagenen Runs passiert ist, ist schwieriger als es sein sollte. AutoGen 0.4 führte OpenTelemetry-basiertes Tracing als Erstklassen-Feature ein, was eine echte Verbesserung gegenüber v0.2 ist. In der Praxis deckt die Instrumentierungs-Dokumentation nur die niedrigere Core-API ab; AgentChat-Level-Abstraktionen haben keine dedizierte Tracing-Dokumentation, und Multi-Komponenten-Konfigurationen können Provider-Konflikte auslösen. Für eine Produktions-Build sollten Sie damit rechnen, über das Dokumentierte hinaus in die Observability-Einrichtung investieren zu müssen.
- Fehlerbehandlung. Wenn ein Agentenschritt mitten im Workflow scheitert — ein API-Timeout, eine fehlerhafte Tool-Antwort — hat keiner der beiden Zweige eine robuste eingebaute Retry- und Kompensationslogik. Die bauen Sie selbst.
- Deployment-Muster. AutoGen und AG2 sind Frameworks, keine Plattformen. Es gibt keinen eingebauten Scheduler, keine verwaltete Queue, kein Deployment-Ziel. Sie bringen Ihre eigene Infrastruktur mit.
Vergleichen Sie dies mit dem Produktionsreife-Test, den wir auf alle Agent-Frameworks anwenden: Observability, Fehlerbehandlung, State-Management, Deployment und Sicherheitskontrollen. Nach diesem Massstab schneiden beide AutoGen-Zweige gut auf der Reasoning- und Konversationsebene ab — und schlecht auf der operativen Ebene.
Das ist kein Ausschlusskriterium. Es bedeutet, dass Sie das operative Scaffolding obendrauf aufbauen — oder ein opinioniertes Framework verwenden, das es bereits enthält.
Wer AutoGen oder AG2 ernsthaft in Betracht ziehen sollte
Gut geeignet für:
- Teams, die bereits im Microsoft/Azure-Ökosystem investiert sind, wo der Azure AI Foundry Agent Service — aufgebaut auf dem Microsoft Agent Framework — verwaltete Infrastruktur rund um Multi-Agenten-Workflows hinzufügt
- Forschungsnahe Anwendungen — interne Wissenssynthese, Langform-Analyseaufgaben, komplexe Dokumentprüfung — bei denen das konversationale Agenten-Modell natürlich auf den Workflow passt
- Python-native Entwicklungsteams, die feingranulare Kontrolle über das Agenten-Konversationsdesign wünschen und damit umgehen können, die eigene Deployment-Schicht aufzubauen
- Organisationen, die Multi-Agenten-Reasoning pilotieren, bevor sie sich auf ein schwergewichtigeres Orchestrierungs-Framework wie LangGraph festlegen
Weniger geeignet für:
- Teams, die eine produktionsreife Agenten-Plattform mit eingebautem Scheduling, Observability und Deployment ohne erhebliche Custom-Infrastrukturarbeit benötigen
- Projekte, die TypeScript- oder JavaScript-Integration erfordern — AG2 ist nur Python, und das Microsoft Agent Framework unterstützt Python und .NET (C#), aber nicht TypeScript oder JavaScript direkt
- Einfache Task-Automatisierung, die kein Multi-Agenten-Reasoning braucht — der Overhead lohnt sich nicht
- Organisationen ohne Azure-Footprint, die Managed Hosting möchten — es gibt keine neutrale Managed-Option für AG2
Für einen breiteren Vergleich über Python-Frameworks hinaus behandelt unsere Shortlist quelloffener Agent-Frameworks, wie AutoGen/AG2 neben LangGraph, CrewAI und anderen einzuordnen ist. Wenn Sie speziell Python-basierte Multi-Agenten-Optionen abwägen, ist CrewAI vs. LangGraph eine hilfreiche Ergänzung.
Der Azure-spezifische Fall: Wann Microsofts Stack den Unterschied macht
Ein Szenario, in dem das Microsoft Agent Framework wirklich überzeugend wird: Ihre Organisation nutzt bereits Azure OpenAI Service und Azure AI Foundry, und Microsoft-365-Copilot-Deployments sind in Vorbereitung. In diesem Kontext bietet Ihnen der Azure AI Foundry Agent Service — aufgebaut auf dem Microsoft Agent Framework:
- Verwaltete Agenten-Ausführung mit Azures Compliance- und Sicherheitsprofil
- Native Anbindung an Azure-OpenAI-Modelle ohne zusätzliche Konfiguration
- Integration in Microsoft Identity und Access Management
- Einen Pfad zu Copilot Studio für weniger technische Nutzer, die mit derselben Agenten-Infrastruktur interagieren sollen
Für ein Schweizer oder europäisches KMU mit strengen Anforderungen an die Datenhaltung und einem bestehenden Microsoft-EA-Vertrag ist das kein vernachlässigbarer Vorteil. Azures europäische Rechenzentren und Compliance-Zertifizierungen spielen eine Rolle, und die Integrationskosten, die Sie andernfalls für ein neutrales Framework aufwenden würden, werden durch den erstklassigen Azure-Support teilweise kompensiert.
Der Vorbehalt: Sie bewegen sich jetzt auf einer Microsoft-Produkt-Roadmap, und das Änderungstempo in diesem Stack war hoch — drei grössere Framework-Übergänge in unter drei Jahren. Was heute unter dem Azure AI Foundry Agent Service liegt, kann in zwölf Monaten wesentlich anders aussehen. Bauen Sie auf Schnittstellen — nicht auf Framework-Internals.
Die entscheidende Frage vor der Framework-Wahl
Framework-Auswahl verdient selten das strategische Gewicht, das Ingenieure ihr beimessen. Die wichtigeren Fragen sind:
- Was muss der Agent konkret tun, und passt das Multi-Agenten-Konversationsmodell zu dieser Aufgabe?
- Welche Infrastruktur haben wir bereits, und welche operativen Lücken schafft das Framework?
- Wie viel Engineering-Kapazität fliesst in das Framework-Plumbing statt in das eigentliche Problem, das wir lösen?
AutoGen und AG2 beantworten Frage eins gut für kollaborative Reasoning-Aufgaben. Fragen zwei und drei lassen sie weitgehend Ihnen überlassen.
Dieser Engineering-Overhead ist real. Bei Orange ITS folgt die Framework-Wahl dem Use-Case und den operativen Anforderungen — nicht umgekehrt. Eine 50-köpfige Professional-Services-Firma hat eine andere Kalkulation als ein Fintech mit einem dedizierten MLOps-Team.
Besprechen Sie Ihr Agenten-Projekt, bevor Sie sich auf ein Framework festlegen
Die Wahl zwischen AG2, der Microsoft-AutoGen-Linie, LangGraph oder Custom-Entwicklung hängt von Ihrem Stack, der Kapazität Ihres Teams und davon ab, wie viel operative Infrastruktur Sie selbst betreiben möchten.
Wenn Sie sich in der Evaluierungsphase befinden, kann ein 30-minütiges Gespräch mit dem Orange-ITS-Team Wochen an Framework-Experimenten sparen. Wir schauen uns Ihren Use-Case und Ihre bestehende Infrastruktur an und geben Ihnen eine direkte Einschätzung, welcher Ansatz wahrscheinlich in Produktion geht — und welcher wahrscheinlich ins Stocken gerät.