Agent lock-in: own what survives a switch

A coding agent becomes easier to replace when the project’s rules and the evidence that work is complete stay in your repository. Switching vendors while leaving those assets inside the product keeps much of the lock-in intact.

In my migration account, published in February and updated in July 2026, I described leaving Claude Code for OpenCode, then Kilo Code CLI. In Anthropic, the Apple of AI, published in July, I documented returning for the integrated ecosystem. That journey explains the trade-off; it does not prove my hooks work unchanged elsewhere.

The approach proposed here separates what defines the work from what connects a tool to it. You can choose a convenient integration and keep the criteria that would let you leave. This article presents no controlled comparison of the method.

What belongs outside the product

Project conventions, architecture decisions and acceptance criteria have value independent of the model. A task should specify the expected behavior, the boundaries of the change and the evidence required for acceptance. Those assets remain useful to the next agent, and to a developer taking over without one.

The open AGENTS.md format provides a place for project commands and instructions. Its documentation describes a Markdown file with no required fields, supported by several agents. That makes the text easier to share. How it gets loaded and how instruction conflicts are handled still need checking in your chosen tool.

The same applies to model routing: keeping the selection criterion, such as reserving complex reasoning for tasks that require it, lets you change model references later. A configuration full of vendor names preserves that intent less effectively than a decision documented alongside it.

The team rules guide covers this groundwork. For a small task, the issue and existing tests may be enough. Collecting context files nobody reads would add another kind of debt.

A portable gate still needs an adapter

A rule such as “reject delivery without approval” can survive an agent switch. The mechanism that intercepts the action depends on the harness. The Claude Code hooks reference describes events, JSON inputs and decisions tied to its execution lifecycle. PreToolUse runs before a tool call and can block it; PostToolUse runs after a successful call.

Copying the script without checking when it runs can therefore change the protection. A check after the action does not replace a refusal before it. Porting must establish which event receives which data, and how a refusal is actually enforced.

The durable asset includes the rule, the check where it can be isolated, and its test cases. The adapter translates the harness event into input for that check. For a review gate, cases should cover missing approval, approval invalidated by a change, and valid approval. An allowed case must also pass: false positives are part of the cost.

I documented a bypass of my own gate when the approval stamp and commit were chained in the same shell call. That historical defect justifies a regression case during a port; it does not establish equivalence between two harnesses. Protections in CI can remain shared without guaranteeing that an action is blocked locally.

Run a switch whose result you can assess

The proposed method starts with a representative task, from the same repository state in two isolated workspaces. Set the criteria before launching the agents. The agentic workflow guide explains how to break work into verifiable units.

Then prepare a handoff packet: intent, relevant files, decisions already made, verification commands and remaining work. That summary belongs to the project. It avoids making the entire handoff depend on a conversation history the other product cannot import.

Port the necessary adapters and verify their behavior before trusting them with a sensitive action. Run the task against the same acceptance criteria. Record preparation time, gate porting, execution and review corrections separately. Learning the tool deserves its own line; a first encounter does not measure established use.

The exercise should produce an actionable decision: which assets were reused, which checks needed adapting, which capabilities are missing, and whether the deliverable meets the same criteria. A copied file or a session that starts does not establish that equivalence.

An exit route needs upkeep

Connectors, permissions and session histories do not automatically travel with Markdown conventions. If a handoff loses access to a useful source, count the reconstruction time or acknowledge the missing capability. Integration may remain the best choice for your work.

An unused alternative also needs updates, valid access and recovery exercises. Choose a cadence proportionate to the risk and record the actual effort. Dropping a personal customization during a switch does not automatically mean you have removed a shared dependency.

You can start with one task and its critical checks. If the criteria survive but the port costs too much, keep the integration with that trade-off understood. There is still a benefit: the next tool change will have a work contract and evidence requirements to meet.