Lock-In Risk in Agent Tooling, and How to Keep Optionality

The agent tooling market is young, products change monthly, and some of them won't exist in two years. That makes lock-in a live concern in a way it isn't for mature categories — and it's manageable with a small amount of deliberate design.

Where lock-in actually accumulates

Not where people expect. The API call is trivially portable. The coupling forms in four places:

Your prompts, tuned to one product's assembly. If a harness assembles context in a particular way, your prompts are written for what it produces. Move and they don't fit.

Your tools, written to one product's interface. Every integration you built to its plugin shape is work you'd redo. ⚠️ This is the largest one for most teams, and a standard tool protocol is the specific mitigation.

Your eval cases, if they live in the vendor's system. These are your specification. Held externally, migration means recreating what your agent is supposed to do, from memory.

Your workflow, shaped by one product's concepts. The subtlest and hardest to unwind — the team's process reorganized around a particular abstraction. This is a real switching cost even when nothing technical is coupled.

What good optionality looks like

Tools behind a standard protocol. Write tool servers to a protocol rather than to a vendor's plugin API, and they work with anything that speaks it. This is the single highest-value structural choice available.

Eval cases in your own repository. In your version control, in a format you own. They're the specification of your agent's behavior and the most expensive thing to lose.

Prompts in your repository, versioned, with the model-specific compensations annotated.

One seam that names the model, in configuration.

Traces exported to your own store. ✅ Even when using a vendor's viewer. Your history of runs is the input to every future improvement, and losing it resets the compounding.

None of this is heavy. It's a day of structural decisions that keeps the door open.

What's reasonable to accept

Optionality has costs, and refusing all coupling produces a lowest-common-denominator setup that's worse than committing.

Reasonable to accept:

• Using a vendor's trace viewer, provided the data is yours.
• Using their eval runner, provided the cases are yours.
• Depending on their loop implementation — it's the small part, and rewriting it is genuinely a few hundred lines.
• Product-specific conveniences that save real time, as long as they're not load-bearing.

The test: if this product disappeared tomorrow, what would I have to rebuild, and how long would it take? Under a week is fine. A quarter isn't.

🔍 The exit rehearsal

Once, deliberately, run your eval suite against a different harness or a plain loop you wrote.

You don't have to switch. The exercise tells you what's coupled — usually two or three things nobody realized — and each is cheaper to decouple now than under pressure. It also gives you a real answer to the question above rather than an estimate.

💡 The lock-in that isn't technical

The one that actually traps teams: process. When a team's workflow is organized around a product's particular model of work, switching means changing how people work, and that's harder than any migration.

Mitigation is mostly awareness — knowing which of your practices are genuinely good and which are shaped by a tool. The good ones survive a move; the tool-shaped ones are the switching cost, and noticing which is which is worth doing before you need to.

The takeaway

Lock-in in agent tooling forms in prompts, tools, eval cases, traces, and workflow — not in the model call. Keep tools behind a standard protocol, cases and prompts in your own repository, traces exported to your own store, and one seam that names the model. Accept conveniences that aren't load-bearing, and rehearse the exit once so you know what's actually coupled. A day of structure now, against a market where products change monthly.