I gave a talk last week and said it out loud: delete that memory, agent. When your agent learns a lesson, do not park it in some private memory file. Make a pull request that improves the skill, so the fix helps you and everyone else who uses that skill. Someone messaged me afterward that there was probably a banger piece of content buried in the idea. So here it is. My agent's memory had quietly grown to 218 files. A 46-kilobyte index that was so big the harness had started silently dropping the back half of it every single session. I cut it to 6 files, moved those into my CLAUDE.md, and turned auto-memory off. Then I audited the CLAUDE.md they landed in. This is the whole system, because your agent's memory and your CLAUDE.md are the same problem wearing two hats: standing instructions that load every session and rot the moment you stop looking. Before I cleaned any of this up, I ran last30days on the whole topic, ten sweeps across Reddit, X, YouTube, TikTok, and Hacker News. The first thing the research told me is that I was about to argue with the entire internet. The loud advice is "build a memory system." I went the other way. Open any feed right now and the memory pitch is everywhere: 90% of people coding with AI lose hours a day to one problem nobody talks about. The agent has no memory. Every session starts from zero. It forgets your codebase, your decisions, your context. The people shipping fastest fixed this for $0. @Nyra_nx, X, 11 likes There is a whole cottage industry forming around this. "Show HN: Recall, local project memory for Claude Code" hit 136 points and 86 comments on Hacker News the same week. The instinct is understandable: the agent forgets, so bolt on a bigger brain. Here is where I want to be precise, because the instinct behind that is correct. A stateless agent that starts cold every morning is a real problem. The mistake is not wanting memory. The mistake is answering it by loading more into every session instead of letting the agent query a store on demand. Hold that distinction, I come back to it. For the always-loaded layer this article starts with, more is not the fix, and one creator said why better than I have: Hard limits on memory force an AI agent to distill what actually matters. Enforced scarcity is the mechanism that creates focused, useful long-term memory instead of bloated, useless context. aidecipher on TikTok, 8 likes That is the whole philosophy. A memory with no budget is not a brain, it is a landfill. Why a fat memory makes your agent dumber This is not a vibe, it is mechanical. Your CLAUDE.md and your memory get injected into the context window at the start of every session, and a context window that is filling up is a context window that performs worse. The most-watched explainer I found put a real number on the rule: The default behavior of Claude Code is, when you start a session, it injects the full claude.md, and that is why we want to keep the claude.md ideally under 200 lines. Simon Scrapes on YouTube, 870 likes A 472-like TikTok said the consequence in plainer language: the longer you let Claude's context clog up, the dumber it gets. My memory index was 46 kilobytes. It was so far past the limit that the harness was loading only part of it and dropping the rest, which means the file had stopped steering anything and become a work journal that happened to cost tokens. The bloat was not theoretical. Half of it already was not loading. HACKS Your memory and CLAUDE.md inject every session. Past a point, more text means worse adherence, not more knowledge. Keep each file under 200 lines. The audit: it was not 90% junk, it was 90% misfiled I had three readers go through all 218 files line by line and bucket each one. The split surprised me: About 14% was true trash: records of shipped PRs and finished videos, lessons already encoded in tooling. Git history already has all of it. About 39% was durable, useful lessons, but each one was tied to exactly one skill. A fix for a specific tool, sitting in a global memory that the tool never reads. The rest was genuinely cross-cutting steering, plus a pile of in-flight project trackers that would rot the day the work shipped. That middle bucket is the entire point. The question was never "what percentage do I delete." It was "where should each lesson live." A lesson about one skill belongs inside that skill, as a PR, where it changes behavior for everyone and gets version-controlled like the code it is. Parked in memory, it is private tribal knowledge that silently goes stale. This is the skills-over-memory idea in one sentence: stop journaling lessons, start shipping them into the skill. HACKS Bucket every memory entry: trash (git has it), skill-tied (PR it into the skill), or genuinely cross-cutting (keep). Most "memory" is a misfiled skill PR. Where the lessons actually go: write your own skills So if a skill-tied lesson does not belong in memory, where does it go? Into a skill. This is the half of skills-ove