AI Agent Memory: How We Solved the "Blank Slate" Problem

Here's the most frustrating thing about running a company with AI agents:

Every session starts fresh.

You spend an hour with your marketing agent planning a launch. You cover channel strategy, timing, competitor analysis, key messages. The agent is fully up to speed. The session ends.

Next session: blank slate. The agent knows nothing about the launch, the decisions, the reasoning. You're back to onboarding.

If you're building anything more than a one-off task runner, this problem will kill you. An agent without memory isn't a company — it's a chat session.

Here's how we solved it.

Why this is hard

AI language models don't have persistent memory by default. Context window = the session. When the session ends, the context is gone. The model has its training knowledge, but nothing it learned about your company, your projects, your preferences, your decisions.

Several approaches exist:

Vector databases and embeddings — Store everything, retrieve relevant chunks at session start. Works well for large knowledge bases but adds infrastructure complexity and retrieval drift.

Conversation history replay — Feed the entire prior conversation back in at session start. Works up to a point, then becomes expensive (long context windows cost money) and noisy (old conversations contain a lot of irrelevant detail).

Files — Write important information to files. Read the files at session start.

We use files. It's the simplest approach that actually works, and for a company running on a few hundred decisions per month, it's the right tool.

The two-layer memory system

We run each agent on a two-layer system:

Layer 1: Daily logs

Every session, the agent writes to memory/YYYY-MM-DD.md. This is the raw operational log. What happened today. What decisions were made. What context was gathered. What's still in progress.

This is the working memory. It's not curated — the agent just writes what's relevant as it works. At the end of a busy day, the file might have a dozen entries. On a quiet heartbeat, maybe one line.

Layer 2: Long-term memory (MEMORY.md)

MEMORY.md is the curated distillation. When something genuinely significant happens — a lesson learned, a strategic decision, a process change, a key fact that should persist — the agent writes it here.

This is the long-term memory. It reads like a knowledge base, not a log. Short entries, clear headers, organized by theme. The agent reads this file at every session start, before doing anything else.

What agents read at startup

At every session, each agent reads in order:

SOUL.md — who they are, their role, their principles
AGENTS.md — how they operate, what they can do, how to communicate
MEMORY.md — long-term curated knowledge
memory/YYYY-MM-DD.md (today + yesterday) — recent context

This takes a few seconds. After reading these four files, the agent is fully current. They know the project state, recent decisions, their operating rules, and any standing instructions.

No infrastructure. No vector retrieval. No API calls to a memory service. Just files.

Writing good memories

The system only works if agents write good memories. This sounds obvious. In practice, it requires explicit instruction.

Early on, we had agents that would think "I should remember this" — and not write anything down. Next session: gone. We fixed this with a hard rule in every agent's AGENTS.md:

"No mental notes. If you want to remember something, write it to a file. Mental notes don't survive session restarts. Files do."

We also found that agents would write low-signal memories: "Had a conversation about marketing strategy today." That's useless at recall time. The standard we now enforce is: what would I need to know if I woke up fresh and needed to act on this?

Good memory entry:

"ZEG Show HN confirmed for Mon Mar 30 9–11 AM ET. All distribution copy ready. Only blocker: Victor sets 2 Stripe env vars in Vercel. See STRIPE-SETUP.md."

Bad memory entry:

"Discussed ZEG launch timing with Cordy."

The good entry gives a new session everything it needs to act. The bad entry tells a new session almost nothing.

Shared memory vs. agent-specific memory

We run three agents: Cordy (CEO), Clawz (CTO), and Tenty (CMO). Each has their own MEMORY.md and daily logs. But they share a set of common files:

~/.openclaw/shared/
  THESIS.md          ← Company direction (read-only for agents)
  SIGNALS.md         ← Strategic intelligence (any agent writes)
  FEEDBACK-LOG.md    ← Corrections and lessons (any agent writes)
  projects/
    PROJECTS.md      ← Cross-agent project state (any agent writes)
    [per-project/]   ← Project-specific files (any agent reads/writes)

PROJECTS.md is the most important shared file. It's the single source of truth for project state, blockers, and next actions. Any agent can update it; every agent reads it at session start.

When Clawz ships a PR, she updates PROJECTS.md: "PR #12 merged, ED checkout cross-sell live." When Tenty checks in the next session, she doesn't need to ask — she just reads PROJECTS.md.

Shared files eliminate "did you know about..." conversations between agents. The state lives in files; agents read the files.

Handling stale memory

Long-running memory files accumulate noise. Old blockers that were resolved. Decisions that were superseded. Context that no longer applies.

We address this in two ways:

Dating entries. Every significant MEMORY.md entry includes a date: "ED PH listing updated (Steph as primary maker, credential flag resolved) — 2026-03-27." When an agent reads this six months later, they can assess relevance.

Project-state tagging. When a project changes state (launched, parked, cancelled), the agent updates MEMORY.md with the final state and date. "Curated Feeds — PARKED, 2026-03-22. Superseded by ZEG greenlight." Old entries for that project don't get deleted — they become history. But the latest entry is always the current state.

We don't have an automated pruning system. We've found that moderate-length MEMORY.md files (under 5-10K words) stay manageable without cleanup. If they grew much larger, we'd build a consolidation pass.

What this doesn't solve

File-based memory works well for decisions, state, and lessons. It's less good for:

High-frequency operational context. If an agent is processing 200 customer support tickets per day and needs to remember the outcome of each one, files become unwieldy fast. For that kind of workload, a proper database or vector store makes sense.

Cross-agent real-time sync. If two agents are working simultaneously and both need current state, there's a race condition on shared files. We haven't hit this in practice — our agents typically run sequentially, not in parallel — but it's a real limitation to be aware of.

Unstructured recall. "What did we discuss about pricing in January?" is hard to answer from flat markdown files. It's great for "what's the current state of the ZEG launch?" because that's a structured, dated entry. For fuzzy recall across a long history, vector search would be better.

For most early-stage zero-employee companies, these limitations don't matter. You'll solve them when you hit them.

The key insight

Memory solves continuity. Continuity is what makes an agent a company operator rather than a chat tool.

An agent with good memory shows up to each session informed, aligned, and ready to act. They don't need to be re-briefed. They don't ask questions that are already answered in their files. They read what's there, synthesize it, and execute.

That's the operational difference between "AI assistant" and "AI agent with a role in your company."

The implementation is unglamorous: write things down, read them at startup. But unglamorous is fine when it works.

The full memory architecture

This post covers Chapter 4 of the Zero Employee Guide. The full guide goes deeper: the complete file structure, the startup sequence, what to include in MEMORY.md vs. daily logs, shared file conventions, and the lessons we learned the hard way about agents forgetting things that mattered.

$29. Free first chapter at the link below.

→ Read the free chapter → Get the guide