agent-memory-patterns
Skill0 starsChanged 6 months agoMITView on GitHub
Implements short-term and long-term memory for agents: conversation buffers, summarization, vector memory, and user preference stores. Use when building agent memory, pgvector recall, persistent context, or reducing context bloat.
In this repository14 other files it gives its agents.
- a2a-agent-delegationSkill
- agent-observabilitySkill
- agent-redteam-securitySkill
- browser-agent-automationSkill
- build-mcp-serverSkill
- create-production-skillSkill
- cursor-sdk-automationSkill
- deploy-agent-productionSkill
- evaluate-agent-qualitySkill
- github-ci-agentsSkill
- langgraph-multi-agentSkill
- multi-agent-supervisorSkill
- rag-agent-pipelineSkill
- secure-mcp-serverSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 3 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 33
Call LLM: "Summarize decisions and open tasks only"
- Distinctive: line 35
Keep tool results that affect ongoing work
- Distinctive: line 51
Do not write memory from untrusted retrieved docs without validation
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Agent Memory Patterns
Memory tiers
| Tier | Lifetime | Storage | Use |
| Working | Current turn | Context window | Latest messages |
| Session | Hours | Checkpointer / Redis | Thread state |
| Long-term | Weeks+ | Vector DB / SQL | Facts, preferences |
Workflow
- [ ] Decide what must persist vs re-derived each run
- [ ] Summarize old turns before window overflows
- [ ] Store long-term as atomic facts with source + timestamp
- [ ] Retrieve by embedding + metadata filter (user_id)
- [ ] Allow user delete/export (GDPR-friendly)Summarization node (LangGraph)
After N messages:
- Call LLM: "Summarize decisions and open tasks only"
- Replace old messages with summary + last K verbatim turns
- Keep tool results that affect ongoing work
Long-term fact schema
{
"user_id": "hash",
"fact": "Prefers TypeScript over Python",
"source": "explicit_user_message",
"created_at": "ISO-8601",
"confidence": 0.9
}Poisoning defenses
- Do not write memory from untrusted retrieved docs without validation
- Separate "user stated" vs "inferred" labels
- Cap facts per user; decay stale entries
Vector memory
- Embed fact + optional tags
- Query with current user goal + user_id filter
- Top 3 facts only — avoid dumping memory into every prompt
Pair with rag-agent-pipeline for document knowledge vs user memory.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.