Agents triggered by events in your systems rather than by direct user prompts.
Event-driven agents react to things that happen rather than waiting to be asked. They monitor event streams from business systems and activate when defined conditions are met — completing the vision of AI that works continuously in the background, not just when a user types a prompt.
An event-driven agent architecture consists of an event source (systems that emit events), an event bus (a queue or stream that routes events to subscribers), and agent subscribers (agents that activate when they receive events matching their subscription filters). When an agent activates, it processes the event, takes defined actions using its tools, and may emit new events that trigger other agents. The critical design constraints are: preventing event loops (agent activations that trigger more events that trigger more activations without end); handling event ordering (events arriving out of sequence); and managing event loss (events dropped from the queue before being processed).
A commercial property firm uses event-driven agents to monitor its lease management system. An agent subscribes to the event stream for leases approaching expiration. When a lease enters the 6-month window, it activates: retrieves current market rent data, compares to in-place rent, drafts a renewal proposal for the asset manager, and logs the activation. A second agent subscribes to the event for when proposals are marked 'no response after 30 days' and escalates to the managing director. A third agent monitors the event stream for emergency maintenance requests and routes them to the facilities team with SLA countdown tracking.
The most valuable agents are the ones working when you are not watching. Event-driven agents close the gap between 'AI you interact with' and 'AI that runs your operations'. They convert reactive processes (someone noticing a lease expiry and manually triggering a workflow) into proactive ones (the system detecting the condition and acting before anyone needs to notice).
How this pattern fails in practice — and what to watch for.
Agent A activates on Event Type X and emits Event Type Y. Agent B activates on Event Type Y and emits Event Type X. The two agents trigger each other indefinitely. Event volume grows exponentially until infrastructure limits are hit. This can consume API budget, storage, and compute in minutes.
Events arrive in a different order than they were emitted. A 'contract signed' event arrives before the 'contract drafted' event it depends on. The agent processes them in arrival order, activating on a signed contract it has no record of drafting, producing incoherent output.
Events are dropped from the queue during a peak load period. The agents never activate for those events. The upstream system has no visibility into whether its events were processed. Leases expire, maintenance requests go unrouted, and incidents go undetected — all silently.
Seven things to verify before deploying this pattern in production.
Event-driven agents are covered in AIDA under D5 Deployment Safety, with a focus on loop prevention and event loss. CAIG examines the governance of event-driven activation: who authorises an agent to subscribe to which event types, and how is this controlled? CAIAUD auditors focus on whether event activation logs exist and whether event loop protection is implemented and tested.
The AIDA certification covers all 21 agentic design patterns with a focus on deployment safety, governance, and the PSF. Free to attempt.