Chapter 9
The Memory System
Letting the Agent remember you across conversations
🎯
Like Your Personal Notebook
Imagine you have an assistant who gets amnesia every morning. You have to re-explain your preferences, project context, and work habits every single day. Now give them a notebook where they can write down important things — the next day, they just flip it open and know everything. That's the Agent's memory system.
The LLM's "Amnesia" Problem
Large language models have a fundamental limitation: every new conversation starts from scratch. They don't remember what you told them yesterday, don't know your preferences, and have no context about your project.
This means you might need to repeatedly explain:
• What tech stack your project uses
• What coding style you prefer
• What bug was fixed in the last conversation
• Your role and work priorities
The memory system exists to solve this problem.
OpenHarness's Memory Mechanism
OpenHarness uses a file-based memory system with these core components:
📄 MEMORY.md
The memory index file that lists all memory entries with titles and links. It's loaded into context at the start of every conversation.
📁 Memory Directory
Each memory entry is stored as an independent Markdown file, organized by topic.
The design is elegant: MEMORY.md serves as an index that's always in context, so the Agent quickly knows what memories are available. When needed, it reads the specific files.
Four Types of Memory
OpenHarness defines four memory types:
👤 User Memory
Information about the user: role, preferences, expertise level, etc.
Example: "User is a senior Go developer but new to React"
💬 Feedback Memory
User corrections and confirmations of Agent behavior.
Example: "Don't summarize at the end of every response"
📋 Project Memory
Project-related information: goals, deadlines, special agreements.
Example: "Code freeze starts March 5th"
🔗 Reference Memory
Locations of external resources.
Example: "Bug tracking is in the Linear INGEST project"
What a Memory Entry Looks Like
memory/feedback_testing.md
1---2name: Testing preferences3description: User's preferences on testing approach4type: feedback5---67Integration tests must use a real database, no mocks.89**Why:** Last quarter, mocked tests all passed but the real10database migration failed, causing a production incident.1112**How to apply:** All database-related tests should use13a test database instance, no mocking whatsoever.
Memory Lifecycle
1. Create: The Agent writes a memory file when it discovers information worth remembering
2. Index: The memory entry is added to the MEMORY.md index
3. Load: MEMORY.md is loaded into context at the start of every new conversation
4. Use: The Agent adjusts its behavior based on memories
5. Update: If information becomes outdated, the Agent updates or deletes the memory
Importantly, the Agent verifies that memories are still accurate before acting on them. Memories can become stale, so the Agent cross-references them with the current code state.
📌 Key Takeaway
Files = Persistence, Index = Efficient Access
OpenHarness's memory system is elegantly designed: simple Markdown files store memories (easy to read, easy to edit), and MEMORY.md serves as the index (quick lookup). No database needed, no complex vector store — the file system is the best persistence solution.
🧠 Check Your Understanding
What is MEMORY.md's role in the memory system?