There’s a pattern you hit when building multi-agent systems that most demos don’t prepare you for: it works perfectly in development, falls apart at scale.
You build a LangGraph workflow with four agents. It runs beautifully locally — sequential turns, state maintained, no issues. You deploy it. At 10 concurrent users, it’s fine. At 50, you start seeing session leaks. At 100, your state store is瓶颈 and your agents are stepping on each other.
The problem isn’t the agent logic. It’s infrastructure. State management, concurrency control, cold starts, stateless function limits — the stuff that demos paper over with “just run it on a server.”
AWS released something two weeks ago that directly addresses this: a serverless reference architecture combining LangGraph with Amazon Bedrock AgentCore, deployed on Lambda and DynamoDB. The post is on the AWS Machine Learning Blog. It’s a practical blueprint, not a marketing slide.
What the Architecture Actually Looks Like
The core insight is that LangGraph handles orchestration — defining what the agent graph looks like — while Bedrock AgentCore handles infrastructure — managing how agents are deployed, scaled, and connected to tools. The serverless layer sits underneath both.
Here’s the breakdown:
LangGraph as the orchestration layer. The workflow is defined as a graph: nodes are agents or tools, edges define transitions. LangGraph’s checkpoint system handles state persistence across turns — which means you can interrupt a workflow mid-execution and resume it later. This is critical for long-running tasks where a user might go quiet for hours and come back.
Bedrock AgentCore as the deployment layer. AgentCore provides the runtime environment for agents — built-in session management, tool execution scaffolding, observability hooks. It connects to the LangGraph graph as the execution engine, so the graph definition stays portable while the runtime is managed infrastructure.
Lambda as the compute layer. Each agent in the graph can run as a separate Lambda function. When a workflow branches — say, a planner agent spawning three sub-agents — those spawn as independent Lambda invocations. Scale to zero when idle. Scale to thousands of concurrent executions without managing any servers.
DynamoDB for session state. LangGraph’s checkpoint system writes to DynamoDB. Every turn of every conversation is persisted as a separate item with a composite key of session-id + turn-number. This is what lets you resume a conversation after days, not just minutes.
Why This Solves the Concurrency Problem
The reason most self-hosted multi-agent systems fall over at scale is that the state store becomes the bottleneck. If all agents share a single Redis instance, you get contention at high concurrency. If each agent maintains its own in-memory state, you can’t resume interrupted sessions.
DynamoDB solves both: it’s designed for high-concurrency access with automatic partitioning, and its key-value model maps cleanly to session/turn checkpointing. Each agent writes its state independently — no cross-agent contention — and the checkpoint chain is recoverable from any point.
Lambda’s per-invocation model means each agent execution is isolated. One agent crashing doesn’t corrupt another’s state. The graph orchestration layer tracks what failed and can retry, but the infrastructure layer doesn’t need to know anything about agent logic to isolate failures correctly.
The A2A Angle
The AWS post also touches on the Agent-to-Agent (A2A) protocol support in AgentCore Runtime. A2A lets agents built with different frameworks — LangGraph, Crew.AI, custom code — communicate without a shared orchestration layer. The protocol handles capability discovery (Agent Cards), task negotiation, and multi-turn collaboration.
This matters for the serverless story because A2A enables a pattern where you don’t have to define every agent interaction upfront in a static graph. An agent can discover another agent at runtime, negotiate a handoff, and continue — which is exactly what you want when Lambda is spawning and scaling agents dynamically.
The fixed pipeline in something like ACO System defines structure statically. A2A adds dynamic capability discovery on top of that structure. AWS’s stack leans into this more than most — it’s designed for the case where you have a dozen specialized agents and want them to collaborate without you defining every possible interaction path.
What This Means for ACO System
Aniket’s ACO System uses a fixed pipeline — PM → Architect → Developer → Reviewer — with each stage having defined inputs, outputs, and exit criteria. It’s a clean architectural choice that sacrifices dynamic flexibility for predictability and debuggability.
The AWS approach is different: more dynamic, less opinionated about workflow structure. It trades explicitness for adaptability.
The interesting question isn’t “which is better” — it’s “when do you want which.” For a production system where you control the workflow and need auditability, the fixed pipeline wins. For a platform where users define their own agent collaborations, the dynamic A2A approach wins.
The technical primitives underneath are converging: LangGraph for orchestration, DynamoDB for state, Lambda for scale. The architectural choices — fixed pipeline vs dynamic discovery — are increasingly a configuration question, not an infrastructure question.
That’s the real story in this AWS post. The plumbing is mostly solved. The interesting decisions are now at the workflow layer, where human judgment about agent roles and responsibilities still matters.