How to Avoid Vendor Lock-In for Coding Agents: A Layer-by-Layer Exit Test

You avoid vendor lock-in for coding harnesses by keeping the layers that build up context in storage you own and by testing, on a schedule, that you can actually move them. For coding agents, lock-in sits in the layers that build up context, not in the model alone. Swapping models is the easy part: most harnesses let you repoint to a different model or gateway with a config change. The accumulated context, meaning your agent definitions, skills, memory, and run history, is the asset that is hard to move, and it is exactly what makes your agents effective at your work.

---

TL;DR:

• Lock-in for coding agents lives in the context layers (agent definitions, skills, memory, run history), not in the model itself.
• Audit eight layers, from agent definitions down to deployment, and score each one with a yes/no exit question.
• A paid API or managed host is a normal vendor relationship; the dangerous case is context you cannot export.
• Self-hosting and multi-harness workers make the exit real, but prompt retuning, capability gaps, and eval re-validation still cost time.
• Portability means leaving is possible and cheap enough to threaten, not that it is free.

---

Table of Contents

• What lock-in means for coding agents
• The eight layers where lock-in actually lives
• The exit test: seven questions to run this week
• Operational dependency vs context loss
• How self-hosting and multi-harness workers change the trade-off
• The migration costs portability does not remove
• When a managed or single-provider setup is the better choice
• Portability checklist
• FAQ

What lock-in means for coding agents

Lock-in is the gap between what it costs to stay and what it costs to leave. With a classic SaaS tool, the asset is the data: CRM records, support tickets, documents. If the vendor offers a full export and the schema is documented, leaving is painful but bounded. You re-import, retrain the team on a new interface, and move on. The data walks out with you, and the tool you left behind held no compounding value of its own.

Coding agents break that pattern, and teams misjudge it because the visible layer looks portable. The model is rented compute. You pay per token, the unit prices are public, and a competing model is one config change away, so the procurement review concludes the stack is fungible. But the asset that makes coding agents effective is the accumulated context layered on top of the model:

• Agent definitions: the roles, instructions, and constraints that shape behavior.
• Skills: the reusable procedures agents invoke against your codebase and workflows.
• Memory: what the system has learned across runs about your repos, conventions, and past decisions.
• Run history: the prompts, traces, and task outcomes you use to debug, evaluate, and improve.

These layers compound. Every run adds memory and trace data; every skill refinement makes the next task cheaper. A model you can replace in an afternoon. Two years of tuned definitions, skills, and memory sitting in a proprietary store with no export path is a factory you would have to rebuild from zero. The strategic case for owning this learning loop is in A Frontier Model Is Rented, a Swarm Is Owned; this post is the practical audit that tells you whether the factory is actually yours.

The eight layers where lock-in actually lives

A coding-agent stack is a stack of layers, and each layer carries its own exit cost. Teams often check only the model layer, conclude they are portable because they can change an API key, and stop there. The audit below runs from the asset layer at the top, the context you accumulate, down to deployment at the bottom, which is whether you can rebuild the system at all. For each layer, the exit question is the one to ask your vendor or your own platform team.

Layer	What locks you in	Exit question	What portability looks like
Agent definitions and skills	Proprietary formats stored in the vendor's cloud	Can you export every agent and skill as files?	Plain files in your repo, importable elsewhere
Prompts and traces (run history)	Logs trapped in a dashboard, retention caps	Can you export full prompts, traces, and task history?	Bulk export in an open format, no retention ceiling
Memory	Opaque store, no dump, no re-import path	Can you export memory in a format you control?	A database file or structured export you can re-import
Model and inference choice	Hard-coded endpoints, model-specific assumptions	Can you switch model or gateway with config only?	An env var or gateway change, zero code edits
Harness	The agent loop runs only in one vendor's CLI	Can the same task run on a different harness?	Tasks defined as data, executable on another harness
Worker runtime	Execution happens only on vendor machines	Can workers run on hardware you control?	Self-hosted workers from images you build and pin
Credentials	Secrets pasted into prompts or a vendor vault	Are secrets bound per host and injected server-side?	Host-bound bindings; secrets never enter context
Deployment	No restore path from your own backup	Can you rebuild from your backup on a fresh host?	A documented restore drill you have actually run

The exit test: seven questions to run this week

Each question is yes/no. A "no" is not a reason to panic; it is a line item with a price you can now see. Answer them as a team, in writing.

1. Can you point the same agents at a different model or gateway with a config change? A no here means model choice is welded into code or prompt assumptions. When the vendor changes pricing or deprecates a model, you are negotiating with no alternative.
2. Can the same task run on a different coding harness? If a task only executes inside one vendor's agent loop, your workflows are hostage to that vendor's roadmap. A no means the harness's feature set, not your definitions, decides what your agents can do.
3. Can you export agent memory in a format you control? Memory is the compounding layer. A no means every run makes the agent better and the exit worse at the same time.
4. Can you export prompts, traces, and task history? Run history is how you debug failures and re-validate after any move. A no means you cannot prove the new stack works as well as the old one, because you no longer hold the old one's record.
5. Are your agents, skills, workflows, and schedules stored as data you hold, in files or a database you can back up? This is the factory definition. A no means the specification of how your work gets done exists only inside someone else's product.
6. Are secrets bound per host and injected server-side rather than pasted into prompts? A no means credentials are leaking into context windows and logs. That is a security problem and a portability problem at once.
7. Can you restore the whole system from your own backup onto a fresh host? This is the only question you cannot answer on paper. If you have not run the restore, the honest answer is no.

Score it plainly. Six yeses and one no is a strong position with a known weakness. Three yeses is a dependency you are choosing not to look at.

Operational dependency vs context loss

Not every dependency is lock-in, and treating them the same wastes political capital. Paying a model vendor per token is an operational dependency. The bill is visible, the unit price is public, and substitutes exist. Paying for a managed host is the same shape of relationship: you are renting capacity, and if the asset walks out with you when you leave, the dependency is just procurement.

Context loss is different in kind. Memory, skills, and run history are the compounding part of the system: they grow more valuable with every run, and they are exactly the parts a vendor has the most incentive to make sticky. If you cannot export them, each month of use raises the exit cost while the monthly bill stays flat.

The asymmetry is the trap. A monthly bill is visible on day one; context loss is invisible until the day you try to leave. Procurement sees the first and optimizes it. Nobody owns the second until a migration is on the table and someone asks where the memory export button is. Treat exportability as a property you verify, not a promise you were given.

A useful forcing question: if this vendor shut off your account tomorrow, what would you lose? If the answer is "an API key and a billing relationship," you have an operational dependency. If the answer is "two years of tuned prompts, agent memory, and trace history," you have lock-in, and the time to fix it is before you need to leave.

How self-hosting and multi-harness workers change the trade-off

It helps to walk through a concrete system built to pass this test. Agent Swarm is open source under the MIT license and self-hosted with Docker Compose, so the custody questions have structural answers rather than policy promises.

At the harness layer, a worker picks its harness at boot with HARNESS_PROVIDER. Harnesses supported today: Claude Code, Codex, pi (pi-mono), OpenCode (experimental), Devin, Claude Managed Agents, and ACP agents, where an ACP agent is an OpenCode or GitHub Copilot CLI preset or a custom command; the README also lists Cursor, Amp, and Grok. Every harness plugs in behind one ProviderAdapter interface, so tasks and agent definitions keep the same shape across harnesses. The details are in the harness configuration guide.

At the model layer, routing goes through gateways rather than hard-coded endpoints. OpenRouter works with Claude Code, OpenCode, and pi through environment variables. OpenCode and pi also work with OrcaRouter and any OpenAI-compatible gateway, and Bedrock via pi is alpha. Not every gateway works with every harness, so check the provider capability matrix before planning a move; gateway authentication is covered in the model gateways guide.

Memory is stored in SQLite, with sqlite-vec for vectors. The embedding endpoint can be any OpenAI-compatible URL (Azure, Together, vLLM, Ollama), and keyword search still works with no embedding key at all, so the memory layer never depends on a single embedding vendor. All swarm state (tasks, agents, schedules, config) lives in one SQLite database on the swarm_api_data volume, and the deployment docs give a copy-the-volume backup and restore procedure. The secrets encryption key must be backed up alongside the database, because without it the stored credentials are unreadable. That database-and-key backup does not cover what lives outside the database: workspace files on the shared and per-agent volumes, custom skill files agents keep on disk, and the file logs on the log volume. Inventory those assets, decide per volume what you would actually miss, and verify with a real restore drill that you can get them back, not just the database.

Script credentials are bound per host through credential bindings and injected server-side, so secrets stay out of agent prompts and out of traces. The Agent Swarm skills plugin installs into Claude Code and Codex, and into OpenCode, pi, and others via npx skills add desplega-ai/agent-swarm, so skills follow the harness instead of being rebuilt per vendor. Session continuity uses a bounded context preamble rather than harness-native resume, which is what lets a task move to a different harness; the mechanism is covered in the context preamble deep dive, and the broader case for this architecture is in self-hosted AI agents.

None of this makes migration free, and there is no one-click export UI. It changes the shape of the exit, from "rebuild the factory" to "retune and re-validate."

The migration costs portability does not remove

Portability removes custody problems. It does not remove engineering work. Four costs survive every exit, and planning for them is what makes the exit cheap enough to threaten:

• Prompt and skill tuning per model. Prompts that sing on one model can go flat on another, and skills need re-testing against the target model. Budget days, not minutes, per critical workflow.
• Capability gaps between harnesses. Steering, skills paths, and spend tracking differ by provider. A workflow that leans on mid-run steering on one harness may need restructuring on another, and spend reporting you relied on may not exist in the same form.
• Re-validating evals. Your eval suite was calibrated against the old stack. Expect to re-baseline scores and re-check regressions on the new model and harness before you trust the move for production work.
• The ops burden of self-hosting. If you self-host to gain portability, upgrades, backups, and monitoring become your job. That is a staffing cost, and pretending it is zero is how backup drills quietly stop happening.

Portability means the exit is possible and cheap enough to threaten, not that it is free. A credible threat is usually enough. Vendors negotiate differently with customers who can leave within a quarter.

When a managed or single-provider setup is the better choice

The exit test is a tool for seeing your dependency clearly, not a command to eliminate it at any cost. Accepting the dependency is often the rational move:

• Your team is small and all of your context fits in one harness. Portability insurance costs more than the risk it covers.
• You are a one-harness shop with no second runtime planned. If nothing in your roadmap points at a move, optimize for depth on one stack.
• You have no ops capacity. A self-hosted control plane with neglected backups is worse than a vendor with good ones.
• Your compliance regime is one the vendor already handles. Rebuilding that evidence chain yourself is real work with no product payoff.

If you want the multi-harness model without running the control plane, Agent Swarm also has a hosted Cloud option, and the self-hosted software stays MIT either way. This post makes no claims about Cloud data handling; those questions go to the team through the contact address on the site. If you are comparing self-hosted options more broadly, the roundup of open-source, self-hostable agent platforms covers the field.

The decision rule is not "dependencies are bad." It is: know which dependencies you hold, price the exit honestly, and re-check after each growth step, because the setup that fits a three-person team rarely fits a thirty-person one.

Portability checklist

• Agent definitions and skills live in files or a database you can back up
• You can switch model or gateway with a config change, no code edits
• You can export full prompts, traces, and task history on demand
• Agent memory exports to a format you control and can re-import
• The same task runs on at least one other harness
• Secrets are bound per host and injected server-side, never pasted into prompts
• You have restored the full system from your own backup onto a fresh host in the last quarter
• The backup includes the secrets encryption key alongside the database
• You know which provider capabilities (steering, skills paths, spend tracking) your workflows depend on
• The exit test has a named owner and a recurring schedule

FAQ

Is using a paid API already lock-in?

No. Paying per token is an operational dependency: visible, priced, and substitutable. Lock-in starts when the asset that makes your agents effective, your definitions, skills, memory, and run history, cannot leave with you. A paid API sitting under context you own is a normal vendor relationship.

How is coding-agent lock-in different from SaaS lock-in?

With classic SaaS, the export is the asset: records out, records in, and you are done. With coding agents, the asset is the accumulated context, and it compounds with use. The model is rented compute; the context layers are the factory, and factories do not fit in a CSV export.

What should we export first if we can only do one thing?

Export the factory definitions: agents, skills, workflows, and schedules. They are small, they change slowly, and they regenerate value fastest on a new stack because they encode how your work gets done. Memory and run history come next, and both should be on the roadmap within a quarter.

Does self-hosting remove lock-in completely?

No. Self-hosting removes vendor custody, but you can still lock yourself into your own conventions, and the migration costs above (retuning, capability gaps, eval re-validation, ops burden) still apply. It converts lock-in from a custody problem into a portability discipline you have to maintain.

How often should we run the exit test?

Quarterly is a good default, plus any time a vendor changes pricing, deprecates something you use, or a renewal comes up. Give the restore question special treatment: a backup you have never restored from is a hypothesis, so run the actual restore drill at least once per cycle.