The Model Is the Least Important Part

In July 2026 I gave OpenAI's Codex access to the vault that Claude had been working in for months. I expected a migration. What I got was two new folders and a symlink. The corpus, the procedures, the tools, and the memory layer all stayed exactly as they were. A second model started doing real work on the same projects, and the only thing I had to write was how that model should behave when it got there.

That's what made the argument clear to me. The model is the part of an AI system that gets the most attention, the most money and the most argument, and it's the least important part of the system.

What the Agents Stand On

From the bottom up, my setup looks like this.

The corpus is a single Obsidian vault. It used to be about nineteen vaults; I merged them in 2026 on the Atlas, Calendar, Efforts spine, so a project folder nests intact and keeps its own scoped instructions. It’s plain Markdown so that it opens in any editor, syncs with any tool, and survives every vendor I might stop paying.

Inside the corpus sits a small maps layer, six files in one folder: an entry point, a resume point that says what’s next, a decisions log that says why calls were made, a vault index, an append-only migration ledger, and a model map that says which model I use for what. One fact lives in one file. The vault index wins on status and the resume file wins on what’s next, so nobody has to guess.

Recall is a separate layer, intentionally scoped as read-only rather than integrated into an interactive session. A nightly job distills the vault into a database, after some light preparation by a small Python gate script, so that my phone can query it and hold context about how I work, what I’m working on, and who I am, long term, with minimal drift.

Procedures and tools sit beside recall: skills, which are written procedures the model executes, and MCP servers, which give the model a contract with a real system. Both exist as files tailored to my specific use cases and workflow.

Only then, at the top, come the models, with two different instruction planes (one per model) and a line in the model map for each job.

Proof by Substitution

The way to test whether the model is the important part is to swap it and watch what breaks.

My whole corpus started with Claude as the only model in use. Codex came in one project at a time, starting with a research folder on July 27, 2026. Its instruction plane is a sibling of Claude’s: a folder with its own agent instructions, a template for a per-project adapter, and a readme. It reaches every Codex session through a symlink in the home directory, and rather than keeping its own duplicate of the resume file or the vault index, it points at them. There’s no mirror of the corpus and no second ledger.

The two models only ever talk to each other through one specific procedure with tight formatting rules and guidelines to follow. Inside a project that both models work on, there’s an append-only dialogue file. An entry names its author, one of claude, codex or human, and carries a contradiction, a verification result, a question or a state change. The next agent to open the project reads the log before it does anything, and changelog entries carry the same author field. The file is the only interaction protocol, and I check it weekly to make sure the protocol’s instructions haven’t drifted and that no contamination has breached the rest of the corpus.

With this very specific implementation (and I’ve tried several others), I finally found a system where nothing in the corpus, recall, or tools broke when Codex arrived. All I had to write was the plane, the adapter template, and the first dialogue entry asking the other side to wire its half, and I learned that the ever-growing system I’d spent a year building didn’t care which model showed up for work on any given day.

Tools That Bend Instead of Break

The same principle runs one layer down, inside the tools.

The first MCP server I shipped connects an assistant to a CRM. The obvious way to build one is to write a tool per action, with the CRM’s fields and pipeline stages typed into the code. That works until someone renames a stage or adds a field, which in a working CRM happens every few weeks. Then the model calls the tool in good faith and the call fails, or it succeeds against the wrong field, which is worse.

So the server reads the CRM’s own schema at run time. Fields and pipelines come from the system as it is today, and the tool set is generated from that: fourteen read tools, plus sixteen write tools behind a gate. When the CRM changes underneath it, the next call sees the change. The version on my site is a rebuild running on sample data, but the shape is the one in daily use.

There’s a political economy to this, and I’d rather acknowledge it than pretend the design is neutral.

A model is a commodity with a per-token price, and a vendor who only sells me tokens has a thin hold on me. A vendor who also holds my corpus, my procedures, my memory and the contracts my tools depend on has a huge grip on my day-to-day operations, and the price that results starts to look like rent. It’s rent paid in switching costs, in features I can’t leave, and in the slow drift of my own work into a shape only their product can read. It’s enclosure, an old move, showing up through a new interface.

Owning the substrate is what keeps the rent thin. My corpus and my procedures are files. My memory is a database that I export nightly and could re-point whenever I choose. My tools describe themselves from the systems they talk to, so any vendor I currently use only holds the session I’m in, for as long as I’m in it.

I apply one standard here. Claude built a lot of this with me and I like working with it, but if that ever changes, I’ve made arrangements in advance so that I could stop tomorrow. The same goes for OpenAI. What I’m protecting is the arrangement itself, whichever vendor happens to be on the other end of it.

What I Ask a Vendor Now

Whenever I try out a new vendor, I ask myself these questions, and the answers tell me most of what I need to know.

1. Can I take my corpus out in an afternoon, in a format another tool reads?
2. Do their tools describe themselves at run time, or do I retype their schema into my code?
3. Can a second model read my instructions without a rewrite?
4. What do they keep when I leave?

I'm not saying the model doesn’t matter at all. Quality across large language models differs depending on the job that needs to be done, so I pick per job. However, when I look at where the value in my system actually lives, it’s in the files at the bottom of the stack, every one of which has my name on it and is model agnostic. That way, the system stays reliable regardless of which LLMs are on the market or available for local use at any given time.