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

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 umsetzt, 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. Viele Frameworks bieten inzwischen graphbasierte Workflows mit Tool-Calling an, etwa LangGraph und die Workflows im Microsoft Agent Framework. 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 iterieren, bis der Reviewer den Code freigibt. Als weitere mögliche Abbruchbedingung nennt die Doku eine Höchstzahl an Durchläufen. 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 eigenem GitHub-Repository im Maintenance-Modus und bekommt keine neuen Features mehr. Microsoft hat AutoGen und Semantic Kernel zum Microsoft Agent Framework zusammengeführt und leitet neue Projekte dorthin. Der Migration Guide von AutoGen ist die maßgebliche Referenz für bestehende AutoGen-Nutzer.

AG2 ist kein Ableger der v0.4-Architektur. Laut eigener Darstellung führt das Projekt das ursprüngliche AutoGen als Community-Projekt weiter und bietet Nutzern von AutoGen 0.2 einen abwärtskompatiblen Umstiegsweg. Die klassische AG2-API baut auf konversationsbasierten Mustern wie ConversableAgent und GroupChat auf. Diese Klassen liegen heute in AG2 Classic, das nur noch kritische und Sicherheitskorrekturen erhält. Seit v1.0 setzt AG2 auf ein eigenes Netzwerkmodell: Ein zentraler Hub hält den verbindlichen Zustand, Agenten tauschen Events über Kanäle aus. RoutedAgent und Pub/Sub-Topics aus AutoGen v0.4 kommen darin nicht vor. Wer heute eine event-driven Architektur baut, wählt also praktisch zwischen bestehendem AutoGen v0.4 (lauffähig, aber nur noch gepflegt), dem Microsoft Agent Framework für Neuprojekte im Enterprise-Umfeld und AG2 als eigenständiger Alternative mit anderem Modell.

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. Bei Devin kann ein Manager-Devin eine größere Aufgabe aufteilen, Kind-Devins dafür starten und deren Fortschritt über ein internes MCP koordinieren. Ü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. Der EU AI Act schreibt automatische Protokollierung nur für Hochrisiko-KI-Systeme vor: Diese müssen Ereignisse über ihre gesamte Lebensdauer automatisch aufzeichnen können (Art. 12 EU AI Act). Nach der Änderungsverordnung (EU) 2026/1744 (Digital Omnibus zur KI) gelten die Hochrisiko-Pflichten für Systeme nach Anhang III erst ab 2. Dezember 2027, für KI in Produkten nach Anhang I ab 2. August 2028. Die DSGVO verlangt zugleich, personenbezogene Daten auf das notwendige Maß zu beschränken und nicht länger als erforderlich identifizierbar zu speichern (Art. 5 DSGVO). Verteilte Event-Traces sollten deshalb korreliert und PII-bereinigt gespeichert werden, damit Nachvollziehbarkeit und Datenminimierung zusammengehen.

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 liefe 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. Starte nach dem in der Praxis bestätigten Grundsatz mit dem einfachsten Muster, das funktioniert, meist ein ReAct-Loop, und eskaliere 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 eine Community-Alternative mit eigenem Architekturmodell, kein Ersatz für die v0.4-Actor-Runtime. 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.