Event-driven agents: AutoGen v0.4 architecture explained, and where AG2 fits

Event-driven agents are autonomous software actors that communicate asynchronously via messages and events, not in a fixed, sequential loop. Each agent reacts to incoming events, processes them independently and publishes its results as new events. This architecture, as implemented by AutoGen v0.4, decouples agents from one another and allows for parallelism, loose coupling and long runtimes.

• Core: Agents = actors with their own state that communicate exclusively via asynchronous messages instead of through a central control loop.
• Advantage: Loose coupling, genuine parallelism and suitability for long-running processes (minutes to hours) with waiting times on external systems or people.
• Trade-off: Higher complexity in debugging, tracing and verifiability. The control flow is no longer linearly readable.

From the orchestrated loop to the event bus

Most classic agent patterns are strictly sequential. In the ReAct pattern, for instance, a single agent based on a Large Language Model (LLM) repeatedly runs through the cycle Thought -> Action -> Observation until it emits a final answer. The latency is inherently serial: it corresponds roughly to the number of steps multiplied by the sum of LLM response time and tool response time. Plan-and-Execute or ReWOO do plan ahead, but at their core they still execute the steps one after another.

Event-driven architectures break with this model. Instead of a central loop that dictates the next step, there is a message or topic layer (an event bus). Agents subscribe to particular topics, react to published events and in turn trigger follow-up events. Many frameworks now offer graph-based workflows with tool calling, for example LangGraph and the workflows in the Microsoft Agent Framework. Pure prompt-pattern differences recede into the background; what becomes decisive is the quality of middleware, observability and context engineering.

The actor model as the theoretical foundation

Event-driven agents implement the actor model familiar from concurrent programming. An actor is an isolated computational unit with three properties:

• Its own, encapsulated state: no shared memory between actors, and therefore no classic race conditions over shared variables.
• Communication only via messages: an actor typically processes incoming messages one after another from its mailbox.
• Dynamics at runtime: an actor can change its state, create new actors and send further messages.

In AutoGen v0.4 this is reflected in the RoutedAgent abstraction and a pub/sub topic layer. The official AutoGen documentation describes, for example, the reflection pattern as two RoutedAgents that communicate via pub/sub topics: a CoderAgent and a ReviewerAgent that iterate until the reviewer approves the code. The documentation names a maximum number of iterations as a further possible stopping condition. It is precisely this topic-routing logic that constitutes the transition from the hard-wired loop to event-driven coupling: which agent becomes active next is decided not by a central controller but by the published event and the topic subscriptions.

AutoGen v0.4, AG2 and the Microsoft context

Important for DACH decision-makers evaluating the Microsoft stack: according to its own GitHub repository, AutoGen is in maintenance mode and no longer receives new features. Microsoft has merged AutoGen and Semantic Kernel into the Microsoft Agent Framework and is directing new projects there. The migration guide from AutoGen is the definitive reference for existing AutoGen users.

AG2 is not an offshoot of the v0.4 architecture. According to its own description, the project continues the original AutoGen as a community project and offers AutoGen 0.2 users a backward-compatible upgrade path. The classic AG2 API is built on conversation-based patterns such as ConversableAgent and GroupChat. These classes now live in AG2 Classic, which receives only critical and security fixes. Since v1.0, AG2 uses its own network model: a central hub holds the authoritative state, and agents exchange events through channels. RoutedAgent and pub/sub topics from AutoGen v0.4 do not appear in it. Anyone building an event-driven architecture today is therefore effectively choosing between existing AutoGen v0.4 (operational, but only maintained), the Microsoft Agent Framework for new projects in the enterprise environment, and AG2 as an independent alternative with a different model.

When event-driven scales better

Event-driven approaches are not always worthwhile. Three conditions argue in their favor:

1. Loose coupling: agents should be independently deployable, replaceable and individually scalable. A research agent may be redeployed without touching the writing agent.
2. Parallelism: several subtasks run at the same time. Cognition's findings from “Don't Build Multi-Agents” (June 2025) and “Multi-Agents: What's Actually Working” (April 2026) are the central guideline here: multi-agent setups work for reading, parallel information gathering, while writing state changes should remain single-threaded. In Devin, a manager Devin can split a larger task, spawn child Devins for the pieces and coordinate their progress through an internal MCP. Translated for agency clients: one strong agent with tools as the default, parallel sub-agents only for gathering information, never for write operations or status changes.
3. Long runtimes: processes spanning minutes or hours, with waiting times on external APIs, batch systems or people (human-in-the-loop). A synchronous loop would block here; an event-driven system simply waits for the next event.

Advantages and disadvantages compared with orchestrated loops

The biggest weakness is observability. With a ReAct loop, the complete Thought/Action/Observation trace is available linearly and is directly auditable, a real advantage for regulated DACH sectors. In the event-driven model, the control flow is distributed across many actors; errors can propagate, and without careful tracing, root-cause analysis becomes difficult. Observability tools such as LangSmith, Langfuse or Arize Phoenix are therefore effectively mandatory. The EU AI Act requires automatic logging only for high-risk AI systems: these must technically allow events to be recorded automatically over their entire lifetime (Art. 12 EU AI Act). Under the amending Regulation (EU) 2026/1744 (Digital Omnibus on AI), the high-risk obligations apply to Annex III systems only from December 2, 2027, and to AI in Annex I products from August 2, 2028. At the same time, the GDPR requires personal data to be limited to what is necessary and kept in identifiable form no longer than needed (Art. 5 GDPR). Distributed event traces should therefore be correlated and stored with PII removed, so that traceability and data minimization go together.

A concrete example: parallel market research

A marketing agency is to produce a competitive analysis for a B2B client: five competitors, three data sources each (website, press releases, social media). In a ReAct loop these would run strictly one after another: 5 × 3 = 15 sequential tool steps. Assuming 8 seconds per step (LLM plus tool response time), that would give roughly 120 seconds of total latency, and each step additionally pays the full context prefix again.

Event-driven, it looks like this (pseudo-flow):

```
Event: AnalysisStarted(competitors=[A,B,C,D,E])
-> Orchestrator publishes 5 "AnalyzeCompetitor" events
-> 5 ResearchAgents react IN PARALLEL, 3 sources each
-> each publishes "PartialResultReady"
-> AggregatorAgent subscribes to "PartialResultReady"
-> at 5/5 partial results it publishes "ReportReady"
-> WriterAgent (single-threaded!) produces the final report
```

The five research actors run concurrently; the wall-clock time falls roughly to the duration of the slowest branch (≈ 3 × 8 = 24 seconds) plus aggregation, instead of 120 seconds serially. Decisive, following the Cognition principle: the reading research steps are parallelized, while the writing final report remains single-threaded with a single WriterAgent. This way no conflicting write decisions arise. Important: the timings in seconds cited here are illustrative reference values; the real numbers depend heavily on model, tool latency and network, and should be measured against your own load.

For agencies and B2B decision-makers

Event-driven agents are not an end in themselves. Start, in line with the principle confirmed in practice, with the simplest pattern that works, usually a ReAct loop, and only escalate to event-driven multi-actor architectures when measured requirements (parallelism, long runtimes, loose coupling) justify it. For marketing agencies, the typical sweet spot is parallel, reading information gathering with a single-threaded writing step at the end. Anyone evaluating a Microsoft stack should, in 2026, choose the Microsoft Agent Framework rather than the maintenance-mode AutoGen. AG2 is a community alternative with its own architecture model, not a replacement for the v0.4 actor runtime. Blck Alpaca supports DACH companies in selecting the right architectural pattern, setting up observability for GDPR and EU AI Act compliance, and scaling agent workflows by measurement rather than gut feeling.