Vendor lock-in
Dependence on one provider that makes switching costly. With AI it extends beyond APIs and prompts to the vendor's decision behavior, embedded thresholds and platform features.
Vendor lock-in means that changing providers would cost too much in effort, risk or lost capability. In traditional software it usually comes from data formats and integrations. With AI it has more layers.
Prompts, context pipelines and model APIs are the obvious ones. Less visible is dependence on a provider's decision behavior: once thresholds, review queues and evidence are built around how one model decides, a replacement has to be re-qualified, not just swapped in. Platform moves add another layer. A product that holds a user's goals, memory and permissions becomes the owner of continuity, and that is hard to take elsewhere. See OpenAI Dots and context debt.
Reducing it
Keep thresholds and policies on your side of the interface, record the runtime you depend on (runtime address) and test a second option before you need it.
Read more in OpenAI Decisions API turns probability into policy.
Related terms
Decision behavior
How a particular AI system tends to decide across cases — where it leans, abstains or errs. Once embedded in operational thresholds, it becomes a dependency that makes switching vendors harder.
Decisions API
OpenAI's announced decision layer: developers pose a question with a fixed set of possible answers plus text or image context, and the model returns a choice, for classification, routing or an agent's next action.
OpenAI Dots
OpenAI's always-on assistant, described as continuing to work across applications between prompts. It is useful as a test case for persistent delegation: can AI carry a goal, not just complete a task?