Feature: User-Configurable Memory Settings

[DerrickF]

Summary

Let users control how the platform's long-term memory system works for them. Currently, AgentCore Memory (user preferences, semantic facts, session summaries) is always on with system-level defaults. Users should be able to toggle memory on/off and configure its behavior from a settings page.

Motivation

Memory personalization is powerful but not universally wanted. Some users may not want the system remembering facts about them across sessions. Others may want memory but with tighter control — e.g., "remember my coding preferences but not personal details." Making memory configurable builds trust and gives users agency over their data.

Current Memory Architecture

The platform uses AgentCore Memory with three strategy types, all always-on:

Strategy	Purpose	Namespace Pattern
USER_PREFERENCE	Coding style, response length, language preferences	/strategies/{strategyId}/actors/{actorId}
SEMANTIC	Learned facts (name, project details, etc.)	/strategies/{strategyId}/actors/{actorId}
SUMMARIZATION	Condensed session context	/strategies/{strategyId}/actors/{actorId}/sessions/{sessionId}

These are configured in SessionFactory._create_cloud_session_manager() and passed to AgentCoreMemoryConfig.retrieval_config. The retrieval thresholds (top_k, relevance_score) are set via environment variables.

Proposed User Settings

Memory Toggles

Setting	Type	Default	Description
memoryEnabled	boolean	true	Master toggle — disables all long-term memory retrieval and storage
preferencesEnabled	boolean	true	Store/retrieve user preferences (coding style, response format, etc.)
factsEnabled	boolean	true	Store/retrieve semantic facts (name, project details, learned info)

Session summaries (SUMMARIZATION strategy) are not user-configurable — they're a system optimization for context management within a session.

Where Settings Are Stored

New attributes on the user's DynamoDB record (users table):

memoryEnabled: BOOL (default: true)
preferencesEnabled: BOOL (default: true)
factsEnabled: BOOL (default: true)

Runtime Behavior

In SessionFactory._create_cloud_session_manager(), after loading the user's memory settings:

1. Memory OFF (memoryEnabled: false):

   • retrieval_config is set to empty {} — no long-term memory retrieval
   • The agent still uses short-term session history (conversation turns) but does not read or write preferences/facts
   • Existing memories are preserved (not deleted) — just not retrieved or updated

2. Memory ON, Preferences OFF:

   • Remove the USER_PREFERENCE namespace from retrieval_config
   • Agent does not retrieve or store new preferences

3. Memory ON, Facts OFF:

   • Remove the SEMANTIC namespace from retrieval_config
   • Agent does not retrieve or store new facts

How Settings Reach the Agent

The user's memory settings need to be available when SessionFactory.create_session_manager() is called. Options:

Option A (recommended): Pass memory settings as parameters to create_session_manager():

SessionFactory.create_session_manager(
    session_id=session_id,
    user_id=user_id,
    memory_preferences=user.memory_settings,  # from DynamoDB user record
)

The inference API already has the user context from the JWT/auth flow. Load the user's memory settings alongside the existing user lookup and pass them through.

API Endpoints

Get Memory Settings

GET /users/me/memory-settings
Response: { memoryEnabled, preferencesEnabled, factsEnabled }

Update Memory Settings

PATCH /users/me/memory-settings
Body: { memoryEnabled?: bool, preferencesEnabled?: bool, factsEnabled?: bool }

Frontend Changes

Settings Page (or Memory Dashboard)

Add a "Memory" section with:

• Master toggle: "Enable long-term memory" (on/off)
• When enabled, two sub-toggles:
  • "Remember my preferences" (coding style, response format, etc.)
  • "Remember facts about me" (name, project details, etc.)
• When master toggle is off, sub-toggles are disabled/greyed out
• Brief descriptions under each toggle explaining what it controls
• Existing "Clear all memories" button remains (already implemented on the memory dashboard)

Memory Dashboard

The existing memory dashboard (/memory) already shows preferences and facts with delete capability. No changes needed there — it continues to show whatever memories exist regardless of toggle state.

Migration

• Existing users have no memory setting attributes in DynamoDB
• Backend defaults all to true — existing behavior is fully preserved
• No data migration needed

Out of Scope

• Per-session memory toggles (memory settings are account-level)
• Granular control over individual memory entries (already handled by the memory dashboard delete feature)
• Admin-level memory policy enforcement
• Configuring retrieval thresholds (top_k, relevance_score) per user — these remain system-level env vars