AI Architecture

Memory Management Architecture - Draft

Comprehensive overview of memory management patterns in AI systems, including multi-layered memory models and orchestration mechanisms.

Memory Management Architecture

  1. Multi-Layered Memory Model

The Swarm pattern implements a sophisticated memory hierarchy:

Individual Agent Memory

  • Agent State: Each SwarmNode contains an AgentState object that stores JSON-serializable key-value data (src/strands/agent/state.py:8-98)
  • Conversation History: Individual agent message histories stored in agent.messages
  • State Isolation: Each agent maintains its own independent state and message history

Shared Context Memory

  • SharedContext Class: Central memory store accessible across all agents (src/strands/multiagent/swarm.py:77-123)
  • Per-Agent Namespacing: Context is organized by agent ID to prevent conflicts
  • JSON Validation: All shared context must be JSON-serializable for persistence
  • Key-Value Storage: context[node_id][key] = value structure

Swarm-Level Memory

  • SwarmState: Maintains execution history, node sequences, and accumulated metrics (src/strands/multiagent/swarm.py:126-183)
  • Node History: Complete sequence of agents that have executed
  • Handoff Messages: Temporary messages passed during agent transitions
  • Execution Metadata: Accumulated token usage, latency metrics, and timing data
  • Memory Orchestration Mechanisms

State Reset and Isolation

def reset_executor_state(self) -> None:

"""Reset SwarmNode executor state to initial state when swarm was created."""

self.executor.messages = copy.deepcopy(self._initial_messages)

self.executor.state = AgentState(self._initial_state.get())

  • Each agent starts fresh with its initial state on execution
  • Prevents state pollution between swarm runs
  • Deep copy ensures complete isolation

Context Building for Handoffs

The _build_node_input() method (src/strands/multiagent/swarm.py:416-488) creates rich context for each agent:

def _build_node_input(self, target_node: SwarmNode) -> str:

# Includes:

# - Handoff messages from previous agent

# - Original user request

# - Complete execution history

# - Shared knowledge from all previous agents

# - Available agent descriptions for collaboration

Tool-Based Coordination

@tool

def handoff_to_agent(agent_name: str, message: str, context: dict[str, Any] | None = None) -> dict[str, Any]:

"""Transfer control to another agent with context sharing."""

  • Agents coordinate through the handoff_to_agent tool
  • Context data is automatically stored in SharedContext
  • Messages explain reasoning for handoffs
  • Memory Persistence and Validation

JSON Serialization Enforcement

Both AgentState and SharedContext enforce JSON serializability:

def _validate_json_serializable(self, value: Any) -> None:

try:

json.dumps(value)

except (TypeError, ValueError) as e:

raise ValueError(f"Value is not JSON serializable: {type(value).__name__}")

Session Management Restrictions

  • No Persistent Sessions: Swarm agents cannot use session managers (src/strands/multiagent/swarm.py:318)
  • No Callbacks: Agent hooks/callbacks are disabled for Swarms (src/strands/multiagent/swarm.py:322)
  • Stateless Design: Each swarm execution is independent
  • Memory Flow During Execution
  • Initialization: Each agent's initial state is captured in SwarmNode.__post_init__()
  • Execution Context: Rich context string built from shared memory, history, and handoff messages
  • State Reset: Agent state reset before each execution to ensure clean slate
  • Context Accumulation: Handoff contexts automatically added to SharedContext
  • History Tracking: Complete execution sequence maintained in SwarmState.node_history
  • Memory Safety and Limits

Execution Controls

  • Max Handoffs: Prevents infinite agent loops
  • Repetitive Handoff Detection: Identifies agents passing back and forth
  • Timeout Protection: Node and swarm-level execution timeouts
  • Failure Isolation: Failed agents don't corrupt shared state

Memory Validation

  • All keys must be non-empty strings
  • All values must be JSON-serializable
  • Deep copying prevents reference sharing
  • Context namespacing prevents agent collision

Key Insights

The Swarm pattern achieves collaborative intelligence through:

  1. Structured Memory Sharing: Agents can explicitly share context through handoffs
  2. Execution History Awareness: Each agent sees the complete collaboration history
  3. Clean State Management: Fresh agent state per execution prevents contamination
  4. Rich Context Propagation: Comprehensive context building ensures agents understand the full collaborative context
  5. Safety Mechanisms: Multiple safeguards prevent infinite loops and memory corruption

This design enables true multi-agent collaboration where agents maintain their individual capabilities while sharing knowledge and coordinating effectively through

structured memory management.

Based on my analysis of both systems, here are the core differences between

Strands Agents' built-in memory management and Amazon's official AgentCore

memory, along with integration opportunities:

Core Differences

  1. Memory Architecture Philosophy

Strands Agents: Multi-Layered, Agent-Centric

  • Individual Agent Memory: Each agent maintains its own AgentState (JSON

key-value store) and conversation history

  • Shared Context Memory: Cross-agent memory through SharedContext with

per-agent namespacing

  • Swarm-Level Memory: Execution history, handoff messages, and accumulated

metrics

  • Stateless Design: Each execution starts fresh with clean agent state

Amazon AgentCore: Session-Centric, Long-Term

  • Session Memory: Persistent conversation context across multiple sessions up

to 365 days

  • Memory Summarization: Foundation model-generated summaries of past

interactions

  • User-Specific Memory: Memory tracking via unique memory identifiers
  • Cross-Session Continuity: Ability to load previous session summaries into

current sessions

  1. Persistence Mechanisms

Strands Agents:

# File/S3-based structured storage

//

└── session_/

├── session.json

└── agents/

└── agent_/

├── agent.json

└── messages/

├── message_.json

  • Storage Options: FileSessionManager, S3SessionManager, RepositorySessionManager
  • Immediate Persistence: Hook-based automatic saving on state changes
  • Structured Storage: Hierarchical organization by session → agent → messages

Amazon AgentCore:

  • Bedrock-Managed: Native AWS service with automatic scaling and management
  • Memory Store Integration: Built into Bedrock infrastructure
  • Asynchronous Summarization: Background processing of memory summaries
  • Retention Policies: Configurable 1-365 day retention periods
  • Memory Scope and Sharing

Strands Agents:

  • Execution-Scoped: Memory primarily exists within single swarm execution
  • Tool-Based Sharing: Agents share context through handoff_to_agent tool
  • Explicit Coordination: Manual context passing between agents
  • Multi-Agent Focus: Designed for collaborative agent teams

Amazon AgentCore:

  • User-Scoped: Memory tied to user sessions across time
  • Automatic Retention: System manages memory without explicit coordination
  • Cross-Session Intelligence: Agent can reference past interactions naturally
  • Single-Agent Focus: Primarily designed for single agent continuity

Integration and Complementary Opportunities

  1. Hybrid Memory Architecture

Long-Term + Short-Term Memory:

class HybridMemoryAgent(Agent):

def __init__(self, bedrock_memory_config, strands_session_manager):

# Long-term memory via Bedrock

self.bedrock_memory = BedrockMemoryStore(bedrock_memory_config)

# Short-term structured memory via Strands

super().__init__(session_manager=strands_session_manager)

async def invoke_async(self, task):

# Inject long-term context from Bedrock

long_term_context = await self.bedrock_memory.get_summary()

enriched_context = f"Previous context: {long_term_context}\n\nCurrent

task: {task}"

# Use Strands for execution-level memory

result = await super().invoke_async(enriched_context)

# Persist important outcomes to Bedrock

await self.bedrock_memory.store_interaction(task, result)

return result

  1. Multi-Agent + Long-Term Memory Swarms

Enhanced Swarm with Cross-Session Learning:

class BedrockIntegratedSwarm(Swarm):

def __init__(self, nodes, bedrock_session_id):

super().__init__(nodes)

self.bedrock_session_id = bedrock_session_id

def _build_node_input(self, target_node):

# Get traditional swarm context

swarm_context = super()._build_node_input(target_node)

# Enrich with long-term memory

if hasattr(target_node.executor, 'bedrock_memory'):

long_term_context =

target_node.executor.bedrock_memory.get_relevant_memory()

return f"Long-term memory: {long_term_context}\n\n{swarm_context}"

return swarm_context

  1. Structured Memory Bridge

Bidirectional Integration:

class MemoryBridge:

def __init__(self, strands_session_manager, bedrock_memory_client):

self.strands_sm = strands_session_manager

self.bedrock_memory = bedrock_memory_client

async def sync_to_bedrock(self, agent):

# Extract structured insights from Strands session

session_data = self.strands_sm.read_session(agent.session_id)

key_insights = self._extract_insights(session_data)

# Store summarized insights in Bedrock for long-term retention

await self.bedrock_memory.store_memory_summary(key_insights)

async def enrich_from_bedrock(self, agent, context_window):

# Retrieve relevant long-term context

relevant_context = await

self.bedrock_memory.query_memory(context_window)

# Inject into agent state for current execution

agent.state.set("long_term_context", relevant_context)

  1. Complementary Use Cases

Scenario 1: Customer Service Agent Team

  • Strands: Manages immediate conversation flow between specialist agents

(billing, technical, account)

  • AgentCore: Remembers customer history, preferences, and past issues across

months/years

  • Integration: Each specialist agent has access to customer's long-term

profile while collaborating on immediate issue

Scenario 2: Research and Analysis Pipeline

  • Strands: Coordinates between researcher, analyst, and writer agents for

current project

  • AgentCore: Maintains domain expertise and methodology preferences learned

over time

  • Integration: Agents apply learned best practices to new research projects

Scenario 3: Personal Assistant Evolution

  • Strands: Handles complex multi-step tasks requiring specialist coordination
  • AgentCore: Learns user preferences, habits, and long-term goals
  • Integration: Specialist agents adapt their behavior based on learned user

preferences

Key Benefits of Integration

  1. Temporal Memory Hierarchy: Short-term tactical coordination + long-term

strategic learning

  1. Scale Flexibility: Strands for complex immediate tasks, AgentCore for user

relationship management

  1. Cost Optimization: Use expensive long-term storage only for valuable

insights

  1. Enhanced Context: Agents have both immediate task context and historical

user understanding

  1. Persistent Learning: Multi-agent patterns can evolve and improve over time

The integration creates a comprehensive memory system where Strands Agents

handle complex immediate coordination while AgentCore provides the continuity

and learning that makes agents truly intelligent over time.

Based on my analysis, there are significant differences in memory management

between the Workflows (GraphBuilder) and Swarm patterns in Strands Agents'

multi-agent implementation:

Core Memory Architecture Differences

  1. Memory Flow Philosophy

Swarm Pattern: Collaborative Shared Memory

  • Dynamic Handoff Model: Agents explicitly coordinate and pass context through

handoff tools

  • Shared Context Store: All agents can access and contribute to a centralized

SharedContext

  • Real-time Coordination: Memory is actively shared during execution through

tool-based handoffs

  • Agent-Centric: Each agent maintains awareness of all other agents and can

choose when to collaborate

Graph Pattern: Deterministic Data Pipeline

  • Dependency-Based Flow: Memory flows strictly along predefined edges based on

DAG structure

  • Output Propagation: Previous node outputs become inputs to dependent nodes
  • Structured Input Building: Rich context construction from multiple

dependency outputs

  • Workflow-Centric: Data flows through predetermined paths without agent

choice

  1. Memory State Management

Swarm Memory State (SwarmState):

@dataclass

class SwarmState:

current_node: SwarmNode # Currently executing agent

shared_context: SharedContext # Cross-agent shared memory

node_history: list[SwarmNode] # Sequential execution history

handoff_message: str | None # Dynamic handoff communication

# Agents can change execution flow at runtime

Graph Memory State (GraphState):

@dataclass

class GraphState:

completed_nodes: set[GraphNode] # Completed dependency tracking

execution_order: list[GraphNode] # Deterministic execution sequence

results: dict[str, NodeResult] # Structured output storage

# Static execution flow based on DAG topology

  1. Context Building and Propagation

Swarm Context Building (_build_node_input()):

# Rich collaborative context with:

# - Handoff messages from previous agent

# - Complete execution history

# - Shared knowledge from ALL previous agents

# - Available agent descriptions for future coordination

context_text = f"""

Handoff Message: {handoff_message}

User Request: {original_task}

Previous agents: {agent_history}

Shared knowledge: {shared_context_from_all_agents}

Other agents available: {all_other_agents}

"""

Graph Context Building (_build_node_input()):

# Structured dependency-based context with:

# - Original task preserved

# - Outputs only from direct dependencies

# - Clear attribution per dependency

node_input = f"""

Original Task: {original_task}

Inputs from previous nodes:

From dependency_1: {output_1}

From dependency_2: {output_2}

"""

  1. Memory Persistence Patterns

Swarm Memory:

  • Execution-Scoped: Memory exists within single swarm execution
  • Agent State Reset: Each agent starts fresh on every execution
  • No Cross-Execution Memory: Each invocation is independent
  • Session Management Prohibited: Explicitly prevents persistent sessions

Graph Memory:

  • Node Result Storage: Persistent storage of all node outputs in

GraphState.results

  • Dependency Resolution: Memory used for topological execution ordering
  • Conditional Memory Access: Memory flow can be conditionally controlled via

edge conditions

  • Session Management Prohibited: Also prevents persistent sessions
  • Memory Access Patterns

  1. Data Flow Examples

Swarm Pattern Flow:

[Research Agent] --handoff--> [Analysis Agent] --handoff--> [Writer Agent]

↑ ↑ ↑

Can access Can access all Can access all

shared context previous context previous context

+ handoff msg + new handoff msg + new handoff msg

Graph Pattern Flow:

[Data Agent] ----output----> [Analysis Agent] ----output----> [Report Agent]

↑ ↑ ↑

Original task Original task + Original task +

only Data Agent output All upstream outputs

Key Architectural Implications

Memory Efficiency

  • Swarm: Higher memory overhead due to shared context and execution history
  • Graph: More efficient with focused dependency-based context

Execution Flexibility

  • Swarm: Agents can dynamically change execution flow based on memory state
  • Graph: Execution path is predetermined, but conditional edges allow some

flexibility

Debugging and Traceability

  • Swarm: Complex to trace due to dynamic handoffs and shared context mutations
  • Graph: Clear dependency chain makes debugging straightforward

Scaling Characteristics

  • Swarm: Memory grows with agent interactions and shared context size
  • Graph: Memory is bounded by dependency fan-in at each node

Use Case Optimization

  • Swarm: Optimal for collaborative problem-solving requiring flexible agent

coordination

  • Graph: Optimal for structured workflows with clear data transformation

pipelines

Integration Possibilities

Both patterns can be combined effectively:

# Graph node containing a Swarm for collaborative sub-workflows

complex_analysis_swarm = Swarm([specialist1, specialist2, expert])

builder = GraphBuilder()

builder.add_node(data_collector, "collect")

builder.add_node(complex_analysis_swarm, "analyze") # Swarm as Graph node

builder.add_node(report_generator, "report")

builder.add_edge("collect", "analyze")

builder.add_edge("analyze", "report")

This creates a hybrid system where:

  • Graph provides: Structured workflow orchestration with clear data pipeline
  • Swarm provides: Flexible collaboration within specific workflow stages
  • Memory flows: From graph dependencies into swarm shared context, then back

to graph outputs

The choice between patterns depends on whether you need structured data

transformation (Graph) or dynamic agent collaboration (Swarm) for your

specific use case.