Quick answerAssess lock-in risk before you sign by scoring four things independently, not as a single gut-feel judgment: how much of your prompt, config, and orchestration logic is expressed in the vendor's proprietary format versus a portable standard; how much operational and evaluation history (golden datasets, fine-tuning data, eval results) would be stranded if you left; how many other systems have direct, hard-coded integrations to this specific platform rather than to an abstraction layer you control; and what the platform's own switching costs look like for the vendor itself, since a vendor that would also struggle to help you leave cleanly has less incentive to make it easy. Score each dimension before committing, not after a renewal negotiation forces you to find out the hard way.
Why this is a pre-commitment question, not a post-signature one
Negotiating what you can take with you if you switch AI agent vendors later is about the contract clauses to get in writing once you've already decided which vendor to commit to — export formats, timelines, fee caps. This is the methodology for deciding how much lock-in risk you're accepting in the first place, before you're in a position to negotiate anything, because the platforms with the worst lock-in profiles are often the ones where you have the least leverage to negotiate favorable exit terms later. Assess the risk before you sign; negotiate the exit terms as a condition of signing, not as an afterthought.
Score portability of your own logic, not just your data
The most underestimated lock-in risk isn't your conversation data — it's the orchestration logic itself: how your agent routes between tools, escalates, and chains steps together. If that logic is expressed entirely in a platform-specific DSL or proprietary workflow builder with no equivalent in any other framework, migrating means a rebuild, not a data export. Weight this heavily in your assessment relative to how an RFP or vendor bake-off typically weights it, since a bake-off usually optimizes for current capability and cost, and rarely tests how much of what you build during onboarding would survive a future migration.
Count the integrations that assume this vendor specifically
Every system that calls the orchestration platform's API directly — rather than through an abstraction layer your own team controls — is a point of lock-in that compounds over time. Early on, this feels like a minor implementation detail. Eighteen months in, after a dozen internal systems have integrated directly against the vendor's specific API surface, it's a structural dependency that makes switching cost far more than the orchestration logic alone. Assess this at commitment time by asking how many integrations you'd realistically build directly versus through your own thin adapter layer, and weight platforms that force direct coupling as higher-risk regardless of their other strengths.
Weigh the vendor's own continuity posture
A platform with strong technical portability can still be high-risk if the vendor itself is fragile. This overlaps with, but isn't identical to, assessing what happens if your AI agent vendor gets acquired or shuts down — that's about your contingency plan for an event outside your control; lock-in risk assessment is about how much that event would actually cost you given the technical and contractual choices you made at commitment time. A vendor with a shaky continuity posture and a low technical lock-in score is a manageable risk; the same vendor with a high lock-in score is a much more serious one, and the two scores should be multiplied together, not evaluated separately.
FAQ
Does open-source mean zero lock-in risk? No — an open-source orchestration framework still creates lock-in if your team's operational knowledge, integrations, and evaluation infrastructure are built specifically around it. Open-source reduces vendor-continuity risk (the code doesn't disappear if a company shuts down) but doesn't eliminate switching cost.
How often should this assessment be redone after the initial commitment? At minimum at every renewal point, and additionally whenever you're about to build a new integration or migrate meaningful orchestration logic onto the platform — since each addition changes your actual lock-in exposure, not just your contractual terms.
Is some lock-in ever an acceptable tradeoff? Yes, when the platform's capability advantage is large enough and durable enough that the switching cost is unlikely to matter within your realistic planning horizon. The point of the assessment isn't to always choose the most portable option — it's to make that tradeoff consciously instead of discovering the true cost only when you try to leave.