ai-context-infrastructure
Why I Treat My AI Context Like Infrastructure
I spent months using Claude wrong.
Not wrong in a way that produced bad results — I was getting answers, writing drafts, summarizing documents. It worked. But I was using it like a search engine: open a session, ask something, close it. Every conversation started from zero. Every session began with five minutes of re-explaining who I am, what I’m working on, and what I’ve already tried.
I was getting responses. I wasn’t getting leverage.
The shift came when I stopped thinking about AI as a tool I pick up and put down, and started thinking about it as a system I maintain. That reframe changed everything about how I work with it — and this article is about the architecture I built as a result.
$ man llm_memory
The Core Problem: AI Is Stateless by Design
Large language models have no persistent memory between sessions. Every conversation is a blank slate. The model doesn’t remember you, your projects, your preferences, or your decisions. This isn’t a bug — it’s how the technology works. But it creates a fundamental problem for anyone trying to use AI for serious, ongoing work.
Most people solve this with repetition. They re-explain. They paste in context at the start of each session. It works, but it doesn’t compound. Every session is roughly as productive as the first one. You’re not building anything — you’re running in place.
What you want is for each session to build on the last. For context to accumulate. For the AI to know your work better in month three than it did in week one. That requires externalizing your state — taking what would otherwise live only inside the conversation and writing it into files that persist.
That’s the architectural insight. Everything else follows from it.
$ tree workspace/
The Two-Level Context Model
The system I settled on has two levels.
workspace/
├── CLAUDE.md <-- Level 1: permanent brain
│ (who you are, your prefs, all active projects)
└── projects/
└── vendor-review/
└── CLAUDE.md <-- Level 2: loaded on demand
(everything specific to this project)
The first level is your workspace context — a single file that answers the question “who is this person and what are they working on?” It holds your role, your working style, your communication preferences, your active projects, and the people you work with regularly. Claude reads it at the start of every session, automatically, before you say a word.
The second level is project context — a separate file for each active initiative. It holds everything specific to that project: the goal, the key decisions made, the current status, the stakeholders, the next step. This file is loaded on demand, when you mention the project. It doesn’t live in the workspace file — it’s linked from it.
The separation matters. When you’re running four or five concurrent projects, a single monolithic context file becomes unmanageable. Things get buried. The AI misses things at the bottom. The two-level model keeps each context clean: the workspace file stays lean — a routing table, essentially — and the project files carry the depth without cluttering the permanent layer.
$ file CLAUDE.md
Why Plain Text
I could have used a notes app. A wiki. A project management tool with an API. I chose plain text files — specifically Markdown — and it wasn’t a default. It was a deliberate architectural decision.
Plain text survives tool changes. No proprietary format. No account required. No sync service to maintain. When I move from one AI platform to another — and that will happen, probably more than once — my context files travel with me unchanged. They’re readable by any text editor and by any AI model. The investment doesn’t depreciate.
Plain text version-controls cleanly. I can track every change to my context files, diff them, roll them back. That matters when you’re maintaining files that evolve over months.
And critically: AI models are optimized for text. A well-structured Markdown file with clear headings and concise entries gives the model exactly what it needs to retrieve the right information quickly. Fancy formatting doesn’t help here. Structure does.
The choice of plain text isn’t about simplicity. It’s about durability. The files you write today should still be readable — by you and by whatever AI you’re using — in five years.
This portability extends beyond tool changes. The same CLAUDE.md file works across every Claude interface. Whether you’re in Cowork on your desktop, running Claude Code from the terminal, or accessing Claude through the API, the context file loads the same way. You write your context once. It follows you everywhere you use Claude — no reformatting, no duplication, no per-tool maintenance.
$ git log –oneline context/
The Save Workflow: Compound Interest for Knowledge Work
Here’s the math most people miss.
Without a save workflow, none of that happens. Session ends, context disappears, next session starts from your original file. Lessons learned? Gone. Decisions? Gone. Updated project status? Gone.
The save workflow I use works like this: at the end of each session, I say “save.” Claude creates a session summary file — a plain-language record of what was discussed, what was decided, and what comes next. It updates the NEXT ACTION field at the top of my workspace file. It logs meaningful changes to the project changelog. Then it generates a handoff script — a paste-ready message I can use to start the next session exactly where I left off, even if days pass in between.
The session summary is what makes compact recovery work. When a long session gets compressed and Claude’s memory of earlier exchanges becomes approximate, the most recent session file is what I point it to. “Read this, confirm current state, then wait.” Recovery takes sixty seconds instead of ten minutes.
The right analogy is a savings account. The return looks small at first. By month three, you’re working with an AI that has detailed knowledge of your projects, your working style, your key stakeholders, and the decisions you’ve already made. That’s not the model getting smarter. That’s your context file getting richer.
$ cat runbook.md
Skill Files: Behavioral SOPs for Your AI
This is the piece most people building with AI miss entirely.
You can encode behavioral protocols directly into your workspace — step-by-step procedures that Claude follows when triggered by a specific phrase. I have two active ones.
Active trigger phrases
- “New project” — Runs a guided setup wizard. Claude asks about the goal, stakeholders, deadline, and what success looks like. At the end, the project folder exists, the context file is populated, and the pointer is added to the workspace file. No manual file creation. No forgotten fields.
- “Catch me up” — Runs a state-recovery protocol. Claude reads the workspace file and the most recent session file, presents a current-state brief, and waits for confirmation before doing anything. Use after a compact, after a break, or any time you want to verify Claude’s working model before a complex task.
These aren’t prompts I type from scratch each time. They’re standing procedures I wrote once and invoke with two words. The discipline is the same as any other runbook — you don’t improvise the process, you follow the procedure. Skill files let you apply that discipline to your AI workflow. The behavior is consistent, repeatable, and doesn’t depend on remembering the right incantation.
$ diff yesterday/ today/
What This Looks Like in Practice
I came back to a complex vendor review after a week away. New session, blank slate — Claude had no memory of where we’d left off.
I pasted the handoff script from my last session. Claude read the project file and the session summary, and in one sentence told me the current state: draft risk summary is 80% complete, waiting on one outstanding questionnaire response, first review scheduled for the following week. It asked for confirmation before doing anything.
Thirty seconds. No re-explaining. No reconstructing context from memory or email threads. I confirmed, gave it the outstanding response I’d received while I was away, and we finished the draft in forty minutes.
That’s what a well-maintained context system buys you. Not magic — just information that was captured when it was fresh, stored where the AI can find it, and retrieved when it’s needed.
$ exit
The Real Unlock
Most people who use AI heavily eventually hit the same ceiling. The model is capable — it can write, analyze, draft, summarize, reason. The bottleneck isn’t the AI. It’s the context.
What you give the model to work with determines what you get back. A session that starts with rich, current, well-organized context produces work that’s immediately useful. A session that starts from zero produces work you have to reshape.
Building a context system is infrastructure work. It takes an afternoon to set up and a discipline to maintain. It’s not glamorous. But it’s the thing that separates using AI from leveraging it — and the gap between those two things is larger than most people realize until they’ve been on both sides of it.
The timing matters more than it might seem. Context systems compound. A session you run today without capturing anything is a session that doesn’t build on tomorrow’s. The people building this infrastructure layer now will be working with a materially different AI than colleagues who are still re-explaining every session six months from now. That gap is already opening. It just isn’t obvious until you’ve been on the right side of it.
