5.5 Persistent State & Multi-Agent Coordination

5.5 Persistent State & Multi-Agent Coordination

External State Persistence with Amazon DynamoDB

For enterprise architectures requiring full auditing, external CRM integration, or strict transactional guarantees, developers persist state externally using Amazon DynamoDB.

                                  ┌───────────────────────────┐
                                  │   Client / Web Portal     │
                                  └─────────────┬─────────────┘
                                                │
                       1. Authenticate & Lookup │ 2. InvokeAgent(sessionId,
                          Customer Profile      │    sessionAttributes={...})
                                                ▼
┌───────────────────────────┐     ┌───────────────────────────┐
│      Amazon DynamoDB      │<───>│   API Gateway / Backend   │
│ (Customer Profiles, State,│     └─────────────┬─────────────┘
│  Transaction Audit Log)   │                   │
└───────────────────────────┘                   ▼
                                  ┌───────────────────────────┐
                                  │   Amazon Bedrock Agent    │
                                  │  (Orchestrates Actions)   │
                                  └───────────────────────────┘

Hydration Pattern

1. Session Initialization: When a user logs in, the backend microservice queries Amazon DynamoDB using the user's primary key (PK=USER#12345).
2. Attribute Hydration: The backend injects essential profile metadata (e.g., accountType, region, creditTier) into the sessionAttributes of the first InvokeAgent call.
3. Transactional Mutations: During agent execution, action group Lambda functions update the DynamoDB table directly to record transactions, maintaining an external, auditable single source of truth.

---

Multi-Agent Collaboration Patterns

In large enterprises, building a single "super-agent" with 30 action groups and 10 knowledge bases leads to severe operational degradation: the foundation model struggles to select the correct tool from a massive OpenAPI prompt, latency increases, and team-level domain separation is impossible. Production systems adopt Multi-Agent Collaboration.

1. Supervisor / Router Agent Pattern

The Supervisor Agent pattern consists of a lead agent that faces the user, analyzes incoming intent, and delegates tasks to specialized sub-agents (collaborator agents):

• Supervisor (Router) Agent: Holds no direct database tools. Its instructions focus entirely on intent classification, conversational routing, and synthesizing sub-agent outputs.
• Collaborator Agent A (HR Specialist): Equipped with leave request tools and employee benefit Knowledge Bases.
• Collaborator Agent B (IT Helpdesk Specialist): Equipped with device management Lambda functions and network diagnostic tools.
• Collaborator Agent C (Corporate Travel Specialist): Equipped with flight booking and hotel reservation action groups.

                             ┌─────────────────────────────┐
                             │          End User           │
                             └──────────────┬──────────────┘
                                            │
                                            ▼
                             ┌─────────────────────────────┐
                             │   Supervisor Router Agent   │
                             └──────┬───────┬───────┬──────┘
                                    │       │       │
            ┌───────────────────────┘       │       └───────────────────────┐
            ▼                               ▼                               ▼
┌───────────────────────┐       ┌───────────────────────┐       ┌───────────────────────┐
│      HR Specialist    │       │     IT Helpdesk       │       │    Travel Specialist  │
│       Agent           │       │        Agent          │       │         Agent         │
├───────────────────────┤       ├───────────────────────┤       ├───────────────────────┤
│ • Leave Action Group  │       │ • Device Action Group │       │ • Flight Action Group │
│ • HR Policy KB        │       │ • IT Troubleshooting  │       │ • Hotel Action Group  │
└───────────────────────┘       └───────────────────────┘       └───────────────────────┘

2. Sequential Multi-Agent Pipeline

In a sequential pipeline, agents execute in a predefined relay where the output of one agent serves as the input to the next:

• Research Agent: Scours Bedrock Knowledge Bases and summarizes market reports.
• Drafting Agent: Formulates a detailed technical proposal based on the research.
• Compliance Reviewer Agent: Evaluates the draft against regulatory guardrails and approves or flags violations.

3. Native Multi-Agent Collaboration in Amazon Bedrock

Amazon Bedrock provides native support for multi-agent collaboration. Developers define an agent and add other Bedrock agents directly as Collaborator Agents within its configuration. The supervisor agent automatically receives the descriptions and capabilities of its collaborators, delegating sub-tasks autonomously without requiring custom glue code or intermediate API Gateway routing.

---

Exam Scenarios & Common Architectural Traps

Real-World Exam Scenario

An insurance provider is designing a claims assistant. When an authorized policyholder begins a session, the system must maintain their claimId throughout a 20-minute conversation. However, for a single sensitive turn where the user verifies their identity with a one-time SMS passcode, the passcode must be provided to the authentication Lambda function but must never remain in conversational memory or be accessible in subsequent turns.

Diagnosis & Resolution: The developer should pass the claimId in sessionAttributes so it persists across all turns for the duration of the session. The one-time SMS passcode should be passed strictly in promptSessionAttributes, ensuring it is available only for that specific turn's authentication check and is instantly purged upon turn completion.

Common Architectural Traps

• Trap 1: Passing Complex Nested JSON in Session Attributes Without Stringification: sessionAttributes only accepts key-value pairs where both keys and values are strings (map<string, string>). Passing a nested object without calling json.dumps() causes an API serialization validation error.
• Trap 2: Building Monolithic Multi-Domain Agents: Adding tools for HR, IT, Finance, and Legal into a single agent exhausts prompt token limits and severely degrades tool parameter selection accuracy. The Supervisor Multi-Agent pattern must be used instead.
• Trap 3: Relying on Idle Session TTL for Permanent Data: Assuming Bedrock's native session storage will retain user data indefinitely. After 30 minutes of idle inactivity, session data is deleted. Long-term business state must always be persisted in DynamoDB or external databases.

Strands, Agent Squad, and MCP

The current blueprint explicitly includes Strands Agents, AWS Agent Squad, and Model Context Protocol (MCP). Strands provides an agent-development approach for model, tool, and loop composition. AWS Agent Squad is an example of coordinating specialized agents. These frameworks do not remove the need for a deterministic application boundary: define which agent owns a task, what evidence is handed off, how conflicts are resolved, and when the workflow stops.

MCP standardizes how a client discovers and invokes server capabilities. A lightweight stateless server can be implemented behind Lambda-oriented HTTP patterns; more complex or long-running tools can use container services such as ECS or AgentCore Runtime. Current AgentCore documentation supports streamable HTTP and both stateless and stateful MCP modes. Validate tool schemas, authenticate clients, authorize each operation, constrain egress, cap time and recursion, and treat all tool output as untrusted input to the model.