Your AI Tools Start From Zero Every Time. They Don't Have To.

I mentor a few teams on getting real work done with AI coding agents, and the same complaint comes up more than any other. The tool is sharp, but it has no memory. Every session it starts from zero. It doesn’t remember the convention you explained yesterday, it makes the same wrong assumption it made last week, and you correct it again. After a while people decide it’s more trouble than it’s worth and go back to doing it by hand.

The frustrating part is that the fix is simple, and once you set it up the tool stops feeling like a clever intern who never learns and starts feeling like one who actually does. I’ll explain the idea quickly, then show you exactly how I wired it into Claude Code on the blog you’re reading right now.

The problem is that nothing carries over

Think about how you’d onboard a new engineer. They make a mistake, you explain the context, and they don’t make it again, because they remember. An AI agent doesn’t get that second part for free. Each session is a clean slate. Whatever it figured out last time, painfully, is gone, so you pay the same teaching cost over and over and the tool never accrues the thing that makes a person valuable on a team: knowing how things actually work here.

That’s not a model problem you have to wait on. It’s a memory problem you can solve yourself.

The loop, in one sentence

Keep a file the agent reads before it starts a task and updates when it finishes. After each run it writes down what worked, what didn’t, and the edge case that tripped it up. Next time, it reads those notes first. Run, check the result, record what you learned, repeat. Each pass starts further along than the last.

The idea is floating around the Claude community as a “learnings loop.” Here’s how I made it concrete.

Wiring it into Claude Code

Claude Code reads one file automatically at the start of every session: CLAUDE.md. That’s the hook the whole thing hangs on. Anything in there is in the agent’s context before it does a single thing, so that’s where the loop lives.

I don’t put the learnings directly in CLAUDE.md, though. I keep them in a separate learnings.md and pull it in with an import, so the memory file can grow and get rewritten without touching the project’s instructions. Claude Code supports @-imports, so the bottom of my CLAUDE.md is just:

## The learnings loop (read this first)

Before starting any task, read @learnings.md — the accumulated memory of how
this project actually works. After finishing, append any durable learning (a
gotcha, a convention, a fix that took a few tries) to learnings.md. Run
/log-learnings to consolidate. A stale entry is worse than none.

@learnings.md

That @learnings.md on its own line is the important part. It imports the file, so every session starts with the project’s hard-won notes already loaded.

What actually goes in the file

The same things you’d tell a new hire and then forget you told them. From this blog’s learnings.md, more or less verbatim:

## Build & deploy
- The `[glob-loader] Duplicate id` warning after editing a post is a benign
  stale-cache artifact. The build output is still correct. Don't chase it.
- If a change "isn't showing" on the live site, it's the browser cache, not a
  deploy bug — Cloudflare serves the HTML with max-age=0.

## Content & writing
- Do NOT manually number h2 headings. The CSS auto-numbers them, so "1. " in
  the source renders as "01 1.".
- New posts need the newest pubDate to lead the index; same-day ties need a time.

Every one of those is a mistake I (or the agent) made once. The duplicate-id warning sent me chasing a non-bug. The manual heading numbers showed up doubled on the live site. Each one is now a line in a file the agent reads before it touches a post, so it doesn’t step on the same rake twice.

The more specific and real the notes, the more the next run benefits. Vague advice (“write good posts”) does nothing. A concrete trap (“this warning is fake, ignore it”) saves an hour.

Closing the loop

Reading the file is the easy half. Getting it updated is where loops usually die, because nobody remembers to do it. You have a few options in Claude Code, from most manual to most automatic:

• Just ask. The instruction in CLAUDE.md tells the agent to append a learning when it finishes something non-obvious. This works more than you’d expect, because the instruction is in context the whole session.
• A slash command. I added a /log-learnings command (a file in .claude/commands/) that tells the agent to review the session and update the file: append what’s new, merge duplicates, delete what’s stale. Running one command at the end of a work session is a small enough habit to actually keep.
• A hook. Claude Code can run a command on certain events via settings.json. A Stop hook, for instance, fires when the agent finishes. That’s the most automatic option, though hooks run fixed commands rather than judgment calls, so I use them to remind, and leave the actual writing to the command.

I started with the first, added the second when the file got big enough to need tidying, and haven’t needed the third yet.

Treat it like a system of record, not a junk drawer

Here’s where my day job leaks in. A file like this is a small database, and like any database it rots if nobody maintains it. Left alone it grows into a pile of contradictory, stale notes — and a bad knowledge base is worse than none, because the agent will confidently act on the wrong entry.

So /log-learnings doesn’t just append. It consolidates: merge the duplicates, delete what’s no longer true, sharpen the vague lines into specific ones. The goal isn’t a longer file. It’s a file where every line still earns its place. If you’ve ever maintained a runbook, you know the discipline — the notes are only useful as long as someone keeps them honest.

It compounds

What you end up with is a tool that gets better the more you use it instead of staying flat. The first week you’re mostly writing the file. A month in, the agent starts most tasks already knowing your conventions and the traps, and the corrections you used to repeat are rare. The knowledge stops living only in the head of whoever’s been here longest and starts living somewhere the tool, and the next person, can actually read it.

That last part is the one I care about most. We spend a lot of energy worrying about whether the model is smart enough. Most days the thing holding it back isn’t intelligence. It’s that nobody gave it a way to remember. This blog’s CLAUDE.md and learnings.md are sitting in the repo doing exactly that, and writing this post was one more pass through the loop.