5.4 Agent Memory, Session State & Multi-Agent Collaboration Patterns

5.4 Agent Memory, Session State & Multi-Agent Collaboration Patterns

As enterprise generative AI applications mature, single-agent architectures and stateless request models quickly encounter scaling bottlenecks. Complex customer journeys require memory systems that can retain context across days or weeks without exceeding foundation model context windows. Furthermore, attempting to combine dozens of disparate enterprise capabilities into a single monolithic agent degrades tool-selection accuracy. This section explores memory management within Amazon Bedrock Agents—contrasting short-term attributes with managed long-term episodic memory—and examines multi-agent collaboration patterns for enterprise systems.

---

The Memory Hierarchy in Generative AI Agents

Language models are inherently stateless: every inference request is evaluated in isolation. To create coherent, multi-turn conversational agents, systems maintain state across an architectural hierarchy:

                               ┌────────────────────────────────────────────────────────┐
                               │             Agent Memory Architecture                  │
                               └───────────────────────────┬────────────────────────────┘
                                                           │
                    ┌──────────────────────────────────────┴──────────────────────────────────────┐
                    ▼                                                                            ▼
     ┌─────────────────────────────┐                                              ┌─────────────────────────────┐
     │      Short-Term Memory      │                                              │      Long-Term Memory       │
     └──────────────┬──────────────┘                                              └──────────────┬──────────────┘
                    │                                                                            │
         ┌──────────┴──────────┐                                                      ┌──────────┴──────────┐
         ▼                     ▼                                                      ▼                     ▼
┌─────────────────┐   ┌─────────────────┐                                    ┌─────────────────┐   ┌─────────────────┐
│ Working Context │   │Session / Prompt │                                    │ Bedrock Managed │   │ External Store  │
│ (Sliding Window │   │   Attributes    │                                    │ Episodic Memory │   │(Amazon DynamoDB)│
│ in Scratchpad)  │   │  (Key-Value)    │                                    │ (Summarization) │   │ (Profiles & KB) │
└─────────────────┘   └─────────────────┘                                    └─────────────────┘   └─────────────────┘

---

Short-Term Memory: Session Attributes vs. Prompt Session Attributes

Amazon Bedrock Agents provide two native key-value state mechanisms passed via the sessionState object in InvokeAgent requests and Lambda event/response payloads:

1. Session Attributes (sessionAttributes)

• Scope & Lifecycle: Persist across the entire conversation under a specific sessionId for the duration of the idle session TTL (default 30 minutes).
• Data Structure: A string-to-string key-value map (map<string, string>). Values must be stringified primitives or serialized JSON.
• Read/Write Behavior: Can be initialized by the client application on turn 1, read by backing Lambda functions during action group invocations, modified by Lambda responses, and retained for subsequent turns.
• Typical Use Cases: Storing authenticated user metadata (e.g., {"userId": "USR-9021", "tier": "Enterprise", "tenantId": "acme-corp"}), preferred language, or active transaction IDs.

2. Prompt Session Attributes (promptSessionAttributes)

• Scope & Lifecycle: Ephemeral and strictly scoped to a single prompt turn. Once the agent synthesizes and returns the final response for that turn, all prompt session attributes are discarded.
• Data Structure: A string-to-string key-value map (map<string, string>).
• Read/Write Behavior: Injected by the client for a specific invocation, accessible to prompt templates and Lambda functions during that turn only.
• Typical Use Cases: Supplying transient, single-request correlation IDs, temporary authorization tokens, client-side UI coordinates, or turn-specific override flags that should never persist into subsequent conversational turns.

Comparison of Native State Mechanisms

---

Bedrock Long-Term Memory (Episodic Memory Management)

While short-term session attributes maintain state within an active 30-minute window, real-world customer support and personal assistants require long-term memory spanning multiple distinct sessions over weeks or months.

The Problem with Naive History Accumulation

Simply appending all past user dialogues into the prompt context causes severe architectural failures:

• Context Window Exhaustion: Rapidly consumes the model's maximum input tokens (e.g., 200,000 tokens).
• Exponential Cost: Callers pay input token costs on every single turn for the cumulative weight of all historical conversations.
• Reasoning Degradation ("Needle-in-a-Haystack"): Models become confused or distracted when evaluating dozens of outdated, irrelevant conversational turns.

Bedrock Managed Memory Mechanics

Amazon Bedrock Agents provide native Memory Management capabilities that extract and persist episodic memory across distinct sessionId instances for a given memoryId:

1. Dialogue Summarization: When a session closes or reaches inactivity, Bedrock automatically processes the transcript using background foundation models to generate concise semantic summaries.
2. Entity & Preference Extraction: The memory system extracts key factual entities (e.g., "User prefers window seats on flights", "User operates macOS laptops", "User's child is named Leo") and stores them in structured memory blocks.
3. Selective In-Context Retrieval: When the user initiates a new session in the future, Bedrock retrieves only the relevant long-term memory blocks and injects them into the orchestration template, giving the agent persistent recall with minimal token overhead.

---

Memory security and deletion

Treat a memory identifier as an authorization-scoped reference, not proof of identity. Bind it to the authenticated tenant and user in trusted application state, validate that binding on every request, and reject caller-selected references outside that scope. Define retention, deletion, export, and correction workflows for stored summaries. A summary can preserve sensitive or incorrect information even when the original transcript is removed.

Evaluate memory with adversarial cross-user tests, stale-preference tests, and explicit forgetting requests. Record when memory influenced an action, but avoid exposing private memory in ordinary traces or collaborator payloads. Multi-agent designs must minimize what each collaborator receives and prevent a routing decision from expanding data access.