AGENTPERF04-BP03 Design high-performing event-driven integration patterns
Agents that react to events in real time, data changes, user actions, and system alerts deliver faster business outcomes than agents that poll for work. Overly broad event subscriptions trigger agents for irrelevant events, missing filtering causes agents to process and discard events they don't need. Inefficient routing adds delays that push response time past user expectations.
Desired outcome:
-
You have agent workflows triggered by precisely filtered events that match their processing requirements, with minimal latency between event emission and agent invocation.
-
You have efficient event schemas that include only routing metadata, with agents retrieving full context on demand.
-
You have event-driven patterns that support both real-time and batch processing modes.
Common anti-patterns:
-
Subscribing agents to broad event streams without filtering, forcing agents to receive and process events they immediately discard and wasting compute resources.
-
Using polling-based event detection instead of push-based event delivery, adding latency and consuming compute during idle periods.
-
Including full data payloads in events rather than event references, inflating event size and network transfer time when most consumers only need a subset.
Benefits of establishing this best practice:
-
Push-based delivery reduces latency between event occurrence and agent invocation.
-
Filtering at the event bus reduces compute waste by invoking agents only for relevant events.
Level of risk exposed if this best practice is not established: Medium
Implementation guidance
Use Amazon EventBridge
For agents that need to react to database changes,
Amazon DynamoDB Streams triggers agents directly from data changes
without polling. Event deduplication using idempotency keys helps
prevent agents from processing the same event twice, relevant
whenever at-least-once delivery is the default. For complex event
processing that requires correlation of multiple events before
triggering an agent,
AWS Step Functions
Implementation steps
-
Configure EventBridge rules with content-based filtering to route events to specific agents: Use content-based filtering on Amazon EventBridge
so agents receive only the events whose attributes match their responsibilities. -
Design minimal event schemas with references rather than full payloads, registered in EventBridge Schema Registry: Keep event payloads to routing metadata and identifiers, store full data in S3 or DynamoDB, and register schemas in EventBridge Schema Registry so consumers can generate bindings.
-
Implement DynamoDB Streams for data-change-driven agent triggers: Use Amazon DynamoDB Streams to trigger agents directly from data changes without polling.
-
Implement idempotency keys for event deduplication in agent processing logic: Apply idempotency keys so agents don't process the same event twice under at-least-once delivery.
-
Monitor event processing metrics: event-to-invocation latency, filter efficiency, and throughput: Publish these metrics to CloudWatch so filtering and routing can be tuned from measured behavior.
Resources
Related best practices:
Related documents:
Related services: