[EAAPL-AGT008] Event-Driven Agent

Category: Agentic AI Sub-category: Event-Triggered Execution Architecture Version: 1.2 Maturity: Proven Tags: event-driven, kafka, eventbridge, webhooks, trigger-evaluation, back-pressure, context-assembly, reactive-agent Regulatory Relevance: APRA CPS 234, EU AI Act (Art. 9, 14), ISO 42001 §8.4, NIST AI RMF (GOVERN 1.6)

1. Executive Summary

The Event-Driven Agent Pattern defines the architecture for AI agents that are triggered by external events — system alerts, customer actions, data changes, IoT signals, or business process milestones — rather than by direct user requests. Instead of waiting for a human to initiate a task, the event-driven agent subscribes to event streams, evaluates incoming events against trigger conditions, assembles context from the event payload and related data sources, and executes the appropriate agent task autonomously.

For CIO/CTO audiences: this pattern enables your AI workforce to be responsive to your business in real time, not just when humans remember to invoke it. When a customer's credit utilisation crosses a threshold, the agent proactively assembles their financial profile and prepares a targeted intervention. When a production deployment event fires, the agent immediately reviews the diff and post-deployment metrics. When a regulatory filing deadline is approaching, the agent automatically begins document collection and drafting. This is the architectural enabler for proactive AI — agents that respond to business conditions at machine speed, not human speed. The critical governance challenge this pattern solves is ensuring that reactive autonomy does not become uncontrolled autonomy: every trigger has explicit conditions, every event-initiated action is audited, and back-pressure controls prevent event floods from spawning runaway agent farms.

2. Problem Statement

Business Problem

Human operators cannot monitor every data stream, system event, and business condition that should trigger an AI-assisted action. The gap between "an event occurs that warrants action" and "a human notices and delegates the task" is measured in minutes to hours. In high-velocity domains (financial markets, customer churn, security incidents), this gap is where value is lost and risk is accumulated.

Technical Problem

Standard agent invocation patterns are pull-based: a human or calling system must initiate each agent task. There is no infrastructure for agents to subscribe to event streams, evaluate trigger conditions, and self-initiate. Without this, reactive automation requires humans to be in the loop for event detection, which eliminates the latency advantage.

Symptoms of Absence

• Time-sensitive business events (customer churn signals, security anomalies, SLA breaches) are actioned hours after detection
• Operations teams write brittle, bespoke scripts to detect events and invoke agent APIs
• Event floods (e.g., thousands of concurrent alerts) cause ad hoc agent invocation systems to fail without back-pressure controls
• Audit teams cannot reconstruct which events triggered which agent actions without bespoke logging

Cost of Inaction

• Revenue: Customer churn events actioned 2 hours late vs. 2 minutes produce measurably different outcomes
• Risk: Security alerts not actioned within SLA windows create undetected exposure periods
• Operational: Manual event-to-agent wiring creates maintenance overhead that grows with the number of event types

3. Context

When to Apply

• Agent actions should be triggered by data events, not human requests
• Response latency to events matters (seconds to minutes, not hours)
• The organisation has existing event infrastructure (Kafka, EventBridge, webhooks, message queues)
• Event volume can vary significantly; back-pressure handling is required
• Audit trail of which events triggered which agent actions is a compliance requirement

When NOT to Apply

• All agent tasks are human-initiated and interactive
• Event volume is very low (< 10 events/day) — a cron-based or webhook-triggered approach is simpler
• Events are highly structured and actions are deterministic — a rule engine is more appropriate than an AI agent

Prerequisites

• Event infrastructure: Kafka, EventBridge, Azure Event Grid, Google Pub/Sub, or webhook receiver
• Event schema registry for source events
• EAAPL-AGT001 (Single Agent Pattern) for agent execution
• EAAPL-AGT009 (Agent Identity) for event-triggered agent workload identity
• Dead-letter queue infrastructure for failed event processing

Industry Applicability

4. Architecture Overview

The Event-Driven Agent Pattern wraps the standard agent loop (EAAPL-AGT001) with an event-subscription and trigger-evaluation layer. The key architectural insight is that not every event warrants agent invocation: events must be evaluated against trigger conditions before agent resources are committed.

Event Ingestion and Normalisation The Event Ingestion Layer subscribes to one or more event sources (Kafka topics, EventBridge rules, webhook endpoints). Incoming events are normalised into a standard internal event format: event_id, event_type, source_system, timestamp, payload (structured), and entity_references (IDs of related entities whose data may be needed for context assembly). Normalisation decouples the agent infrastructure from the idiosyncratic schemas of source systems.

Trigger Evaluation The Trigger Evaluator is a lightweight, low-latency component that evaluates each normalised event against a library of trigger rules. A trigger rule defines: the event type(s) that activate it, the conditions on the event payload (e.g., amount > 50000, severity == "HIGH"), any deduplication logic (suppress duplicate triggers for the same entity within a time window), and the target agent task type and priority. Trigger evaluation must be fast (target: < 5ms) because it runs on every event; it must not invoke the LLM. If no trigger rule matches, the event is dropped (or archived for audit). If a trigger matches, a task record is created and queued.

Context Assembly When a task is queued from an event trigger, the Context Assembler enriches the triggering event with data from related systems. This enrichment is the most important step: the LLM cannot act on a bare event payload alone. For a credit utilisation event, the context might include: the customer's full credit profile, recent transaction history (last 30 days), prior intervention history, and the organisation's intervention policy guidelines. The Context Assembler retrieves this data using pre-defined data access patterns specified in the trigger rule configuration. Context assembly is an async, potentially multi-source operation that completes before the agent loop begins.

Back-Pressure and Rate Limiting Event floods are a real failure mode in event-driven systems. If a system generates 10,000 alert events per minute (e.g., a monitoring system during a major incident), naively spawning 10,000 agent tasks would exhaust LLM quotas, compute, and downstream API capacity simultaneously. The Back-Pressure Controller enforces: maximum concurrent agent tasks per trigger type, per entity (deduplicate: one active task per customer/entity per trigger type), and globally. Excess events are held in a priority queue (high-priority events pre-empt lower-priority ones) and processed as capacity becomes available. A circuit breaker detects event flood conditions and can switch to a degraded mode (e.g., trigger evaluation only; no agent execution; alert the operations team).

Event-to-Action Audit Every event-triggered agent invocation creates an immutable audit record linking: the source event (event_id, source_system, timestamp), the trigger rule that matched, the task created, and the final agent action. This bidirectional linkage enables compliance teams to answer "what event caused this agent action?" and "what did the agent do in response to this event?" — both questions that arise regularly in financial services and security operations regulatory reviews.

5. Architecture Diagram

6. Components

7. Data Flow

Standard Event-to-Action Flow

Event Flood Scenario

Error Flow

8. Security Considerations

Event Source Trust

• Not all event sources are equally trusted; events from external webhooks are lowest trust and must be authenticated (HMAC signature verification, API key, OAuth)
• Internal events from trusted systems (Kafka with ACLs, EventBridge with resource policies) receive higher trust but are still validated against the schema registry
• Trigger conditions must not be derivable from public information that an attacker could control to trigger privileged agent actions

Audit Linkage

• The bidirectional event-to-action audit log is the forensic foundation for investigating "why did the agent do that?" — it must be tamper-proof and queryable

OWASP LLM Top 10

9. Governance Considerations

Trigger Rule Governance

• Every trigger rule must be approved by the business owner of the source event and the owner of the target agent action before activation
• Trigger rules are versioned; changes require change management review with impact assessment
• Quarterly review of all active trigger rules: is each rule still producing value? Are any rules causing unintended agent actions?

Governance Artefacts

10. Operational Considerations

SLOs

Monitoring

• Event ingestion rate per topic/source: detect floods, silences (source failure), and schema drift
• Trigger match rate per rule: sustained 0% match rate may indicate rule misconfiguration or source schema change
• Context assembly success rate per data source: low rate indicates data source degradation
• Agent task queue depth: early warning of processing backlogs

11. Cost Considerations

Cost Drivers

Indicative Cost Range (per 10,000 triggered events/day)

12. Trade-Off Analysis

Event Trigger Architecture Options

Architectural Tensions

13. Failure Modes

14. Regulatory Considerations

APRA CPS 234

• Event-driven agents that access or modify customer data are subject to CPS 234 information security requirements
• The event-to-action audit log is a CPS 234-mandated information security record for automated system actions

EU AI Act

• Art. 14 (Human Oversight): for high-risk event-triggered actions, a human approval gate between trigger and execution is required; the priority queue provides a hold point for this gate
• For GPAI models used in event-driven agents: the trigger rule library's scope constraints are the documented "intended use" limitation

NIST AI RMF

• GOVERN 1.6: the trigger rule register documents the intended use and scope constraints for each event-triggered agent behaviour

15. Reference Implementations

AWS

Azure

On-Premises

16. Related Patterns

17. Maturity Assessment

Overall Maturity: Proven

18. Revision History