New pattern - sfn-agentcore-bedrock-cdk#3066
Conversation
…estration pattern Step Functions state machine orchestrates multiple Bedrock AgentCore agents in parallel using Map state, then aggregates responses via Bedrock Converse API. Uses NodejsFunction with bundled SDK since @aws-sdk/client-bedrock-agentcore is not in Lambda runtime. Key features: - Parallel multi-agent invocation via SFN Map state - Lambda intermediary handles AgentCore streaming responses - Bedrock Converse aggregation of multi-agent outputs - Configurable agent runtime ARNs and model ID - Retry logic for AgentCore cold starts
- Scope bedrock:InvokeModel to inference profile ARN + foundation-model/* - Scope bedrock:ApplyGuardrail to account guardrails instead of wildcard - Add comment explaining agentcore wildcard (dynamic user-provided ARNs)
|
Hi @biswanathmukherjee 👋 Friendly nudge — this pattern is ready for review. Deployed and tested end-to-end on a live AWS account. Would appreciate a look when you have time. Thank you! |
|
Hi @biswanathmukherjee 👋 This pattern demonstrates a unique integration: Step Functions orchestrating multiple Bedrock AgentCore agents in parallel via Map state — the first pattern combining SFN with AgentCore. No existing pattern covers multi-agent orchestration. Deployed and tested. Would appreciate a review! |
|
@NithinChandranR-AWS -- thanks for contributing this pattern! The idea of using Step Functions as a deterministic orchestrator for multi-agent workflows is compelling. You get predictable execution paths, built-in retries, and auditability that you do not get with dynamic LLM-driven orchestration. Nice architectural choice. One suggestion: the testing example uses a generic prompt ("What are the best practices for building serverless applications?") with placeholder agent ARNs (agent1, agent2). Without context on what makes each agent different, it is hard for users to understand why they would fan out the same prompt to multiple agents and what value the aggregation provides. Consider updating the example to show agents with distinct specializations, for example, a security agent, a cost-optimization agent, and an architecture agent all receiving the same migration question, each responding from their domain expertise, and the aggregation producing a unified plan. That way the multi-agent value proposition clicks immediately for builders picking up this pattern. A brief "When to use this pattern" section in the README would also help users understand when to reach for SFN-orchestrated multi-agent vs. single-agent or dynamic orchestration approaches. |
Step Functions + Bedrock AgentCore Multi-Agent Orchestration
Orchestrates multiple Bedrock AgentCore agents in parallel using SFN Map state, then aggregates responses via Bedrock Converse API.
Architecture: Trigger Lambda → SFN → Map (parallel AgentCore invocations) → Aggregate Lambda (Bedrock Converse) → Summary
Key decisions:
@aws-sdk/client-bedrock-agentcorevia NodejsFunction (not in Lambda runtime)Deployed and tested — SFN orchestrated 2 AgentCore agents in parallel, produced aggregated summary via Bedrock Converse.
TypeScript / AWS CDK