Switching from Claude Code to Codex should take minutes.
But for most people, it means starting from scratch (here's why)...
Most engineers think they're locking into a harness.
But they're actually locked into their context.
So every time your assistant learns something, gains new skills, or automates another workflow, it becomes harder to switch.
This is why, while building my personal AI assistant for our upcoming Manning book, I've been converging toward one architecture:
Make the harness disposable.
Keep everything else.
Here's what that looks like:
1/ Unified memory
Everything the agent knows lives in one place.
Instead of scattering memory across multiple systems, I prefer building it on top of a single database that supports:
Documents
Full-text search
Semantic search
Knowledge graph traversal
For me, that's
@MongoDB.
One database is enough for the majority of AI assistants.
2/ Serving layer
The agent should talk directly to an interface.
Typically, that's an MCP server.
The database stores the memory.
The MCP server owns the business logic.
It decides:
How memory is searched
How memory is updated
Which tools the agent can use
When conversations become long-term memory
This separation is what makes the system portable.
3/ Harness
Claude Code.
Codex.
OpenCode.
Gemini CLI.
These should be the most replaceable part of your stack.
If your context layer is portable, changing harnesses should be little more than a configuration change.
The new assistant should immediately know:
Who you are
What you're working on
What you've learned
What matters to you
Because your memory moved with you.
To sum up:
The model isn't the moat.
The harness isn't the moat.
Your context layer is.
Design your architecture accordingly.
P.S. If you're interested in building an AI assistant that remembers your research, notes, conversations, and preferences across any harness, I break down the full architecture in Decoding AI Magazine
Read it here:
decodingai.com/p/the-context…