Overview
Event-driven agents react to events rather than direct calls. An event broker routes messages so producers never need to know who receives them, enabling scalable, loosely-coupled multi-agent systems.
Architecture
Event Source → Event Broker → Agent A (subscribes to "order.*")
→ Agent B (subscribes to "payment.*")
→ Agent C (subscribes to "inventory.*")
Event Types
Domain Events
Business occurrences: "OrderPlaced", "PaymentReceived", "InventoryLow"
Command Events
Requests for action: "ProcessOrder", "SendNotification"
Query Events
Information requests with async responses
Benefits
Loose Coupling
Agents don't know about each other—only about event types.
Scalability
Add more agent instances to handle load.
Resilience
Failed agents don't block others; events can be retried.
Flexibility
Add new agents without modifying existing ones.
Event Schema
{
"eventType": "order.created",
"timestamp": "2025-01-15T10:30:00Z",
"source": "order-service",
"data": {
"orderId": "12345",
"customerId": "67890",
"items": [...]
},
"metadata": {
"correlationId": "abc-123",
"traceId": "xyz-789"
}
}
Multi-Agent Event Patterns
Choreography
Agents coordinate through events without central control.
Saga Pattern
Long-running transactions with compensating events for rollback.
Event Sourcing
Reconstruct agent state from event history.
Implementation Considerations
- Event ordering may not be guaranteed
- Idempotency required for event handlers
- Event schema evolution needs planning
- Monitoring and observability essential
When to Use
Good fit:
- High-throughput systems
- Workflows spanning multiple services
- Systems requiring audit trails
- Scenarios where agents should be independently deployable
Caution for:
- Simple request-response scenarios
- Strict ordering requirements
- Low-latency, synchronous needs