| name | agent-memory |
| description | Agent memory and context management: design persistent memory systems, manage context windows, implement summarization strategies, and build stateful agents that learn across sessions |
Agent Memory & Context Management Skill
When to activate
- Building agents that need to remember information across conversation turns
- Designing systems that must work within LLM context window limits (100K-200K tokens)
- Implementing long-term memory (vector stores, structured databases) for agents
- Building multi-session agents that accumulate knowledge over time
- When agent responses degrade due to context overflow or information loss
- Designing memory hierarchies (working memory, episodic, semantic, procedural)
When NOT to use
- Stateless one-shot completions where no memory is needed
- Simple chatbots without domain-specific persistence requirements
- When the conversation fits entirely within the context window with room to spare
- Single-turn question-answering without session continuity
Instructions
1. Memory Architecture Design
Choose the appropriate memory type for each information category:
| Memory Type | Analogy | Use Case | Implementation |
|---|
| Working Memory | Short-term RAM | Current conversation context | Context window (system prompt + messages) |
| Episodic Memory | Personal experiences | Past interactions, decisions made | Vector store with timestamps |
| Semantic Memory | Facts & knowledge | Domain knowledge, user preferences | Structured DB or knowledge graph |
| Procedural Memory | Skills & habits | Learned workflows, tool patterns | Fine-tuning or prompt templates |
2. Context Window Management
Strategies for staying within token limits:
Prioritization (when context is full):
- System instructions (never evict)
- Current task context (never evict)
- Recent conversation turns (compress older turns)
- Retrieved memory (summarize or re-retrieve)
- Tool results (keep only relevant outputs)
Compression techniques:
- Summarization: Replace N old messages with 1 summary message
- Selective inclusion: Only include relevant turns based on current query
- Rolling window: Keep last K turns + summary of everything before
- Semantic retrieval: Instead of full history, retrieve relevant past interactions
3. Memory Read/Write Patterns
async def store_memory(agent_id: str, interaction: dict):
"""Store important information from an interaction."""
facts = extract_facts(interaction)
for fact in facts:
await semantic_memory.upsert(
agent_id=agent_id,
content=fact.text,
metadata={
"type": fact.type,
"source": "conversation",
"timestamp": datetime.now(),
"confidence": fact.confidence,
}
)
async def recall_memories(agent_id: str, query: str, top_k: int = 10):
"""Retrieve relevant memories for the current query."""
episodic = await episodic_memory.search(query, top_k=5)
semantic = await semantic_memory.search(query, top_k=5)
combined = rank_memories(episodic + semantic, query)
return combined[:top_k]
4. Summarization Strategies
Progressive summarization (best for long conversations):
Turn 1-10: Full messages in context
Turn 11-50: Summary of turns 1-10 + full turns 11-50
Turn 51-100: Summary of turns 1-50 + full turns 51-100
Turn 101+: Summary of summaries + full recent turns
Topic-based summarization:
- Group past messages by topic
- Summarize each topic independently
- Include topic summaries as structured context
5. Memory Consistency & Conflicts
Handle contradictory information:
- Timestamp precedence: Newer information overrides older
- Confidence scoring: Higher confidence facts persist
- Explicit contradiction detection: Flag conflicts, ask user to clarify
- Version tracking: Keep history of changing facts (user preferences evolve)
6. Memory Persistence Patterns
File-based (simple):
{
"preferences": {"language": "en", "style": "concise"},
"decisions": [
{"date": "2026-06-13", "topic": "auth", "decision": "JWT over sessions"}
],
"knowledge": ["project uses FastAPI", "deployed on AWS ECS"]
}
Vector store (scalable):
- Embed all memories with metadata
- Retrieve top-K relevant memories per query
- Decay old, unused memories over time
Knowledge graph (structured):
- Entity → relationship → entity triples
- Query by entity (all facts about user X) or relationship (all decisions about auth)
7. Context Budget Allocation
For a 200K token context window:
System prompt: ~2K tokens (1%)
Agent instructions: ~3K tokens (1.5%)
Retrieved memories: ~5K tokens (2.5%)
Tool descriptions: ~5K tokens (2.5%)
Current task context: ~10K tokens (5%)
Conversation history: ~170K tokens (85%)
Response generation: ~5K tokens (2.5%)
Adjust based on use case:
- Memory-heavy agents: Increase memory allocation, reduce history
- Conversation-heavy: Increase history, reduce memory
- Tool-heavy: Increase tool descriptions, use summarization for history
Example
Building a customer support agent with memory:
memory_config:
working_memory:
type: context_window
max_tokens: 8000
strategy: rolling_window
keep_recent: 20
episodic_memory:
type: vector_store
provider: pinecone
embedding: text-embedding-3-small
store:
- past_tickets
- resolution_steps
- customer_feedback
retrieval:
top_k: 5
min_similarity: 0.75
rerank: true
semantic_memory:
type: structured_db
provider: postgresql
store:
- customer_preferences
- product_knowledge
- agent_decisions
update_policy: upsert_on_conflict
memory_operations:
on_turn_complete:
Anti-Patterns
- Memory bloat: Storing every detail without pruning → retrieval noise
- Stale memory: Not updating facts when they change → incorrect responses
- Context stuffing: Filling context with low-relevance memories → degraded performance
- No summarization: Keeping full history until context overflow → abrupt information loss
- Over-reliance on memory: Retrieving memories for simple queries that don't need them → latency and cost