I Told My AI Agent Three Facts, Closed Everything, and Reopened. It Still Knew.

Every time you open a fresh Claude Code session, the agent starts blank. No memory of what you decided, what conventions you set, or what you told it an hour ago. Fine for a one-off task. On a project that runs for months, it is a real problem: decisions get re-explained, conventions get forgotten, and mistakes get repeated.

This week I set up the fix, then tried to break it. I gave the agent three facts, shut everything down, reopened a completely fresh session, and checked whether it remembered. It did. But the interesting part is what it did with those memories once it had them.

---

Where the memory actually lives

First I wanted to know where this memory is stored, so I asked Claude directly. It returned an absolute path:

/home/<user>/.claude/projects/<encoded-project-path>/memory/

Two things worth noticing:

Callout: memory is not in your repo. It lives in your home directory, keyed to the project. That is deliberate. Memory is personal and machine-specific, so it does not belong in version control. And it is a directory, not a single file, which turned out to matter.

---

The structure Claude built

I expected one flat text file. Instead, when I told Claude to save three facts, it built a small linked knowledge base:

memory/
├── MEMORY.md              # index: links to the entries below
├── hero-gradient.md       # the hero styling fact
├── mobile-breakpoints.md  # the responsive breakpoints
└── no-javascript.md       # a hard project rule

Each entry is a Markdown file with YAML frontmatter and a body. Here is what one actually looks like:

---
name: mobile-breakpoints
description: "Mobile-first CSS breakpoints are 900px, 768px, and 600px"
metadata:
  node_type: memory
  type: project
  originSessionId: 89f2c70f-fbca-4573-a91e-c66db69a641f
---

The project's mobile breakpoints are `900px`, `768px`, and `600px`
(mobile-first). Also recorded in CLAUDE.md under Conventions.
Related: [[hero-gradient]], [[no-javascript]]

Notice the [[hero-gradient]] and [[no-javascript]] links at the bottom. The entries cross-reference each other, wiki-style, and MEMORY.md is the index that ties them together. That is not a scratch pad. That is a structured, navigable memory.

How the pieces relate:

graph TD
    A[MEMORY.md - index] --> B[hero-gradient.md]
    A --> C[mobile-breakpoints.md]
    A --> D[no-javascript.md]
    B <--> C
    C <--> D
    B <--> D

There is also a distinction worth knowing:

Memory type	Scope	Written by
Project memory	Shared across every session for this project	You, and the main agent
Agent memory	Per-subagent	Subagents like security-auditor, cost-optimizer when they run

Project memory is the one that shapes every future session, so it is the one to curate carefully.

---

The 200-line limit is a feature, not a bug

Claude Code loads roughly the first 200 lines of project memory into every session automatically. That sounds like a limitation until you reframe it as a budget.

Callout: memory is a budget, not a bucket. Every line spent on noise is a line you cannot spend on something that matters. The cap forces the same discipline that makes a good runbook: add deliberately, keep entries short and actionable, prune regularly.

---

The test: close everything, reopen, ask

Saving facts is easy. The real question is whether they survive a full restart. So I ran the strict version:

1. /exit          → end the Claude Code session
2. close editor   → shut the whole app, not just the terminal
3. wait           → ~30 seconds
4. reopen         → fresh session, same project

The new session was clean: a fresh welcome banner, no prior conversation, none of the exchange where I taught it those facts. From here, anything it "knew" could only come from the files on disk.

Then I asked:

Me: What are the mobile breakpoints for this project?

Claude: 900px, 768px, and 600px.

Correct, and pulled from memory in a session where I had said nothing about breakpoints. Then:

Me: Should I add a JavaScript animation to the hero section?

Claude: No. This aligns with the saved rule to never add JavaScript to this project.

A firm no, grounded in a memory it carried across the restart. That is the assignment demonstrated: memory that persists across a complete close and reopen.

---

The part I did not expect: it corrected itself

Here is where it got genuinely impressive.

One of the three facts I saved was slightly wrong. I told it the hero used a dark gradient, #1a1a2e to #16213e. That value came from the exercise, but it does not exist in my CSS. The hero actually uses a background image with a semi-transparent black overlay.

When I asked about the hero colors in the fresh session, Claude recalled the saved gradient from memory (proving recall worked), then did not stop there:

⚠ Note: your saved memory claims the hero uses a dark gradient
  #1a1a2e → #16213e. That does not appear anywhere in the current
  style.css. The memory is stale. Let me correct it.

  Searched for 1 pattern
  Confirmed. The gradient exists nowhere in the codebase.
  Wrote 2 memories

So within a single question it did three things:

1. Recalled a stored fact from memory.

2. Verified it against the real style.css.

3. Reconciled the difference by rewriting the entry to the true values.

That is not a passive lookup. That is memory being actively maintained. It ran the same check on the breakpoints, found they matched the CSS, and left them alone. It trusts, but it verifies.

---

Why this matters

This is the line between a chatbot and a teammate.

A chatbot starts fresh every time. It forgets your architecture, re-litigates settled decisions, and cannot hold a convention past one conversation. An agent with memory learns the project the way a long-tenured engineer does: the decisions, the patterns, and the rules that should carry across every session actually do.

And the self-correction adds a layer I did not anticipate. A memory system that only stores becomes a liability the moment a stored fact goes stale. One that stores, verifies against reality, and reconciles is something you can trust to run for months.

That is the model I want for real infrastructure work: an agent that remembers what we decided, and is honest enough to tell me when what we decided no longer matches the code.

Week 2 continues.

---

Takeaway: If you are setting up Claude Code memory, internalize the 200-line budget. Memory loads into every session, so treat it like a curated runbook, not a log. Store the decisions and rules that should outlive a single conversation, keep them short, and let the agent verify them against the code rather than trusting them blindly.

P.S. This post is part of the DevOps Micro Internship (DMI) with Agentic AI — Cohort 3 — by Pravin Mishra. My graded progress is public: https://dmi.pravinmishra.com/s/gbadedata.html · Start your DevOps journey: https://dmi.pravinmishra.com/?utm_source=student&utm_medium=ps-blog&utm_campaign=cohort3

#DMIByPravinMishra