Make Your AI Agent Replaceable

I had let one AI assistant become the only tool that knew how my work was organized. Then I hit its usage limit halfway through something. My files were still mine. Too much of the explanation lived in one vendor’s chats and memory. So I spent a day making sure a second agent could walk in cold, read the house rules, and keep going.

For fellow fans of My Hero Academia, this was my “Plus Ultra” attempt.

“But I can’t do it” → “Go beyond.”

That sounds more dramatic than it was. I could still work. I was just slower and worse at it, like getting out of the car and walking the last stretch with a paper map. It felt like a small Flowers for Algernon moment: I could remember what I had been able to do an hour earlier.

The trap was not that Claude Code owned my files. It did not. The trap was that it had become the only tool that understood my folders, my half-finished analyses, and the rules I use to keep an agent from sending email, spending money, or printing credentials.

Then I read a post by Adam Schoenfeld. He had hit the same wall and switched to a second agent. Because his work lived locally and in GitHub, the switch took minutes.

I am a marketer, not a software engineer. My version came down to plain files, one symlink, and a habit of writing down where I stopped.

Keep the work in files you own

Claude Code and Codex can both read ordinary files in local folders. That is the whole trick.

If the project, its instructions, and the unfinished work all live in those files, the agent can visit the project without becoming its only home.

The question I use now is simple: if this vendor vanished tomorrow, what would I have to rebuild?

Here is what I want to survive:

• Folders and Git. My work lives in local directories. The important ones are backed by private GitHub repositories.
• One instruction file per project. It explains what the folders mean, how the project works, and what the agent must never do.
• Project memory in Markdown. Names, decisions, failed attempts, and useful context live in files I can open with any text editor.
• A handoff note. When work stops, the note says what is done, what was checked, and what comes next.

If you have none of this, start with the instruction file. It is useful even if you never change agents.

One rulebook, two filenames

Claude Code reads CLAUDE.md. Codex reads AGENTS.md. I did not want two copies of the same rules drifting apart.

On macOS or Linux, I created a symlink from one name to the other:

ln -s CLAUDE.md AGENTS.md

A symlink is a pointer, not a second copy. Edit CLAUDE.md and Codex sees the same changes through AGENTS.md.

I added three more things:

1. A root instruction file. It maps the folder where my projects live and lists rules that apply everywhere.
2. A tooling map. TOOLING.md says how I reach each service. Command-line tools and scripts usually transfer. Connected accounts often need to be set up again.
3. A handoff convention. Before an agent stops, it writes .agent_handoff.md with what is done, what is pending, and which branch it used.

I also wrote down two house rules: only one agent works in a project at a time, and agents do not edit their own instruction files. Codex has an /init command that creates an AGENTS.md scaffold. I skip it here because AGENTS.md already exists through the symlink.

My backup is Codex

The exact backup matters less than having one you have tested. I use Codex CLI because it works in a local repository and reads the same AGENTS.md file.

The current macOS and Linux installer in the official Codex CLI guide is:

curl -fsSL https://chatgpt.com/codex/install.sh | sh

Prices, models, and limits move too quickly for me to pretend a comparison table will stay useful. The test is simpler: can the backup open the project, repeat the rules, and finish a real task?

While comparing agents, I asked one research tool to check another. It confidently told me that an official installer did not exist. It did. I had read the vendor’s documentation the day before. These tools can help and invent a correction in the same breath. I treat their research as claims to check, not verdicts.

Test the handoff before you need it

My first check was one sentence, typed into a freshly installed Codex from my main working folder:

“Read AGENTS.md and tell me the working agreements.”

It repeated my guardrails, found the handoff convention, and knew where the project notes lived. I had not taught this agent any of that in chat. It read the rules from the project.

Then I gave it a small real task. That second part matters. A backup you have never used is only a theory.

What does not transfer

• The live conversation. A new agent starts cold. The handoff note helps, but it is not memory.
• Connected accounts. Logins and permissions belong to the tool that created them. Some have to be set up again.
• Scheduled jobs. A task running inside one app does not follow you to another.
• Taste and judgment. Models behave differently. I check a new agent’s work the way I would check a new coworker’s.

Why this is a Skill Trade post

Skill Trade is where I write down things that have been useful to me, in case they are useful to someone else. This one keeps paying off: every bit of context I move from a chat into a file becomes available to the next agent too.

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 is the trade.

Email me: ron@skilltrade.marketing