Event-driven Agenten: AutoGen v0.4 / AG2 Architektur erklärt

Event-driven Agenten sind autonome Software-Aktoren, die asynchron über Nachrichten und Events kommunizieren – nicht in einem festen, sequentiellen Loop. Jeder Agent reagiert auf eingehende Events, verarbeitet sie unabhängig und publiziert seine Ergebnisse als neue Events. Diese Architektur, wie sie AutoGen v0.4 und der community-getriebene Fork AG2 umsetzen, entkoppelt Agenten voneinander und erlaubt Parallelität, lose Kopplung und lange Laufzeiten.

• Kern: Agenten = Aktoren mit eigenem Zustand, die ausschließlich über asynchrone Nachrichten kommunizieren statt über einen zentralen Steuer-Loop.
• Vorteil: Lose Kopplung, echte Parallelität und Eignung für lang laufende Prozesse (Minuten bis Stunden) mit Wartezeiten auf externe Systeme oder Menschen.
• Trade-off: Höhere Komplexität bei Debugging, Tracing und Nachweisbarkeit – der Kontrollfluss ist nicht mehr linear ablesbar.

Vom orchestrierten Loop zum Event-Bus

Die meisten klassischen Agent-Muster sind streng sequentiell. Beim ReAct-Muster etwa durchläuft ein einzelner Agent auf Basis eines Large Language Model (LLM) wiederholt den Zyklus Thought → Action → Observation, bis er eine finale Antwort emittiert. Die Latenz ist dabei von Natur aus seriell: Sie entspricht ungefähr der Zahl der Schritte multipliziert mit der Summe aus LLM-Antwortzeit und Tool-Antwortzeit. Auch Plan-and-Execute oder ReWOO planen zwar im Voraus, führen die Schritte aber im Kern nacheinander aus.

Event-driven Architekturen brechen mit diesem Modell. Statt eines zentralen Loops, der den nächsten Schritt diktiert, gibt es eine Nachrichten- oder Topic-Schicht (einen Event-Bus). Agenten abonnieren bestimmte Topics, reagieren auf publizierte Events und stoßen ihrerseits Folge-Events an. Der Forschungsstand 2026 hält fest, dass die Frameworks generell auf ein gemeinsames Primitiv konvergieren – eine Kombination aus State-Graph und Tool-Calling, wie sie LangGraph, das Microsoft Agent Framework Workflow und AutoGen Core teilen. Reine Prompt-Muster-Unterschiede treten dabei zurück; entscheidend werden Middleware-, Observability- und Context-Engineering-Qualität.

Das Actor-Model als theoretische Grundlage

Event-driven Agenten setzen das aus der nebenläufigen Programmierung bekannte Actor-Model um. Ein Aktor ist eine isolierte Recheneinheit mit drei Eigenschaften:

• Eigener, gekapselter Zustand – kein geteilter Speicher zwischen Aktoren, also keine klassischen Race Conditions über gemeinsame Variablen.
• Kommunikation nur über Nachrichten – ein Aktor verarbeitet eingehende Nachrichten typischerweise eine nach der anderen aus seiner Mailbox.
• Dynamik zur Laufzeit – ein Aktor kann seinen Zustand ändern, neue Aktoren erzeugen und weitere Nachrichten verschicken.

In AutoGen v0.4 spiegelt sich das in der RoutedAgent-Abstraktion und einer Pub/Sub-Topic-Schicht wider. Die offizielle AutoGen-Dokumentation beschreibt etwa das Reflection-Muster als zwei RoutedAgents, die über Pub/Sub-Topics kommunizieren – einen CoderAgent und einen ReviewerAgent, die bis zur Konvergenz iterieren oder bei einem max_iterations-Limit stoppen. Genau diese Topic-Routing-Logik ist der Übergang vom hartverdrahteten Loop zur ereignisgesteuerten Kopplung: Welcher Agent als Nächstes aktiv wird, entscheidet nicht ein zentraler Controller, sondern das publizierte Event und die Topic-Abonnements.

AutoGen v0.4, AG2 und der Microsoft-Kontext

Wichtig für DACH-Entscheider, die den Microsoft-Stack evaluieren: AutoGen ist laut Research-Stand 2026 offiziell im Maintenance-Modus. Microsoft hat AutoGen und Semantic Kernel zum Microsoft Agent Framework konsolidiert und leitet neue Projekte dorthin – die Migration-Guide (from-autogen) ist die maßgebliche Referenz für bestehende AutoGen-Nutzer. Das Agent Framework führt zudem den SPAR-Zyklus (Sense → Plan → Act → Reflect) als produktisierte Variante eines kombinierten ReAct-plus-Reflexion-Musters.

Parallel existiert AG2 als community-getriebene Fortführung der AutoGen-Linie. Wer heute eine event-driven Architektur auf Basis dieser Idee baut, wählt also praktisch zwischen drei Optionen: bestehendes AutoGen v0.4 (lauffähig, aber nur noch gepflegt), das community-getragene AG2 oder das von Microsoft empfohlene Agent Framework für Neuprojekte im Enterprise-Umfeld.

Wann ereignisgesteuert besser skaliert

Ereignisgesteuert lohnt sich nicht immer. Drei Bedingungen sprechen dafür:

1. Lose Kopplung – Agenten sollen unabhängig deploybar, austauschbar und einzeln skalierbar sein. Ein Recherche-Agent darf neu deployt werden, ohne den Schreib-Agenten zu berühren.
2. Parallelität – mehrere Teilaufgaben laufen gleichzeitig. Cognitions Befunde aus „Don't Build Multi-Agents" (Juni 2025) und „Multi-Agents: What's Actually Working" (April 2026) sind hier der zentrale Leitfaden: Multi-Agent-Setups funktionieren für lesende, parallele Informationssammlung, während schreibende Zustandsänderungen single-threaded bleiben sollten. Devin nutzt dafür einen Manager-Devin, der über internes MCP Kind-Devins erzeugt. Übersetzt für Agenturkunden: ein starker Agent mit Tools als Standard, parallele Sub-Agenten nur fürs Sammeln von Informationen, nie für Schreiboperationen oder Statusänderungen.
3. Lange Laufzeiten – Prozesse über Minuten oder Stunden, mit Wartezeiten auf externe APIs, Batch-Systeme oder Menschen (Human-in-the-Loop). Ein synchroner Loop würde hier blockieren; ein event-driven System wartet schlicht auf das nächste Event.

Vor- und Nachteile gegenüber orchestrierten Loops

Die größte Schwäche ist die Beobachtbarkeit. Bei einem ReAct-Loop liegt der vollständige Thought/Action/Observation-Trace linear vor und ist direkt auditierbar – ein realer Vorteil für regulierte DACH-Branchen. Im event-driven Modell ist der Kontrollfluss über viele Aktoren verteilt; Fehler können propagieren, und ohne sorgfältiges Tracing wird die Ursachenanalyse schwer. Observability-Werkzeuge wie LangSmith, Langfuse oder Arize Phoenix sind daher faktisch Pflicht. Für DSGVO und EU AI Act müssen die verteilten Event-Traces lückenlos, korreliert und PII-bereinigt persistiert werden.

Konkretes Beispiel: parallele Markt-Recherche

Eine Marketing-Agentur soll für einen B2B-Kunden eine Wettbewerbsanalyse erstellen: fünf Konkurrenten, je drei Datenquellen (Website, Pressemeldungen, Social Media). In einem ReAct-Loop liefen das streng nacheinander: 5 × 3 = 15 sequentielle Tool-Schritte. Bei angenommen 8 Sekunden pro Schritt (LLM- plus Tool-Antwortzeit) ergäbe das grob 120 Sekunden Gesamtlatenz – und jeder Schritt zahlt zudem das volle Kontext-Präfix erneut.

Ereignisgesteuert sieht es so aus (Pseudo-Ablauf):

```
Event: AnalyseGestartet(konkurrenten=[A,B,C,D,E])
-> Orchestrator publiziert 5 Events "AnalysiereKonkurrent"
-> 5 ResearchAgents reagieren PARALLEL, je 3 Quellen
-> jeder publiziert "TeilergebnisFertig"
-> AggregatorAgent abonniert "TeilergebnisFertig"
-> bei 5/5 Teilergebnissen publiziert er "BerichtBereit"
-> WriterAgent (single-threaded!) erstellt den finalen Bericht
```

Die fünf Recherche-Aktoren laufen gleichzeitig; die Wandzeit sinkt grob auf die Dauer des langsamsten Zweigs (≈ 3 × 8 = 24 Sekunden) plus Aggregation – statt 120 Sekunden seriell. Entscheidend nach dem Cognition-Prinzip: Die lesenden Recherche-Schritte sind parallelisiert, der schreibende finale Bericht bleibt single-threaded bei einem einzigen WriterAgent. So entstehen keine widersprüchlichen Schreibentscheidungen. Wichtig: Die hier genannten Sekundenwerte sind illustrative Richtwerte; die realen Zahlen hängen stark von Modell, Tool-Latenz und Netzwerk ab und sollten auf der eigenen Last gemessen werden.

Für Agenturen und B2B-Entscheider

Event-driven Agenten sind kein Selbstzweck. Starten Sie nach dem in der Praxis bestätigten Grundsatz mit dem einfachsten Muster, das funktioniert – meist ein ReAct-Loop – und eskalieren Sie erst zu ereignisgesteuerten Mehr-Aktoren-Architekturen, wenn gemessene Anforderungen (Parallelität, lange Laufzeiten, lose Kopplung) es rechtfertigen. Für Marketing-Agenturen ist der typische Sweet Spot die parallele, lesende Informationsbeschaffung mit einem single-threaded Schreibschritt am Ende. Wer einen Microsoft-Stack evaluiert, sollte 2026 das Microsoft Agent Framework statt des im Maintenance-Modus befindlichen AutoGen wählen; AG2 ist die community-getriebene Alternative. Blck Alpaca unterstützt DACH-Unternehmen dabei, das passende Architekturmuster auszuwählen, Observability für DSGVO- und EU-AI-Act-Konformität aufzusetzen und Agenten-Workflows mess- statt bauchgefühlgetrieben zu skalieren.