The AI's Memory

A Foundation Model, by default, is "Stateless." It doesn't remember who you are or what you said two minutes ago. For an agent to be truly useful—especially in a professional context—it must have Memory.

In this lesson, we will explore the three types of agent memory and how to implement them on AWS using Amazon Bedrock and Amazon DynamoDB.

---

1. The Memory Hierarchy

As a Professional Developer, you must manage three distinct layers of context:

Layer 1: Short-term Memory (Working Memory)

• What: The current conversation history (the last 5-10 turns).
• AWS Implementation: Bedrock sessionId. Bedrock handles this automatically if you pass the same session ID in your API calls.

Layer 2: Long-term Memory (Personal History)

• What: Facts about the user that persist across days or weeks (e.g., "User prefers Python over Java").
• AWS Implementation: Amazon DynamoDB. You store user attributes and preferences in a table, and "Inject" them into the agent's system prompt at the start of a session.

Layer 3: Factual Memory (Knowledge)

• What: Specialized data (e.g., "Company Policy v2").
• AWS Implementation: Knowledge Bases for Bedrock (RAG).

---

2. Managing the Context Window

As a conversation grows longer, the "Context Window" of the model fills up. This leads to two problems:

1. High Costs: You are paying for thousands of tokens of history on every turn.
2. Performance Degradation: The model "forgets" the middle of the conversation or gets confused by old, irrelevant data.

The Pro Strategy: "Summary Memory"

Instead of sending the whole chat history, use a "Summarizer" model to periodically condense the last 20 turns into a 3-paragraph summary.

• The Prompt: "Below is the summary of the conversation so far: [SUMMARY]. Now, respond to the user's latest message: [QUERY]."

---

3. Session State in Bedrock Agents

When using Amazon Bedrock Agents, you can pass a sessionState object. This allows you to store specialized variables that the agent can access but the user cannot see.

{
  "sessionAttributes": {
    "user_tier": "Platinum",
    "region": "us-east-1"
  },
  "promptSessionAttributes": {
    "current_discount_code": "AI_PRO_20"
  }
}

---

4. Federated Memory: Connecting the dots

graph TD
    U[User Query] --> A[Agent]
    A -->|Get Preferences| DB[(DynamoDB)]
    A -->|Get Knowledge| KB[Knowledge Base]
    A -->|Get Chat Stats| CA[CloudWatch]
    
    DB --> A
    KB --> A
    CA --> A
    
    A -->|Final Response| User[User]

---

5. Security of Memory

Memory is inherently sensitive. If your agent "Remembers" a user's password or social security number, it is now an attack vector.

• Privacy Rule: Never store PII (Personally Identifiable Information) in your long-term memory store (DynamoDB) without encryption.
• Filtering: Use Bedrock Guardrails to scan the memory before it is injected back into a new prompt.

---

6. Code Example: Retrieving Long-term Memory

import boto3

db = boto3.resource('dynamodb')
table = db.Table('UserAIPreferences')

def get_agent_memory(user_id):
    # Fetch long-term memory from DynamoDB
    response = table.get_item(Key={'userId': user_id})
    preferences = response.get('Item', {}).get('preferences', "No preferences found.")
    
    # Inject into the system prompt context
    system_prompt = f"User Preferences: {preferences}. Be a helpful assistant."
    return system_prompt

---

Knowledge Check: Test Your Memory Knowledge

---

Summary

Memory transforms an AI from a "Stranger" into a "Partner." By combining Short-term session history, Long-term DynamoDB storage, and RAG-based knowledge, you build a truly intelligent agent.

This concludes Module 16. We move next to Module 17: Multi-Region and Global Architectures.

---

Next Module: The Global Guard: Designing for High Availability Across Regions