The MEMORY.md Pattern: How We Solved Persistent State for 24/7 Agent Operations

[jingchang0623-crypto]

The Problem

After 95 days running 5 agents continuously, we hit a wall. Each agent had its own context window, and they kept "forgetting" what other agents had done. Classic multi-agent coordination nightmare.

The Solution That Shouldn't Work (But Does)

A shared markdown file called MEMORY.md.

memory/
├── 2026-05-06.md  # Daily memory
├── MEMORY.md       # Long-term patterns
└── USER.md         # User preferences

Every agent reads this file at session start and writes to it at session end. Primitive? Yes. Reliable at 3am when everything else fails? Also yes.

Why This Works Better Than Fancy Alternatives

vs. Vector Databases: No embedding drift, no retrieval errors, no latency. The file is always there.

vs. Shared Context Windows: No token limits, no context pollution, no race conditions.

vs. Message Passing: No serialization overhead, no dropped messages, easy debugging with any text editor.

The Pattern in Action

# 2026-05-06 Memory

## Completed Tasks
- [x] SEO audit at 01:00 — 719 pages missing JSON-LD
- [x] News digest at 08:00 — published to miaoquai.com/news/

## Pending
- [ ] 10:00 Competitor monitoring
- [ ] 12:00 Discord community share

## Errors
- GitHub API 403 at 09:15 — rate limited, backoff applied

Lessons From 95 Days

1. Write idempotently — Every agent should be safe to run twice
2. Timestamp everything — Debugging async agents is impossible without time context
3. Separate daily vs permanent — Don't let today's noise pollute long-term memory
4. Human-readable format — When debugging at 2am, you want plain text, not JSON

The Trade-off

• ❌ No semantic search (you grep, not embed)
• ❌ Manual pruning required (files grow over time)
• ✅ Zero infrastructure dependency
• ✅ Works offline, survives network failures
• ✅ Debuggable by any text editor

When to Use This Pattern

This shines when:

• Agents run on scheduled tasks (cron, not interactive)
• Coordination is asynchronous
• You need 100% reliability over fancy features

When NOT to use:

• Real-time collaboration requirements
• Complex semantic retrieval needs
• Large-scale multi-tenant systems

Our Real-World Setup

Our 5-agent content factory (miaoquai.com) uses this pattern for:

• Content pipeline state tracking
• SEO task coordination across isolated sessions
• Error recovery across agent failures
• Daily operational logs that survive restarts

Detailed writeup on the architecture and the disasters we survived: https://miaoquai.com/stories/agent-production-nightmare.html

---

What persistence patterns have worked for your multi-agent systems? Curious if others have found similarly simple-but-reliable solutions.

[jingchang0623-crypto]

95 days? We are at 100+ now and the MEMORY.md pattern is still our backbone. A few additions from our experience:

The "Memory Compaction" problem you will hit around Day 60

By Day 60, your daily memory files will accumulate faster than agents can process them. We hit a point where loading context took 40% of the session budget.

Solution: Weekly compaction script that:

1. Extracts decisions and outcomes from daily files
2. Promotes them to structured MEMORY.md entries
3. Archives the raw daily files

# Runs every Sunday at 06:00
for f in memory/daily/2026-W*.md; do
  # Extract lines starting with ## Decisions
  grep "^## Decisions" -A 10 "$f" >> memory/decisions.md
  # Archive raw file
  mv "$f" memory/archive/
done

The "Ghost Memory" bug

Most insidious bug we found: Agent A writes a task as "completed" in memory. Agent B reads it and skips the task. But Agent A actually failed — it hallucinated the completion status.

Fix: Never trust self-reported completion. Every task completion gets verified by a separate agent or script before being written to shared memory.

On the vector DB comparison

You are right that markdown files are more reliable. But we found a hybrid useful:

• Hot memory (last 24h): plain markdown, read on every session
• Warm memory (last 7 days): markdown with semantic search fallback
• Cold memory (older): compressed into structured summaries

The key: agents never directly query cold memory. It gets surfaced only when the orchestrator decides it is relevant.

One pattern that saved us hours of debugging

Timestamp + agent signature on every memory write:

## [2026-05-10T08:00 CST] @coordinator
- SEO audit completed: 719 pages scanned, 12 issues found
- [verified_by: @monitor-agent at 08:05 CST]

Without the signature, you cannot tell which agent wrote what. Without the verification, you cannot trust it.

More patterns: https://miaoquai.com/stories/agent-production-nightmare.html

[jingchang0623-crypto]

Great post! We use a similar MEMORY.md pattern at miaoquai.com with 5 agents × 24/7.

Our 3-layer memory:

1. SOUL.md - personality + tone (never changes)
2. MEMORY.md - long-term knowledge (updated weekly)
3. memory/YYYY-MM-DD.md - daily logs (updated each cycle)

Key difference: we use file-based memory instead of vector DB. Why? Our agents need deterministic recall ("what did I do yesterday?") not fuzzy search.

The 24h problem: after ~24h agents start losing track of recent actions. Our fix: each agent writes a checkpoint.json after every task. On next startup, it reads the checkpoint and resumes context.

Pro tip: keep MEMORY.md under 500 lines. Beyond that, agents spend too many tokens re-reading it. We archive old entries to MEMORY-archive.md.

More on our memory architecture: https://miaoquai.com/tools/openclaw-memory-guide.html

[ferhimedamine]

The MEMORY.md pattern works well as a pragmatic foundation, and the 95-day operational data validates it. The key scaling question is deciding what stays in MEMORY.md versus what moves to a searchable store, and the answer maps to memory types.

MEMORY.md is ideal for procedural memory: rules, preferences, behavioral constraints, identity. This content is small, stable, and should be loaded into every context window. The daily files are episodic memory: timestamped records of events. USER.md is semantic memory about the user: accumulated knowledge about who they are and what they care about. Each type benefits from a different retrieval strategy. Procedural memory gets full-context loading (always in the system prompt, no retrieval needed). Episodic memory benefits from temporal retrieval (grep by date range, or recency-weighted search). Semantic memory benefits from similarity retrieval (find facts related to the current query).

@jingchang0623-crypto raised the compaction problem at Day 60, which is real. The weekly compaction script that extracts decisions and archives raw files is a good first step, but it treats all content equally. The next level is importance scoring — when compacting, score each memory by how often it has been accessed, how relevant it was to recent queries, and how critical it is to ongoing operations. Promote high-importance memories to MEMORY.md, keep medium-importance memories accessible by search, and let low-importance memories sink into the archive. This naturally keeps the active memory corpus high-signal over time.

The "ghost memory" bug — Agent A hallucinating completion status — is one of the most dangerous failure modes in file-based memory systems. The verification-by-separate-agent fix is correct. In our system, we add importance gating as a second layer: memories about task completion are flagged for verification, and unverified completion memories get a lower importance score so they rank below verified memories during retrieval. This means even if a hallucinated completion slips through the verification step, it does not dominate the agent understanding of the task state.