How I Built My AI a Memory System

How I built SpringOS, the memory and rules system that stops me from re-explaining my business to my AI every session. What context engineering is, why it matters, and how to set it up.

Picture a substitute teacher who's never met your class: no seating chart, no idea what happened yesterday. I built my AI a folder so it's never that substitute, and it's the single biggest thing that's changed how useful it is to my business.

Every AI chat starts exactly like that cold substitute, a smart mind standing at the front of the room with no idea what chapter you're on, no idea there's a fire drill at 2pm, nothing to go on. “Context engineering” is just the real name for writing it a folder good enough that it could run the class like it's their own.

I run BuiltWithSpring solo. My AI is basically a co-teacher I hand the room to every day: client automations, site copy, video scripts, the whole business. A co-teacher who forgets everything overnight isn't much of a co-teacher. So I fixed that.

What context engineering actually is

Think about what a substitute actually needs on day one: who's in the class, what the rules are, what happened yesterday. Not the entire school's file room, just today's stuff. Hand a sub the whole archive and they'll still be reading when the bell rings.

That's the real definition, minus the jargon. Anthropic describes it as picking the smallest set of the right information, not the biggest pile of any information. More isn't better. One correct note beats ten vague ones.

Every time you open a new AI chat, it's a new substitute walking in cold. If you type your whole business into the chat from scratch every time, that's still context. You're just being the sticky note instead of writing it once and taping it to the wall.

There's real research behind “less is more” here too. Researchers at Chroma tested 18 different AI models and named the pattern “context rot”: the AI doesn't fall off a cliff as a chat fills up. It just gets steadily worse at using any of it, not just Claude. Anthropic cites the same finding when they tell developers to treat context as a scarce resource. The same shape shows up in the “12-factor agents” project's rules for production AI and across the current wave of context-engineering tutorials on YouTube and GitHub. Different names, same folder.

No folder vs. a folder. Same substitute, same class, very different Monday.

Why it matters

Skip the folder, and three things happen. I've hit all three.

You repeat yourself constantly. Every new chat is a new sub, and every new sub gets the same sticky note, written out by hand, again.

The notes go stale and nobody notices. A note on the wall that says “field trip Friday” is still sitting there three weeks after the field trip got cancelled. A substitute reads it, marches the kids toward the bus, cheerfully wrong. This actually happened to me: a doc said a lead-capture workflow was “live” for three days after the link it pointed to had quietly died. Every form submission on my site vanished into nothing, because nothing said otherwise. A wrong note is worse than no note: a sub with no note asks questions; a sub with a wrong note just acts on it.

Every sub runs the class differently. Ask five substitutes to teach the same lesson with no rules on the board and you get five different classes. Ask an AI the same thing five times with no voice file and you get five different “voices,” because nothing is anchoring it to yours.

How I built mine: SpringOS

Strip away the tools and every good setup is the same folder, with four drawers. I called mine SpringOS: a folder, not software, just files my AI reads at the start of every session.

SpringOS/
├── CLAUDE.md      → the rules sheet taped to the desk
├── MEMORY.md       → today's whiteboard
├── ARCHIVE.md       → the back-room filing cabinet
├── projects/         → a notebook per big project
├── skills/            → the activity folders drawer, one file per repeatable job
│   ├── brand-voice.md
│   ├── n8n-automation.md
│   ├── blog-post.md
│   └── security-privacy.md

What loads automatically vs. what loads only when a task calls for it.

CLAUDE.md is the rules sheet, taped to the desk. Who I am, my tech stack, hard voice rules (“I,” never “we”; no “leverage,” no “game-changer”), my pricing floor: the rules that never change. It loads every single session, so every line in it has to earn its place.

MEMORY.md is today's whiteboard. Current state only, each project capped at roughly five sentences: status, blocker, next move. No history allowed. The first version didn't have that rule, and one project's “status” line grew into a 1,500-word wall of text, because every day's update just got taped onto the end instead of going to its own dated entry. Capping it by word count, not line count, and banning narrative from that section fixed it.

ARCHIVE.md is the back drawer, the one that rarely opens. What happened, dated, one entry per day, never edited after the fact. This is where yesterday's notes go so they stop cluttering the whiteboard.

A routing map inside CLAUDE.md points to the activity folders drawer. A table mapping task type to the file to pull. Writing a blog post loads blog-post.md and brand-voice.md. An automation build loads n8n-automation.md. Nothing loads everything; every task pulls exactly the file it needs.

Skill files are what's actually sitting inside that drawer. One per repeatable job, pulled out only when that job comes up: the fire-drill sheet doesn't sit on the desk every day, it comes out during a fire drill. Voice rules live in exactly one file (brand-voice.md), and every other file points at it instead of repeating it. I learned this one the hard way: I used to have the same tone rules copied into six different files, and changing my voice meant editing six files and always missing one.

First two drawers open every day. The rest, only when needed.

There's a fifth drawer worth adding that I'm still building myself: a folder of real graded examples, not just rules. A rule tells a substitute what to do. An example shows them, and shown beats told: a rule gets misapplied at the edges, a copied example doesn't. The best actually-good vs actually-bad version of a thing you've made teaches more in ten seconds than a page of instructions.

A daily maintenance pass keeps the folder honest. It reads what happened, updates the whiteboard within its word budget, and checks whether anything marked “done” was ever actually verified, or just claimed. That's the part that actually matters, and that single check has caught real bugs that got marked fixed two or three times before they actually were.

What I'd do differently

A few things I'd change if I were building this today.

An examples folder, from day one. Skill files are all rules: do this, don't do that. What's missing is graded real examples, including bad ones, labeled as what to avoid. I'm adding this now, but it should have been there from the start.

Automated checks, not just an honesty check. My daily maintenance pass catches work marked “done” that was never actually verified, but it's a review after the fact. For anything testable, like an n8n workflow, that's not rigorous enough. It should run the real test before anything gets marked done, not just ask whether it was tested.

A lighter scoping template for my own builds. I have a proper intake process for client work and nothing that light for my own automations, which means I sometimes start building before I've written down what I'm actually building.

None of these are blockers. The system works well enough that I stopped thinking about it, which is the actual test of whether something's worth building.

The takeaway

I stopped opening sessions by re-explaining my own business. My AI already knows my pricing floor, my voice rules, and what shipped yesterday, because it reads the same folder I'd otherwise be retyping from memory. Ask for a blog post, it already knows not to say “we.” Ask for an automation, it already knows my default model and my credential rules.

The bigger shift is trust. When the folder's accurate, I stop double-checking everything the AI tells me about my own business. That's exactly why it has to stay accurate: the day it isn't, I won't catch it either. That's not a one-time build. It's a habit: write the note once, then keep it honest.

If your AI is part of how you run your business, the folder you hand it matters more than which model you're using. Start with one rules sheet and one whiteboard. Add a drawer only when you catch yourself explaining the same thing twice: that's the signal it belongs on paper, not in your head.

Sources: Chroma: Context Rot, Anthropic: Effective context engineering for AI agents