--- title: AI That Remembers (2) — Don't Cram All the Rules Into One File url: https://oosioo.com/en/p/%EA%B8%B0%EC%96%B5%ED%95%98%EB%8A%94-ai-2-%EA%B7%9C%EC%B9%99%EC%9D%84-%ED%95%9C-%ED%8C%8C%EC%9D%BC%EC%97%90-%EB%AA%B0%EC%95%84%EB%84%A3%EC%A7%80-%EC%95%8A%EB%8A%94%EB%8B%A4 date: 2026-09-18T14:07:38+00:00 author: SYSOP summary: One method stuffs every rule into a single file; the other breaks them into small pieces and pulls them out only when needed. That difference in storage philosophy decides the outcome across many projects. --- # AI That Remembers (2) — Don't Cram All the Rules Into One File In the previous piece, I said rules shouldn't be lumped into one file — they should be split by project, or by task. Now it's worth actually examining why, and looking closely at how the two approaches differ. The two methods rest on different ideas of what "storing" means, and that difference can widen far more than expected once you're doing real work. ## Two approaches The first approach loads everything, always. You write everything down in a single rules file, and every time the AI starts a task, it reads that file from start to finish. The advantage is clear: nothing gets missed. Whatever's written in the file is applied every single time, without exception. If you only have one project to handle and the rules are short, this is the safest and simplest option. The second approach reads things only when needed. Rules and information are broken into small pieces and stored separately, and normally only an index of those pieces is scanned. Then, if a piece turns out to be relevant to the task at hand, only that piece gets opened and read. Everything else stays in storage but goes unread unless you're actually working on the project it belongs to. ## Why the retrieval approach wins across multiple tasks The key point is that there's a limit to how much information an AI can hold at once. This is commonly called the "context window." It's similar to the width of a person's desk. No matter how wide the desk is, it isn't infinite — and if you pile it with documents you're not using right now, there's less room to spread out the ones you actually need. The always-load-everything approach fills this desk with irrelevant stacks of paper as the number of projects grows. Say you're managing an online store today, but marketing rules, data analysis rules, and product page writing rules are all sitting on the desk as well. The AI spends its desk space reading through all of it every single time, and in the process, the actual store-management rules end up buried among the rest. The approach that reads project information only when needed works differently. Normally, the only thing sitting on the desk is a single sheet listing where each document is kept. When you start today's store-management project, you pull only the documents related to that project out of the drawer, from that list, and lay them out. The desk stays wide open, and only what's relevant to the current task is in front of you. Whether there are five projects or fifty, under this approach the only thing normally on the desk is that one list. No matter how much stored memory accumulates, the amount read each time doesn't grow by much. That's exactly why the per-project retrieval method has an edge for anyone juggling multiple pieces of work. ## What this actually looks like The structure is simpler than it sounds. It consists of two parts. - Index: a list, written one line per entry, of what memories exist. This alone is what gets read all the time. - Memory fragments: small files, each holding one piece of factual content. These only get opened when the index judges them relevant. ![Diagram showing that normally only the single-page index is read, and only the payment fragment is opened when working on payment tasks](/uploads/20dfe8f76c2aa3d0.webp =720) A single line in the index looks something like this. > Online store payment module: summary of external PG integration rules and exception handling This one line does exactly one job: it lets the AI conclude, "Ah, this is a payment-related task, so let's open this fragment." That's why a line in the index doesn't need to contain the full content. It just needs to tell you precisely when to pull it out. The actual content lives in a separate, small file. Something like this. > Online store payments are handled through an external PG. On payment failure, retry up to 3 times; beyond that, hand off to manual user guidance. Refunds are only executed after admin approval. Normally, only that one line in the index is visible, and this fragment only gets opened once you're actually working on something payment-related. ## Summary The always-load-everything, lay-it-all-out-on-the-desk approach isn't wrong. When you're focused on a single project, it's still the simplest and safest option. But the moment your work multiplies across several projects, that same simplicity turns into a massive burden. The next piece will cover how to split up these memory fragments and how to write them so they can actually be retrieved properly later. Storing things well is far easier — and far less important — than storing them so they can be found.