Avoiding Vendor Lock-In When Building a Composable Engineering Stack

Composable architecture was supposed to end vendor lock-in by replacing one giant platform with many small, swappable parts. In practice, teams that assemble best-of-breed stacks still get trapped, just across more surfaces at once, and the trap is harder to see because no single vendor appears to hold all the leverage.

The failure mode of the monolithic platform is well understood by now. Customer data goes into proprietary formats, and getting it back out means re-exporting, re-mapping schemas, and rebuilding every downstream connection by hand. Teams that lived through this with customer data platforms have a name for the pattern: the fly trap. Getting in takes an afternoon. Getting out takes six months and a consultant. Composable stacks were the industry's answer to that specific failure, built on the premise that no single vendor should ever again hold that much of the exit cost.

But swapping one monolith for a dozen specialized vendors doesn't remove the lock-in. It distributes it. More components means more contracts, more data boundaries, and more seams where a vendor can quietly build leverage without ever offering a single all-or-nothing platform. The question "are we locked in?" stops being answerable at the level of a vendor name, because a platform might hold nothing but your orchestration logic, which is cheap to replace, or it might hold your agent traces, your skills, your compute budget, and your only viable path to inference, all at the same time, without ever selling itself as "the one platform."

The AI layer has made this sharper, not softer. AI vendor lock-in is a compound dependency problem that runs at every layer of the stack simultaneously: model behavior, workflow automation, training data, compliance evidence, and operational expertise can all tangle up with a single vendor at once, and each one of those creates its own independent switching cost. Those costs don't average out. They compound. A team can be fully portable on inference and still be trapped on data, or free on orchestration and stuck hard on compute. The only way to find out which is true is to stop asking the question once and start asking it per layer.

The layer model as a practical audit tool, not just an architecture diagram

The fix for an unanswerable question is to break it into smaller questions that do have answers. An agent or software factory stack breaks cleanly into seven layers: factory definition, data and context, compute, inference, improvement, orchestration, and access. Each layer carries its own switching cost: one layer might cost an afternoon to leave, another a year, and a single yes-or-no verdict about "lock-in" at the vendor level erases that distinction.

Three properties separate a layer that's genuinely portable from one that only looks that way. The layer should be open: it works with any model, any agent, and any hosting setup rather than just the vendor's own. It should be composable, so a team can adopt part of it without being forced to take all of it. And it should be defined in code: versioned, testable, and revertible, rather than living only inside a vendor's console where it can't be diffed or rolled back.

This model isn't specific to AI stacks. The same per-layer logic applies to the infrastructure and data layers underneath any engineering platform. The rest of this piece walks the stack from the AI-native layers down through CI/CD, infrastructure provisioning, and version control, asking the same question at each stop: what does it cost, concretely, to leave this layer, and who actually owns the thing that would need to move?

Factory definition and orchestration layers: the cheapest layers to exit, and why teams negotiate them hardest anyway

Teams spend the most negotiating energy on orchestration and factory definition, even though those layers are already the cheapest to leave. Orchestration launches, tracks, and steers agent runs, and is real work to migrate away from, but the scope of that work is bounded and well understood. That's why renting it from a managed platform is a reasonable choice, if the data those runs generate stays owned by the team rather than the vendor.

Factory definition holds prompts, agent configuration, and routing rules, and works the same way only if those assets live in code inside a repository the team controls. The switching cost there is low when the definition is a file: versioned, diffable, and revertible. But it gets severe the moment that same definition lives only inside a vendor's console, because leaving then doesn't mean migrating a file, you have to retype an entire operating model from memory.

The common mistake follows directly from misreading which of these two layers is actually expensive. Teams negotiate hard on orchestration pricing, squeezing a vendor on per-run costs or seat counts, but then they hand over agent traces and memories without ever asking for a data ownership clause. Teams put optimizing pressure on orchestration, which was never the risk, while the data and context layer, which actually accumulates irreplaceable value, walks out the door unprotected.

Data and context layers: the accumulated learning that cannot be bought back

The data and context layer, covering agent traces, memories, skills, and audit logs, is the most expensive layer in the entire stack to leave, because it holds accumulated learning that no contract renegotiation can buy back once it's gone. A new vendor can stand up new compute in a week. No one can hand a team back eighteen months of agent traces that never left the old vendor's database in portable form.

The terms that separate a portable data arrangement from a proprietary one are specific: traces, memories, evals, and audit logs need to be exportable, hosted inside the team's own boundary where required, covered by zero data retention commitments, and never used to train the vendor's models on the team's content, and these are contractual requirements to insist on before the first serious run touches the system.

There's a quieter risk inside this layer that has nothing to do with contracts. In agentic workflows, LLM-generated code can introduce provider-specific services or APIs before any developer has consciously chosen an ecosystem. The lock-in gets written into the codebase by the agent itself, as a side effect of generating working code quickly, well before a human makes a deliberate vendor decision.

Much of the industry's current agent architecture makes this worse by default. The common agent loop, a monolithic system prompt replayed on every single turn, tool calls parsed out of XML with regular expressions, and destructive middle-truncation when context runs out, reflects a set of token-economics decisions made by omission rather than by design. Each of those omissions is also, quietly, a lock-in decision, because each one couples the team's workflow logic to the specific shape of one vendor's inference window. If you want to own this layer, you need zero data retention, no training on team data, and storage inside the team's own boundary, as baseline terms rather than negotiable extras.

Inference and compute layers: where a single provider can gain pricing power over your engineering budget

Inference and compute are where a single vendor can win lasting pricing power over an engineering budget, because model capability and cost shift month to month, and the ability to re-test and re-route across providers is worth more over time than picking the single best model once and standing still.

The practical exit test for inference is a question a team can ask its vendor directly: can it run a model it doesn't sell them? That includes frontier models and open-weight models, reached through a team's own API keys, a neo-cloud, a hyperscaler, or a self-hosted fine-tune. If the honest answer is "our models only," inference lock-in is total, regardless of how the contract describes itself.

The Model Context Protocol, now governed under the Agentic AI Foundation, a directed fund inside the Linux Foundation, gives you a concrete path around this. MCP creates a vendor-agnostic interface for AI agents to reach tools, data sources, and external systems, so an agent built on MCP-standard connectors can run on any model provider and any orchestration framework that supports the standard. That turns what would otherwise be a full architecture rebuild into a migration of workflow logic, a smaller and more bounded job.

Compute carries a similarly high switching cost when a team can't self-host. The right posture is to own compute, or at minimum keep it self-hostable, so a hyperscaler's pricing change doesn't force an unplanned rebuild on someone else's schedule. The improvement layer, covering scorers, replay tooling, and benchmarks, sits in the middle: moderate cost to migrate, reasonable to rent, as long as the underlying evaluation data stays owned and usable to rebuild the layer elsewhere if the vendor relationship ends.

Merge queue and CI/CD layers: platform-native queues and the event-based decoupling that keeps CI portable

The same layer-by-layer logic that applies to the AI stack applies just as cleanly to CI/CD. Platform-native merge queues from GitHub, GitLab, and Bitbucket are the honest default for teams already running on those platforms, and the insight that matters here is that queue management and CI provider don't have to be coupled together.

A merge queue's job is to order approved pull requests for integration and revalidate each one in sequence before it lands, so it cuts down on merge races, repeated rebases, and wasted CI runs on repositories with heavy automation. GitHub Merge Queue ships natively inside branch-protection rules, it creates gh-readonly-queue/ refs, and it supports configurable minimum and maximum merge-group sizes that control how many pull requests merge together at once. Any CI system that runs on the merge_group event just participates automatically, with no separate integration step needed.

GitLab Merge Trains work the same way, wired tightly to GitLab Pipelines, rebasing each merge request on top of the one ahead of it and running the pipeline for each in turn, which makes it the natural choice for teams already standardized on GitLab CI. Bitbucket Merge Queues reached general availability in 2026 for Standard and Premium plans, automating, sequencing, and validating pull request merges so that every change lands on a green, production-ready main branch. That closes a feature gap, one that had pushed Bitbucket users toward third-party merge-queue tools just to get the same guarantee.

Both GitHub's and GitLab's queues integrate with any CI system that triggers on their respective queue-branch events, so queue management and CI provider are decoupled at the event interface rather than locked together at the platform level. A team can swap its CI provider without touching its merge queue, or the reverse, because the two talk to each other through an event, not a proprietary contract.

Agentic pipelines change what a human does at this layer without changing the layer's portability logic. When an agent operates the merge queue, it handles merge conflicts, CI failures, and queue management directly, and humans step in only for decisions that actually require judgment. The queue layer still needs to be evaluable and replaceable on its own terms, independent of whatever CI system sits next to it.

GitOps engines and infrastructure provisioning: the open-source layer where portability is already the standard

One level down the stack, at infrastructure provisioning, the portability problem is largely already solved if teams build on the open tooling rather than on a cloud provider's proprietary equivalent. GitOps has become the standard way to manage cloud-native systems, making Git itself the single source of truth for what's deployed where, and by 2026 that practice is treated as foundational infrastructure hygiene rather than an optional discipline.

Argo CD, a CNCF-graduated GitOps continuous delivery tool, continuously watches Git repositories and automatically applies changes to Kubernetes clusters as soon as it detects drift between the declared state and the live one. Flux CD, also CNCF graduated, takes a more granular approach, running as a set of composable, modular controllers inside the cluster itself: a source controller, a kustomize controller, a helm controller, a notification controller, plus image reflector and image automation controllers. Teams can mix and match those controllers independently, so Flux is the more finely composable of the two engines, but that doesn't make Argo CD any less standard a choice.

Crossplane extends Kubernetes further, letting teams provision and manage cloud resources using declarative YAML and kubectl the same way they'd manage any other cluster resource. It's open-source, vendor-neutral, backed by the CNCF, and able to use existing Terraform providers underneath it, which is what actually protects a team from cloud provider lock-in at the provisioning layer rather than just promising to.

OpenTofu, governed by the Linux Foundation and the CNCF and built to be compatible with Terraform, has become the recommended open-source infrastructure-as-code option in 2026 stacks specifically as a hedge against HashiCorp's licensing change. That's a clean, concrete illustration of the whole argument in miniature: one vendor's licensing decision altered the portability calculus for an entire layer of the industry almost overnight, and the teams that had already built on open, composable tooling were the ones who didn't have to scramble.

Code storage and version control: where Git's portability ends and hosting lock-in begins

Version control sits at the foundation of the stack, and it's the one layer where portability isn't something a team has to engineer. Git's distributed architecture means every contributor holds a full local copy of the repository's history, so the data is never held hostage by a single host. The branching model and the portability it enables have been proven across every major hosting provider for years.

Lock-in reasserts itself one level up, in the hosting layer sitting on top of Git. Pull request workflows, CI event integrations, permissions models, and package registries are all features of the hosting platform, not of Git itself, and they're exactly where switching friction accumulates even though the underlying repository stays perfectly portable.

Gitea has become the closest thing to a de facto standard for teams choosing to self-host as of 2026. It runs as a single binary written in Go, starts comfortably on roughly 512MB of RAM, and ships with pull requests, an issue tracker, a container registry, a package registry, and Gitea Actions for CI/CD that's mostly compatible with GitHub Actions. That last detail is the one that actually matters for portability: because the Actions syntax carries over, a team can self-host now and migrate its CI later without rewriting its pipelines from scratch.

Code storage for cloud-native agentic workflows carries different performance demands than tooling built for human developers. Agents read, write, and query repositories at throughput and latency profiles that no human contributor approaches, so the hosting layer needs to be evaluated against those access patterns directly, not just against the developer experience metrics that have historically driven the choice.

The access layer sits above all of this, and it's the cheapest layer in the entire framework to exit. Slack, Linear, GitHub, and MCP entry points are all cheap to swap when they're API-first, but that cheapness holds only when the CI and repository integrations underneath them are kept separate from the hosting platform instead of quietly welded to it. A team can replace its chat tool or its issue tracker in an afternoon. Whether it can replace what sits beneath them depends entirely on the layer-by-layer audit this piece has walked through, not on how composable the stack looked on the architecture diagram.