The common advice for avoiding AI lock-in is to choose a client that can switch models. Use Claude for one task, an OpenAI model for another, perhaps an open model for routine work. Keep one interface and change the intelligence behind it.
That is useful. It also solves only one of three portability problems.
The first is model portability: can I change which model reasons about the work?
The second is runtime portability: can I change the system that plans, supervises, equips, isolates, and presents the work?
The third is state portability: do my projects, decisions, methods, safeguards, and accumulated knowledge survive either change?
Most multi-model systems address the first. Synthesis engineering is my attempt to address all three without flattening the differences that make Claude Code, OpenAI Codex, Cursor, Hermes Agent, OpenClaw, and other systems worth using.
Model portability lets you change the reasoner. Runtime portability lets you change the working environment. State portability lets the work remain yours.
A model is not an agentic work system
It is tempting to think of Claude Code or Codex as a model with a terminal attached. That description misses much of what determines the result.
An agentic work system decides which instructions enter context, how tools are described, what the agent may change, how approvals work, where code executes, how long-running work is checkpointed, how parallel tasks are isolated, which apps and data sources are available, and how a human can inspect or interrupt the work.
The vendors describe these systems in product terms. OpenAI’s Codex app supports parallel agents, isolated git working directories, skills, automations, and sandboxing. Anthropic’s Claude Code supports checkpoints, hooks, subagents, and background work. These interface features shape what the model sees and what it can safely do.
Cursor’s Composer 2 technical report makes the point from another direction. Cursor describes training and evaluating its model against production-representative tools, environments, backend behavior, and the actual client. Faithful evaluation requires the runtime because the runtime is part of the behavior being evaluated.
Switching the same model into another client can be an excellent choice. The move creates a different system.
This is why Synthesis complements Claude Code and Codex. It preserves the parts of my work that should belong exclusively to neither one, while letting each native client do what it does well.
Cost is real here, and it is downstream of the question this article is about. A cheaper runtime that strands your method is not cheaper.
Why not choose one runtime and be done with it?
That can be the right decision, and I want to be fair to it. Hermes Agent, OpenClaw, and Cursor are serious systems, not wrappers: between them they cover model choice, memory, tools, self-created skills, subagents, scheduled work, sandboxes, and deep editor integration. If most of your work has one interaction shape, if the system you pick already has the controls that work needs, and if your projects are short-lived enough that migration never comes due, consolidating on one of them is a good trade and you should take it.
The trade I could not make is what standardizing costs at the boundary. Whichever one you choose becomes the home of your tools, your memory, your security model, and your working conventions, and each of those native surfaces keeps its own version of them. Leave, and the state and the method stay behind. That is the failure I kept meeting, and it does not depend on which client I was leaving.
My work also spans more shapes than one interface serves well. Coding, research, writing, project management, communications, and operational work want different surfaces, and some of them should not be conversations at all.
A universal client gives you one place to work. A portable operating layer gives you more than one place to continue the same work.
What Synthesis owns
The stable center has five parts.
1. Durable project state
The project keeps its current context, stable reference facts, session history, plans, and substantial artifacts in version-controlled files. Chat transcripts and tool-native memory may help; the project files remain the system of record.
I described the original cross-client version in Synthesis Project Management Now Works Across Claude Code and Codex. The underlying principle has become stricter since then: the receiving agent must verify the project files against git and live system state instead of trusting any cached summary.
This also follows the tiered context architecture: current working state, stable knowledge, and chronological history have different jobs and should not be collapsed into one ever-growing file.
2. Executable methodology
When a useful practice repeats, it becomes a skill rather than another prompt buried in a chat. Research, code review, project planning, knowledge capture, writing quality, safety checks, and publishing each have explicit procedures and verification.
Synthesis skills turn procedural knowledge into artifacts an agent can load and execute. Public skills have one source with native Claude and Codex packaging. Private skills remain separate sources but follow the same deployment and conformance rules.
The goal is equivalent, verifiable behavior rather than identical file placement.
3. Native adapters
Canonical instructions belong in an agent-neutral source. Claude Code and Codex receive native representations suited to their own discovery and hook systems. Platform-specific integrations stay platform-specific.
This avoids two bad outcomes. Duplicated instructions drift. A universal instruction file that ignores native capabilities targets the least capable common subset.
The adapter pattern keeps one source of intent while allowing different runtime expressions.
4. Continuous conformance
Portability decays if it is treated as a migration project with an end date. Both clients change. Skill formats evolve. Hooks gain events. Plugin systems appear. A path that worked three months ago can remain on disk while the client quietly stops reading it.
Synthesis therefore tests source structure, generated instructions, installed skills, dependency health, protective hooks, active project recovery, cross-client handoff, and version parity between the clients themselves. A release that reaches one client and not the other is drift, and drift is detected daily rather than discovered at failure. Matching file counts prove little. The capability must be discovered and behave correctly in both clients.
Lifecycle evidence matters as much as installed files. Copying a new plugin into a cache does not prove that an active conversation loaded it. Synthesis records genuine startup events as receipts tied to the client-owned transcript, the exact plugin version, and the immutable installed root.
When those records show that a conversation started on older code, the system checkpoints the project and restarts the current client first. It continues the same conversation only if a later startup receipt preserves the session identity and binds it to the current installation. A different conversation is required only when that proof fails. Installation, process restart, and conversation replacement are distinct events; the evidence should distinguish them.
5. Coordination
Portability across time is insufficient when Claude Code and Codex can run at the same time.
The current project-management system registers each independent agent session’s project, machine, heartbeat, isolated git working directory and branch, claimed files, and role in the project record. Different projects can proceed independently. Sessions on the same project use one owner for canonical context and bounded contributors for non-overlapping implementation.
The board refuses overlapping file claims, shared worktrees or branches, and competing project-context owners. Contributors record their results separately for the owner to verify and reconcile.
This makes parallel work possible on one shared filesystem. Across computers, git carries durable handoffs, while the coordination board uses a lease stored on a dedicated private git ref and compare-and-swap updates. Local file locks serialize writers on one machine; the remote lease makes one ownership decision across machines. If the remote cannot be reached, a board mutation fails closed instead of guessing that the claim is still available.
The first version used letters such as A and AX as session labels. Those
letters were never the claims; the claims were the source paths owned by each
session. The labels still blurred that distinction, became harder to discuss as
the board grew, and were a weak foundation for more than one human operator.
Each session now has an authoritative UUIDv7 plus two exact human aliases. One is a compact 12-character Base32 form for copying between tools. The other is four common English words followed by a five-digit number, which is easier to read aloud, remember briefly, and type on another device. Both aliases encode the same 60 random bits from the UUID rather than creating separate identities. The board allocates them inside the same atomic lease transaction, rejects collisions, and preserves old letters only as migration aliases.
The identifier scheme behind that is an implementation detail; what matters here is that several runtimes coordinate through one durable identity rather than each keeping its own.
Parallelism still needs concurrency control.
How the ecosystem has evolved
Synthesis engineering began as a discipline for keeping human judgment, engineering quality, system understanding, and transferable knowledge at the center of AI-assisted work, and those principles still define the broader Synthesis Engineering Framework. Every layer above arrived the same way: practice exposed something missing. Context had to survive long conversations, so the architecture became explicit. Methods had to compound, so they became skills. Work had to move between clients, so project memory moved outside both of them, which is also how I learned that convenient assistant memory is neither portable nor versioned. Running two capable agents at once showed that preserving memory is not the same as protecting it, and coordination followed.
The pattern is what I would keep if you take nothing else from this. When a workflow lesson repeats, it should stop being a lesson and become a system, because a lesson depends on somebody remembering it and a system does not.
Products built on the method
I also build products on this layer, and they are deliberately not the point. The method has to stand without them: if a runtime I wrote disappeared tomorrow, the state, the methodology, and the conformance evidence would still be sitting in git, usable by whatever came next. That is the test for whether a layer is real, and it is a test my own products have to pass like anything else.
When you need this layer, and when you do not
Synthesis engineering imposes real cost. Canonical sources need maintenance. Adapters need testing. Project files require discipline. Coordination rules add friction before concurrent writes. A single runtime is easier to operate.
You probably do not need this architecture when:
- you use one agentic client and expect to keep using it;
- the work is short-lived or readily reconstructed;
- built-in memory and rules are sufficient;
- one model router provides the tools and controls you need; and
- the cost of maintaining portability exceeds the cost of migration.
The case becomes stronger when:
- work spans months, machines, repositories, or organizations;
- more than one model or agent runtime has a meaningful advantage;
- decisions and source provenance must be auditable;
- safety and publishing rules must behave consistently;
- methods should improve and transfer across projects; or
- independent agents can review or continue one another’s work.
Hermes, OpenClaw, or Cursor could each become another capable execution environment. The decision is whether the durable center of your work should live inside the execution environment.
I keep mine outside it.
I want to use the best available model and the best available agent runtime for the task. I also want to close one client, open another, move to another computer, or return weeks later without reconstructing the project from memory.
That is why synthesis engineering exists.
Own the state that must outlive the execution environment. Then choose the execution environment on its merits.