Open-source AI agent platform vendor lock-in, and the test for it

Two doors, and only one is locked

Vendor lock-in is the cost of leaving a product, measured in work you cannot take with you. Most buyers check the model first. They ask whether the platform can call a different provider, and whether the key is theirs. That is a real question, and the answer varies by product.

The door that stays locked sits behind the model: the agents, the memory they build up, and the run history that shows what they did. A hosted assistant can let you switch models and still keep every agent definition in its own workspace. A framework gives you the code and leaves memory in a store you configure. An open-source platform can publish its source and still keep run history in a schema only it reads. The label on the box does not tell you which door you are standing at.

Where the state physically sits

On a hosted workspace, the agent is a set of fields in the product. ChatGPT Work keeps a project's chats, files and instructions together, and Work on web and mobile runs in the cloud (ChatGPT Work and Codex). Messages and task context can be stored in the cloud even when work runs locally. The work is real. The workspace around it belongs to the vendor.

A framework puts the orchestration in your repository. CrewAI defines each agent in agents/<name>.jsonc or in Python, and sets the model per agent with the llm field (CrewAI agents). Memory defaults to LanceDB under ./.crewai/memory (CrewAI memory). You own the code and the store, and you also own the server, the backups and the upgrade path.

Kortix keeps the agents, skills, memory, tools, triggers and connectors as files in the project repo. A session clones it, works on a branch named after the session, commits, and opens a change request against the default branch (Read the docs). The state you would have to leave behind is the state you can read.

The model layer is the one you can swap

The model is the most visible choice on any platform, and the least useful place to look for lock-in. Kortix takes any model provider with your own keys, set per agent, per session or per prompt (Kortix docs). ChatGPT Work has a model picker with a specific model and its reasoning levels (ChatGPT Work and Codex). CrewAI sets an llm on each agent. Three different products, three ways to change the model.

None of that helps if the instructions and memory sit in a store you cannot take out. A team can move from one model to another in an afternoon and still spend a quarter rebuilding its agents somewhere else. Changing the model is easy. Moving the state is the work.

What a Kortix project carries

A Kortix project is a git repo with kortix.yaml at its root. The manifest declares the agents and what each one may reach, while the behavior lives in agents/<name>.md. The shape is in the Kortix docs:

kortix_version: 2default_agent: kortixagents:  kortix:    file: agents/kortix.md    connectors: all    secrets: all    skills: all    kortix_permissions: all

The repository layout is ordinary enough to open in any editor (Read the docs). Every path in it is a file you can edit.

kortix.yamlAGENTS.mdagents/kortix.mdskills/my-skill/SKILL.mdmemory/MEMORY.mdtools/lookup_order.tsharnesses/opencode/opencode.jsonc

Your agents, skills, company memory, and connectors live in one git repo you own. A session clones the repository, works on a branch, and opens a change request. Session work reaches main through a change request. Merge is default-deny for agents.

Kortix runs on Kortix Cloud, in your VPC, or on your own on-prem network. To leave, you clone the repository and take the history with you. Nothing needs a migration tool, because the files are already the format. The migration walkthrough covers the file assembly if you are moving off a hosted workspace.

What open source does not settle

Open source gives you the right to read and fork the software. It does not, on its own, guarantee that memory is portable or that run history is yours. A product can publish its source and still keep the useful state in a hosted database. A repository can be public and hold none of the state you need on the way out. What matters is whether the thing you would carry is a file in it.

Kortix is open source, and its memory is files under memory/ in the project repo. A memory edit is an ordinary file change on the session branch, and other sessions see it after a change request merges (Read the docs). That is the part to verify on any platform: read where the product says memory lives, then look for the file.

The five-question exit test

Run these against a trial project, not a sales demo. A vendor can answer yes to all five in a call; only the product can pass them.

1. Can I export every agent as text? A pass is a file per agent that opens in an editor, or a repository clone that contains them. A fail is an export button that returns a bundle only the product can import.
2. Is memory readable outside the product? A pass is a path you can open: a folder, a database file, a table you can query. A fail is a memory panel with no export and no path.
3. Can I change the model without rebuilding? A pass is a model field per agent or per session, with your own provider key. A fail is a model tied to a plan, where a change means a new agent.
4. Does a session's work arrive as a diff I can keep? A pass is a branch and a change request, or a commit you can merge. A fail is a chat transcript and a set of files you download one at a time.
5. Can I run the same configuration on my own machine? A pass is a repository clone plus a documented install. A fail is a desktop client with no server path.

Five passes do not make a product good. They make the exit real. A platform that fails two of them is asking you to bet the work on staying.