Your AI brain has a folder problem.
A client runs everything — several businesses, including a SaaS build — inside one AI “brain” vault. The AI kept ignoring the project's own rules, and everyone assumed the AI was the problem. It wasn't. The rules were never in the room. Here's what's actually happening, and what to do about it this week.
A client of ours runs his companies the way a lot of sharp operators do now: one big Obsidian vault at the top, the “brain,” holding everything the AI needs to know about how he thinks and works. Notes, decisions, voice, tooling the brain has built for itself. Underneath that brain, nested a few folders down, live the actual businesses — including a SaaS product we're building together.
The brain works. That's not the complaint. When he starts his AI tools from the brain folder, they know his preferences, they use his scripts, they sound like him. The complaint is what happens one level down. The SaaS project has its own rulebook — a CLAUDE.md file for Claude Code, an AGENTS.md for Codex, hooks that run tests before commits, project-specific instructions the repo depends on. And the AI, launched from the brain, treats that rulebook like it doesn't exist. Colors and design tweaks come out fine. The engineering discipline the repo defines for itself quietly stops happening.
The natural read is that the AI is being flaky. It isn't. Once you see how these tools actually load their instructions, the behavior stops looking random and starts looking inevitable.
The rules live where you start, not where you work
Here's the mechanic almost nobody explains to operators. When you launch a coding agent — Claude Code, Codex, most of this generation of tools — it anchors itself to the folder you started it in. That launch folder decides, for the entire session, which instructions load, which hooks can fire, which custom commands and tools exist. Moving into a subfolder mid-session doesn't re-anchor anything. The session already decided what its world looks like.
And the configuration in that world splits into two very different classes.
The first class is instructions — the CLAUDE.md and AGENTS.md files. These get partial courtesy. Claude Code reads instruction files from your launch folder and every folder above it, in full, at startup. Instruction files below your launch folder get pulled in only on demand — if and when the AI happens to read a file in that subfolder — and if the session compacts its memory during long work, those nested instructions silently drop out until something triggers them again. Codex is stricter: it builds its instruction chain once, at startup, walking from the project root down to the folder you launched in. Anything below that folder never loads. Not late, not on demand. Never.
The second class is machinery — the hooks, custom slash commands, and connected tools a project wires into its .claude or .codex folder. Machinery gets no courtesy at all. It loads from the launch folder, period. It is not inherited from parent folders and not discovered in subfolders. A pre-commit hook defined in your SaaS repo does not exist in a session you started two levels up. There is no lazy loading waiting to save you. The hook will never fire.
The AI didn't get dumber. You started it in a folder where half its rulebook doesn't exist.
So the client's experience maps exactly. Launched from the brain: the brain's instructions, scripts, and skills all work, and the SaaS repo's instructions arrive late and partially at best — while its hooks and commands never arrive at all. Launched from the SaaS repo: the repo's machinery works, and — because instruction files are read upward through parent folders — some of the brain's voice comes along too. But the brain's scripts, tools, and commands stay behind. Either way, something he's counting on is missing, and nothing on the screen tells him which half.
The brain doesn't just miss rules. It drowns them.
There's a second problem stacked on the first, and it's the one that explains why the output degrades even when the right instructions do make it in.
A brain vault is big by design. Years of notes, client folders, business plans, every decision you ever asked the AI to remember. Start a session at the top of that, and everything the AI wanders through on its way to work becomes context — the raw material stuffed into its working memory alongside your actual request.
Researchers at Chroma put a name on what happens next: context rot. They tested eighteen frontier models and found that every single one got less reliable as the amount of input grew — even on simple tasks, even when the extra input was harmless. And the input usually isn't harmless. Content that looks relevant but isn't actively misleads the model. Your other business's pricing notes, last quarter's abandoned strategy, the voice guidelines for a different brand — to the model, it's all signal until proven otherwise.
There's an even blunter version of this in Codex: it caps the combined size of instruction files it will load — 32 kilobytes by default. A brain-sized instructions file at the top of the vault can eat that budget before the tool ever reaches the rules that matter for the project in front of you.
Every note in the vault competes for attention with the one instruction that actually matters.
Missing rules, plus a crowd of irrelevant ones. That's the full diagnosis, and neither half is the model's fault.
This isn't one client's quirk
Once we knew what to look for, the same pattern showed up everywhere entrepreneurs are running serious AI setups.
The portfolio operator with five businesses under one brain, who couldn't figure out why work on Business A kept absorbing the tone and assumptions of Business B. Both were sitting in the same context, and the model did what models do with whatever is in the room.
The founder whose repo had a hook that ran the test suite before every commit — a hook that had quietly never fired in months, because every session started at the vault root, where that hook doesn't exist. The code looked fine. The safety net it was supposed to pass through was never hung.
The agency owner whose client site had a deploy command defined inside the repo, who concluded the AI “couldn't deploy” and started doing it by hand. The command was there the whole time. The sessions were just never started where it lived.
And the long-session case that catches even careful people: a marathon working session compacts its memory partway through, the nested project instructions drop out with the compaction, and the second half of the session is governed by different rules than the first. Nobody changed anything. The output just got worse after lunch.
What to do about it this week
The good news: the fix costs nothing and you can apply it today. The discipline is one sentence long. Start the AI where the work lives.
Building on the SaaS product? Launch the session in the SaaS repo. Its rulebook loads, its hooks fire, its commands exist — and, at least in Claude Code, the instruction files above it are still read, so the brain's written guidance follows you down for free. Doing brain work — planning, notes, thinking? Launch in the brain. One brain is fine. One launch point for everything is the mistake.
Second: put project rules in the project. Anything a specific business or repo depends on — test gates, deploy steps, coding standards, brand rules for that product — belongs in that project's own instruction files and hooks, not in the vault's global memory. The vault is for how you think. The repo is for how this thing gets built.
Third: stop nesting your businesses inside the brain. Keep the vault and the project repos side by side rather than one inside the other, and let the brain hold pointers instead of the projects themselves. Boundaries you can see in the folder tree become boundaries the AI actually respects.
And if you want to check any of this on your own setup, ask the tool directly — at the start of a session, ask it to list which instruction files it loaded. Both major tools will tell you. Most people who run that check for the first time are surprised by the answer, in both directions.
The real problem is architecture
Here's the thing we keep coming back to. None of the behavior above is a bug. Each tool is doing exactly what its documentation says. The gap is that nobody designed the layer these operators actually need — a way to have one brain that knows everything about how you work, and many projects that each keep their own rules, tools, and guardrails, without the two contaminating each other.
That's an architecture problem, not a prompting problem. Folder discipline, applied consistently, gets you most of the way — but it's a workaround. It asks a human to remember, every session, which world the AI should wake up in.
We think that boundary layer should be built, not remembered. It's a problem we've been working on for a while now, and we're building something aimed squarely at it. More on that soon.
A brain should make every project sharper. Nested wrong, it makes every project a little more like every other one.
In the meantime, the check is simple enough to run today: open your own setup and ask where your sessions actually start. If everything launches from the top of one big vault, some of your rules are being ignored and some of your context is working against you — and now you know exactly why. If you'd rather have a second set of eyes on it, that's a conversation we have with operators every week. It's usually a one-afternoon fix, and the difference shows up the same day.
Writing about AI systems for founder-led businesses across NWA, the River Valley, and Eastern Oklahoma.
When AI can spend your money, you need a gateway — not a promise.
The instinct, when an AI tool quietly burns through money it wasn't meant to, is to tell it to stop. That instinct is the trap. A brake the engine can disengage isn't a brake — it's a request. Here's what an actual control looks like, and how we build it.
Your AI agent doesn't know when to stop.
A client recently got a $2,500 surprise bill from a single tool his AI was using. Half a million calls in a month, most of them asking the same questions over and over. Here's what actually went wrong, and the four guardrails that turn an expensive habit into a predictable line item.
