Topic
A two-second test that tells you which parts of your AI setup travel with you and which parts you’ll rebuild from scratch the day you switch tools — plus the one discipline (declare, don’t implement) that keeps the answer honest as your setup grows.
Target Reader
A knowledge entrepreneur who has invested real months in a single AI tool — a tuned CLAUDE.md, a folder of skills, project context, accumulated memory. They’re productive. They’re also uneasy, because the pace of model releases means the tool they bet on may not be the right one in six months, and they have no idea how much of their work is portable.
The Fear / Frustration / Want / Aspiration
“I’ve put months into making this thing work the way I think. If I switch — or if the pricing changes, or the model I depend on gets deprecated — how much of that comes with me? I suspect the answer is ‘less than I’d like,’ and I’d rather not find out during the migration.”
Before State
The reader’s setup is one undifferentiated thing. Identity, instructions, project context, memory, MCP connections, hooks, and scheduled jobs are tangled together in tool-specific files, and they’ve never had a reason to sort them. Their lock-in exposure is unknown — not because it’s unknowable, but because they’ve never had a test to apply. The dread is vague, which is why it never turns into action.
After State
The reader can sort their entire setup into two columns in about ten minutes, and knows exactly what they’d lose in a migration. More usefully, they’ve caught the specific mistake that creates avoidable lock-in — implementing a connection where they could have declared a need — and they know the one-line adapter that costs nothing and buys harness independence.
Narrative Arc
Open on the migration nobody plans for: months of tuning, a better tool appears, and the honest question is what comes with me? The tension is that most people answer this by picking a side and hoping — because the setup looks like one thing and there’s no obvious seam. The turn: it isn’t one thing, it’s two with different physics. Cognition (identity, instructions, memory, rules) runs at inference time and is made of text. Kinetics (tools, connectors, loops, schedulers) runs at runtime and is made of code. Text travels; runtime doesn’t. Resolution: the test, the git init analogy that makes it concrete, and the discipline — declare, don’t implement — that keeps the boundary from rotting as the folder grows.
Core Argument
Your AI setup is two things with different physics — cognition that can be written down and travels, and kinetics that must run and stays — and the test for which is which is simply whether it can be a markdown file.
Key Evidence / Examples
- Lou’s framing, and the reason he built the framework: “People are mixing up harness and agent a lot. What I’ve come to conclude is that the agent is the cognitive part and the harness is the kinetic part.”
- The
git initanalogy, which does the heavy lifting for a non-technical reader:.gitmakes an ordinary folder version-aware without changing anything visible..aaidoes the same for intelligence. Copy the folder, copy the intelligence. - The declare-don’t-implement rule, with Lou’s own example: a folder that needs Notion doesn’t talk to Notion — it writes down that it needs the Notion MCP, and the harness supplies it. “This file is really just declaration of needs.” Same for triggers: the folder declares “weekly”; the scheduler lives outside.
- The entire cost of harness independence, one sentence in
CLAUDE.mdorAGENTS.md: “This folder carries its own agentic intelligence. Before acting on any request, read.aai/instructions.mdand follow it.” - The lived version: “Something that would have worked in Claude — you fine-tune Claude to make it do all those things, then you go over to Gemini or Codex and realize, oh, that’s not going to work.”
- The payoff Lou actually uses daily: three windows open — Claude, Codex, Gemini — doing council work off the same core context. “It’s super handy for them to all be working off the same core context.”
Proposed Structure (6 beats)
- The migration question. You’ve spent months on this. A better tool just shipped. What comes with you? Most people don’t know, and that’s not a knowledge gap — it’s a missing test.
- It’s not one thing. Cognition vs. kinetics. Inference time vs. runtime. Text vs. code. Keep this short and concrete — the split is intuitive once named.
- The test. Can it be written down in a markdown file? That’s the whole test. Apply it to five things the reader definitely has.
- git init for intelligence. The analogy, the hidden folder, and the consequence that sells it: copy the folder, copy the intelligence.
- The mistake that creates lock-in. Declare, don’t implement. “Calls the Notion API” vs. “needs Notion access.” One is a trap and it looks like progress.
- The one-line adapter. Show it. Close on the three-windows payoff — portability isn’t just insurance, it’s leverage you can use today.
Related Insights
- Insight - The Markdown Test — If It Can’t Be Written Down, It Belongs to the Harness
- Insight - The Harness Architecture — Declare Only What You Need, Import the Rest
- Insight - The me.md Pattern — Separate Your Identity From Your Harness
- Insight - AI Sovereignty — Build Interchangeable-Intelligence Harnesses So No Vendor Owns Your Workflow
- Insight - The Resolver Pattern — Your CLAUDE.md Is a Pointer File, Not a Knowledge Store
Editorial Notes
Tone: Architectural but not technical. The reader is not an engineer. The git init analogy is load-bearing precisely because it lets a non-engineer hold the whole idea — protect it, and don’t assume familiarity with git internals beyond “it’s a hidden folder that makes the folder smarter.”
Angle to avoid: Do not write this as an AAI product announcement. The test is the article; the framework is one implementation of it, and a reader who never touches AAI should still finish with something they can use on Monday. Any draft that requires the reader to adopt Lou’s repo has failed.
Competing briefs — check before drafting: Brief - Your Business Is a Folder — The Ambient Agent Architecture That Replaces Your Virtual Assistant and Brief - Recursive Ambient Folders Your Folder Tree Is a Rule Inheritance Hierarchy both live in folder-as-agent territory. The differentiator here is lock-in and portability — a fear-driven angle neither of those touch. If a draft drifts toward “here’s how folder agents work,” it has collided with those briefs and should be re-pointed.
The strongest hook is the fear, and it’s real right now: readers watching model releases land monthly, wondering what they’re building on. Lead with the exposure, not the architecture.
Sub-thesis worth one line, not a section: Lou’s prime directive — design so everything runs inside the subscription harness, never as hosted API calls — is what separates this from the other “folders as agents” projects circulating. Useful credibility beat; not the article.
Next Step
- Approved for drafting
- Needs revision
- Deprioritised