Make Your AI Agent Replaceable
Hitting my AI assistant’s usage limit used to end my workday. This week I made it a shrug.
Here’s the trap I had built for myself. Over the past months I moved most of my working life into Claude Code: my project folders, my runbooks, my half-finished analyses, my drafts. It became what some people call a “personal OS.” Wonderful, right up until the meter runs out mid-task and everything I know how to do is locked inside one vendor’s chat window.
Then I read a post by Adam Schoenfeld that reframed the whole problem. He described hitting that same wall and just… flipping to a second agent. Ten minutes of setup, months earlier, had made his tools interchangeable. The line that stuck with me: he works locally plus GitHub, so switching agents was trivial.
I spent a day replicating that, with an AI doing most of the work. This post documents the setup so you can do the same. You do not need to be an engineer. I’m a marketer. If you can rename a file, you can do this.
The principle: own the substrate
Every AI agent worth using can read plain files on your computer. That’s the whole trick.
If your projects live in ordinary folders, your instructions live in a text file, and your work-in-progress lives in documents rather than chat histories, then the agent is just a head you attach to that body. Heads are interchangeable. The body is yours.
The test I now apply to everything: if my AI vendor vanished tomorrow, what would I lose? Anything that survives that question is infrastructure. Anything that doesn’t is a liability with a subscription fee.
What my substrate looks like
Nothing exotic:
- Folders and git. My work lives in local directories, the important ones backed by private GitHub repos.
- One instruction file per project. A markdown file (mine is called
CLAUDE.md) that tells any agent how this project works: what the folders mean, what the rules are, what it must never do (send email drafts, touch budgets, print credentials). - Memory as markdown. Long-lived context (who’s who, what worked, what failed) lives in plain markdown files with an index, not inside any vendor’s memory feature.
- State in files, not in chat. Work-in-progress gets written down: briefs with a status line, next actions, and an append-only log. Any agent (or any human) can pick up where the last one stopped.
If you have none of this today, start with the instruction file. It’s an hour well spent even if you never add a second agent.
The ten-minute bridge
The AI industry quietly converged on a standard: most agents look for a file called AGENTS.md. Claude reads CLAUDE.md. You do not need two files. You need one file and a symlink:
ln -s CLAUDE.md AGENTS.mdThat’s most of the migration. One canonical rulebook, two names, every agent reads the same thing. My guardrails (never send, never spend, never print secrets) now govern whichever model shows up for work, automatically.
The rest of the bridge, maybe twenty minutes of writing:
- A root instruction file for the folder where all my projects live: the map, the universal rules, and a pointer to the memory files.
- A tooling map (
TOOLING.md): how each system is reached in a vendor-neutral way. CLIs and scripts transfer between agents. OAuth connectors do not. Knowing which is which before a failover moment saves you the discovery at the worst time. - A handoff convention. When an agent stops mid-task (limits, end of day), it writes a
.agent_handoff.md: what’s done and verified, what’s pending, which branch. The next agent reads it first. This formalizes something I already did with project briefs, and it’s the piece that makes a mid-task flip painless. - Three rules written into the rulebook itself: one agent at a time per project (they fight over git otherwise), no agent may edit the instruction files, and Codex users must never run
/init(it will happily overwrite your symlink with a generated file).
The heads I chose
I evaluated the current field twice: once with my primary agent doing live research, once with a deep-research run from a different vendor, then reconciled the two. My conclusions, for my workload (marketing ops, scripts, content, CRM automation):
- Primary failover: OpenAI Codex CLI. Terminal-native like Claude Code, reads
AGENTS.mdnatively, flat-rate billing on a ChatGPT plan. Flat rate matters for a failover: when you’ve just run out of capacity elsewhere, the backup must not be a taxi meter. Install is one command:npm install -g @openai/codex. - Async delegation: Google Jules, free tier. Not a failover at all: it clones a GitHub repo into a cloud VM and comes back with a pull request. It can’t touch your local files or your half-finished thoughts. But 15 free tasks a day of “go fix this small thing and open a PR” is real capacity for chores.
- Holstered spare: GitHub Copilot. Since June it bills by metered credits, which makes it wrong as a primary (heavy agent use burns dollars per hour) and exactly right as a spare: $10/month, costs nothing while idle, and it can run Claude-family models on GitHub’s meter when Anthropic’s pool is dry. One gotcha: pin your model explicitly; the auto-router quietly downgrades when limits approach.
- Watchlist: Google Antigravity. The most ambitious architecture in the field (parallel agents, built-in browser automation) and free in preview, but its rate limits are explicitly not guaranteed, which is disqualifying for the one job a failover has. The day it exits preview with real quotas, this list gets revised.
A humbling footnote about that deep-research run: it confidently “corrected” one of my verified facts, insisting an official installer didn’t exist. It does; I had read the vendor’s own docs the day before. I sent one AI to fact-check my other AIs and caught it inventing a correction. Treat every agent’s research, including this post, as claims to verify, not verdicts.
The acceptance test
Setup means nothing until you flip for real. Mine was one sentence, typed into a freshly installed Codex in my main working folder:
“Read AGENTS.md and tell me the working agreements.”
It recited my rules back: the guardrails, the handoff convention, where memory lives. A model I had never configured, from a different company, knew house rules it had never been told, because the rules live in the house, not in the vendor.
What honestly doesn’t transfer
So you don’t oversell this to yourself:
- Live session context. The new head starts cold; the handoff file is the mitigation, not a cure.
- Connected tools. OAuth grants are per-vendor. My CLIs and scripts moved; my chat-app connectors did not.
- Automations. Scheduled tasks and background jobs are harness features, not substrate.
- Judgment. Each model has its own quirks. Verify the new head’s work the way you’d verify a new hire’s.
Why this is a Skill Trade post
Skill Trade is where I document the skills and systems that have been useful to me, on the theory that they’ll be useful to you too. This one compounds: every hour I’ve invested in files-not-chats now pays out across every agent, current and future.
If you build your own version, or already have one, I genuinely want to read about it. Documenting how you use your skills is itself a skill. That’s the trade.