AI vendor lock-in is moving to the harness

For companies building AI products, a choice of models offers less freedom than it seems. Much of what makes an agent useful lives in its harness: the software around the model that calls tools, keeps memory and enforces rules. The harness, more than the model, is where AI lock-in now sits.

Harrison Chase’s email assistant had learned his preferences and tone. When it was accidentally deleted, Chase rebuilt it from the same template, but the replacement performed worse. “I had to reteach it all my preferences, my tone, everything,” he wrote.

Chase co-founded and runs LangChain, which sells tools for building and hosting agents, so the company has a commercial interest in where that memory lives. Even so, the episode illustrates a problem for anyone hoping to move an established agent: recreating the software may leave behind much of what made it useful.

That complicates an appealing promise in AI procurement. A platform that offers several models seems to give its customers plenty of choice. Yet the platform may still hold the memory and operating rules on which their product depends. They can change the model and remain locked in to the supplier running everything around it.

From context engineering to harness engineering #

Engineers call that surrounding software an agent harness. It manages the agent’s work, calling models and tools, keeping track of what has happened, and enforcing rules before an action goes ahead.

Microsoft’s Agent Framework includes approval policies among its harness capabilities. An instruction to seek permission needs software that checks for approval before allowing the tool to run.

Prompt engineering deals with instructions. Context engineering extends it to the information a model receives, including retrieved documents and conversation history, a progression described by Anthropic, the maker of Claude. Both matter when an agent makes repeated model calls to finish a job. Harness engineering adds responsibility for what happens between those calls, including checking the work and recovering when it fails.

Mitchell Hashimoto, a co-founder of HashiCorp, describes the work in less abstract terms: give the agent “fast, high quality tools to automatically tell it when it is wrong.” His examples include tests, screenshot scripts, and repository instructions drawn from earlier mistakes.

The result depends on this environment as well as the model inside it. Ethan Mollick, a professor at the Wharton School, observed different behavior from the same Claude model across applications and harnesses.

Managed agent runtimes and open-source harnesses #

Providers now offer to take this work off the buyer’s hands. OpenAI’s Agents API, in public beta since September 2026, gives developers access to a managed Codex harness.

OpenAI runs sessions, coordinates the work, and handles recovery. It also manages context compaction, which reduces a growing conversation to a smaller representation the model can use. The customer supplies tools and chooses where the agent executes them.

Other services let customers decide how much to hand over. Microsoft Foundry (formerly Azure AI Foundry) lets customers configure an agent for Microsoft to run, or bring their own agent code and leave hosting, scaling, and identity to Microsoft. It offers model changes without changes to agent code. Google’s Agent Runtime (formerly Vertex AI Agent Engine) hosts agents built with several frameworks, including custom containers that meet its requirements.

Customers can buy the whole operation, bring more of their own software, or run a harness themselves while buying models and infrastructure separately. Each arrangement leaves a different amount of work to do if they move.

Vstorm builds harnesses for clients who want to retain control of their systems and avoid dependence on a single vendor. We usually use Pydantic AI, a Python framework for agents, and prefer open-source tools we can inspect and adapt.

Vstorm’s pydantic-deepagents harness puts tools, memory, planning, and execution around a configurable model. Those capabilities can stay in place when the model changes. This is also the approach we sell.

How agent memory creates vendor lock-in #

For a small engineering team with a bounded internal task, a managed agent may be the better bargain. If it does the job and would be affordable to rebuild, maintaining a runtime could consume time better spent on the application.

The calculation changes for a product whose usefulness grows with its knowledge of customers. Chase could recreate the assistant’s template. Recreating its education took more work.

Moving that knowledge requires more than a download. An exported memory store is useful only if the replacement harness can interpret it, retrieve the relevant parts, and supply them to the model.

Session records have similar complications. OpenAI’s compaction endpoint, for example, returns an encrypted item carrying information from earlier work into subsequent requests.

A team planning to leave needs to establish how it would recover the necessary information elsewhere. Keeping the original records and being able to rebuild usable context are part of the migration work.

Why AI model portability requires testing #

Even with those records in hand, models have habits. OpenAI recommends a particular file-editing tool because Codex was trained to work well with its format. A common interface can sacrifice some of that fit.

Armin Ronacher, the creator of the Flask web framework, found a more awkward example while working on the Pi coding agent: newer Claude models sometimes proposed correct edits while inventing extra fields in the tool arguments. Pi rejected the calls. The models could work out the change and still fail to submit it correctly.

Ronacher suspects that training around Claude Code’s tools helps explain the behavior. As he put it, “tool schemas are not neutral, at least not on Anthropic models.” These schemas specify the inputs a tool accepts.

Pydantic AI’s documentation makes a related qualification: services using the same programming interface can still support different features. A shared interface leaves differences in reasoning, tool use, speed, and native capabilities for engineers to handle.

We have had to handle some of them ourselves. On July 24, 2026, we added support for local services using OpenAI’s programming interface to the pydantic-deepagents command-line tool.

The same release incorporated a fix for compressed conversation histories that Anthropic and Google rejected. The rebuilt history contained instructions, but no messages in the form those providers required. Every run long enough to trigger compression failed on those providers. The fix carries the summary as an ordinary message, for every provider. The shared interface had hidden a difference in how providers treat system instructions.

That is why, in our client work, we build evaluations, repeatable tests of the tasks an agent must complete, and run them with multiple models. The results show which alternatives can do the work and where a switch needs adaptation. Clients need evidence of a usable replacement before they need to rely on one. An open harness gives engineers somewhere to make the necessary changes, along with responsibility for maintaining them.

AI sovereignty and the ability to switch providers #

Being able to switch is one practical meaning of AI sovereignty for a company building a product. In an essay for Carnegie, Luca Belli, a professor at FGV Law School in Rio de Janeiro, argues that states retain autonomy through the capacity to switch providers, adapt technology, and impose conditions within an interdependent system.

We think the same reasoning is useful in product architecture. A company can buy models and infrastructure while keeping control of its essential records, rules, and interfaces. It needs an alternative it can actually operate.

Portability addresses only part of a company’s dependence on technology suppliers. An open-weight model, whose trained parameters can be downloaded and run on a company’s own servers, addresses the model dependency. It does little by itself to make the rest of the application portable.

Nor does a migration route settle every sovereignty concern. The European Commission’s Cloud Sovereignty Framework, used in procurement, assesses jurisdiction, operational autonomy, and supply-chain dependence separately. Exposure to another country’s legal authority may justify tighter control over deployment, however easily the software moves.

How to test whether you can switch AI providers #

For an engineering team choosing a runtime, the useful next step is a rehearsal. Run representative tasks with a second model in the existing harness and compare quality, time, and cost.

Then move a representative workflow to another harness. Check whether it can use the exported memory, preserve permissions and approval rules, and resume interrupted work. The effort required to make that workflow run belongs in the cost of adopting the platform, even if it never appears on the vendor’s invoice.

Frequently asked questions #

What is an agent harness?

An agent harness is the software around a model that manages an agent’s work. It calls models and tools, keeps track of what has happened, holds memory, and enforces rules, such as approval checks, before an action goes ahead.

Does a platform that offers several models prevent vendor lock-in?

Not by itself. A platform can offer a choice of models while still holding the memory and operating rules on which a product depends. Changing the model leaves that dependence in place.

Can agent memory be moved to another platform?

Only with work. An exported memory store is useful only if the replacement harness can interpret it, retrieve the relevant parts, and supply them to the model. Session records, such as the encrypted items returned by OpenAI’s compaction endpoint, also need a plan for recovering the information elsewhere.

Does an open-weight model solve AI sovereignty?

It addresses dependence on the model provider, but does little by itself to make the rest of the application portable. Jurisdiction, operational autonomy, and supply-chain dependence still have to be assessed separately.

Sources #

• Harrison Chase, LangChain, "Your harness, your memory" (Chase's rebuilt email assistant).
• Anthropic, "Effective context engineering for AI agents" (prompt engineering to context engineering).
• Microsoft Learn, "Agent Harness", Microsoft Agent Framework (approval policies as a harness capability).
• Mitchell Hashimoto, "My AI Adoption Journey" (tools that tell the agent when it is wrong).
• Ethan Mollick, One Useful Thing, "A Guide to Which AI to Use in the Agentic Era" (same model, different harnesses).
• OpenAI, "Agents API" documentation (managed Codex harness, public beta).
• Microsoft Learn, "Agents in Microsoft Foundry" (hosted and bring-your-own agents).
• Google Cloud, "Agent Runtime" documentation (agents from several frameworks, custom containers).
• OpenAI, "Codex Prompting Guide" (recommended file-editing tool).
• Armin Ronacher, "Better Models: Worse Tools", July 2026 (tool schemas and Claude models).
• Pydantic AI, "Models and Providers" documentation (feature differences behind a shared interface).
• Vstorm, pydantic-deepagents repository and changelog, release of July 24, 2026 (local OpenAI-compatible services, compression fix).
• Luca Belli, Carnegie Endowment for International Peace, "Operationalizing AI Sovereignty Through Agency, Interoperability, and Openness", September 2026.
• European Commission, "Cloud Sovereignty Framework" (jurisdiction, operational autonomy, supply-chain dependence).
• OpenAI, "Compaction" documentation (encrypted compaction items).