Skip to main content

Event Processing Model

Who this is for

Builders wiring event sources (EventBridge, SQS, SNS, S3) to a workflow agent on AgentCore Runtime. If you haven't picked a sample yet, start with the workflow quickstart.

Workflow agents process events asynchronously. An event source delivers a trigger, a Lambda normalizes the payload and invokes the AgentCore Runtime, and the agent handles reasoning and action.

Event-Driven Execution​

Event-Driven Execution

Agents react to real-world events: tickets filed, alerts triggered, documents uploaded, schedules fired. EventBridge, SNS, SQS, and S3 all serve as trigger sources. The agent wakes, reasons, acts, and goes back to sleep. No idle compute, no polling loops.

Runtime

Cost-Efficient by Design

Scale-to-zero means no idle compute between events. Route cheaper models (Haiku) for simple triage and premium models (Sonnet) for complex reasoning. Short-lived sessions don't hold microVMs open for hours. Each invocation gets exactly the resources it needs, then terminates.

Runtime

Service Identity (Machine-to-Machine Auth)

Workflow agents authenticate as service principals, not end-users. AgentCore Identity supports machine-to-machine flows via client credentials and SigV4, so the agent can call internal APIs with a scoped service identity. No shared secrets, no over-privileged roles.

Identity

Platform Capabilities​

CapabilityWhat AgentCore Provides
Event ingestionLambda trigger receives from EventBridge, SNS, SQS, S3, or API Gateway.
Payload normalizationTrigger Lambda extracts key fields and forwards structured JSON to Runtime.
IdempotencyAgent can check if event was already processed via DynamoDB or Memory.
Retry with backoffDLQ captures failed invocations for replay. CloudWatch alarms on DLQ depth.
Concurrent processingMultiple events processed in parallel. Each gets its own microVM.
Timeout handlingRuntime sessions have a default idle timeout of 15 minutes and a maximum lifetime of 8 hours. These are runtime-level limits, not workflow-specific.

Trigger Lambda Pattern​

The trigger Lambda is the bridge between your event source and AgentCore Runtime. Note that runtimeSessionId must be at least 33 characters — see the Runtime sessions documentation for the full ID format requirements.

import json
import os
import uuid

import boto3

# Initialize the Bedrock AgentCore client
agent_core_client = boto3.client('bedrock-agentcore')

def handler(event, context):
    """Receives event from EventBridge/SNS/SQS, invokes AgentCore Runtime."""
    # Extract relevant fields from the event source
    detail = event.get("detail", event)

    payload = {
        "entity_id": detail["entity_id"],
        "event_type": detail["event_type"],
        "priority": detail.get("priority", "MEDIUM"),
        "timestamp": detail.get("timestamp"),
        "context": detail.get("context", {}),
    }

    # runtimeSessionId must be at least 33 characters.
    # Appending a UUID suffix ensures uniqueness and satisfies the minimum length.
    # See: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-sessions.html
    session_id = f"event-{detail['entity_id']}-{uuid.uuid4()}"

    response = agent_core_client.invoke_agent_runtime(
        agentRuntimeArn=os.environ["RUNTIME_ARN"],
        runtimeSessionId=session_id,
        payload=json.dumps(payload).encode(),
    )

    return {"statusCode": 200, "body": "Agent invoked"}

Event Source Options​

Event SourceUse ForDelivery Model
EventBridgeCustom events, AWS service events, SaaS partner eventsPush (rule-based)
SNSFan-out notifications, cross-account event distributionPush (pub/sub)
SQSBuffered processing, rate limiting, retry with DLQPull (polling)
S3Document uploads, file processing triggersPush (notification)
API GatewayWebhook receivers from external systems (Jira, GitHub, etc.)Push (HTTP)
CloudWatchScheduled automation (cron), alarm-based triggersPush (schedule)

The 5-Step Pattern​

Every workflow automation agent follows this execution loop:

① Trigger (event arrives)→② Enrich (gather context)→③ Reason (LLM decides)→④ Act (execute via tool)→⑤ Emit (publish event)

① Trigger — An event arrives from one of the sources above. The trigger Lambda normalizes it into a structured payload.

② Enrich — The agent calls read-only tools to gather context: service health, ticket history, user profile, related incidents.

③ Reason — The LLM analyzes the enriched context and determines the best course of action. This is where scripts break and agents shine: handling edge cases, ambiguous inputs, and novel situations.

④ Act — The agent executes actions via tools: restart a service, update a ticket, send a notification, create a resource.

⑤ Emit — The agent publishes a completion event (to EventBridge, SNS, or a downstream system) with the outcome summary. This enables event chaining and audit trails.

Further Reading​