The Lock-In Trap, in 2026

Two things became true at the same time over the last twelve months. First, every major cloud now sells “managed AI agent” services — Bedrock AgentCore, Vertex AI Agent Builder, Azure AI Foundry agents — and each comes with its own SDK, its own runtime contract, its own observability story, and its own bill. Second, every enterprise AI buyer started asking the same question in procurement: can we run this somewhere else if we need to?

The first trend hands you velocity. The second hands you the bill for that velocity, in the form of a six-figure migration project the day a regulator, a board member, or a CFO decides the answer to “somewhere else” matters. Multi-cloud is no longer a checkbox. For AI workloads — where the unit cost of inference is volatile, where regulatory geography matters, and where the marginal cost of being wrong is your data leaving your jurisdiction — it is the architecture.

This is the runtime pillar of what we have been calling private AI : a complete stack — workbench, runtime, governance — that runs inside the cloud you already trust. The runtime piece is where “BYOC” (bring your own cloud) stops being a marketing phrase and starts being a deliberate architecture choice. But “multi-cloud” is one of the most abused words in our industry. Let’s define what it means for AI runtimes specifically, and what it takes to actually do it.

What Multi-Cloud Actually Means for AI Workloads

Multi-cloud for AI is not “we can deploy a Helm chart to EKS and GKE.” That is multi-cluster. Multi-cloud is the harder thing: a single application manifest that runs on EKS, GKE, AKS, or vanilla Kubernetes without the developer knowing or caring which cloud is underneath, and with the cloud-native managed services (Postgres, Redis, queues, object storage) substituting cleanly per environment.

For AI agents specifically, that means three additional things:

1. Model routing is cloud-agnostic. Your agent calls “claude-4-7” — not “bedrock.anthropic.claude-opus-4-7.” Where the call lands depends on the environment, the region, and your policy layer, not on a hardcoded provider in the agent.

2. Identity federates across clouds. A workload identity in AWS IAM maps to a Workload Identity in GCP maps to a Managed Identity in Azure, with the same policy scope. The agent does not know which one it has — it just knows it is allowed to talk to its tools.

3. State is portable. Your agent’s durable execution log, its vector store, its conversation history — these live on a substrate that exists on every target cloud, with the same API and the same backup story. Otherwise migration is theatrical.

If any of these three is broken, you do not have a multi-cloud runtime. You have two single-cloud runtimes and a press release.

The Three Hard Parts

Kubernetes abstraction beyond “it’s all just Kubernetes”

The first lie cloud teams tell themselves is that Kubernetes is the abstraction. It is an abstraction — over compute scheduling — but the parts that matter operationally (IAM, ingress, storage classes, load balancers, DNS, secret managers) are still cloud-specific. EKS gives you ALB ingress, IRSA for IAM, EBS for storage. GKE gives you GCLB ingress, Workload Identity for IAM, PD for storage. AKS gives you AGIC, Managed Identity, Azure Disk. The Kubernetes objects look identical. The annotations, the controller behavior, and the failure modes do not.

A real multi-cloud platform needs a typed provider plugin model: a contract that says “this is what an ingress is, this is what a load balancer is, this is what a workload identity is” and lets each cloud plug in its native implementation. The application manifest references the abstract kind. The plugin translates.

Networking and DNS that does not assume one cloud

Multi-cloud DNS is harder than people admit. Your platform install has a base zone — call it myastrolift.net for the SaaS, or platform.acme.com for a self-hosted install. Every tenant app lives at *.<org>.<base-zone>. The base zone is not hardcoded. Mobile apps, CLIs, and web clients discover it from a .well-known/ endpoint. Self-hosted operators pick their own. A single platform install can host multiple base zones simultaneously, and your DNS provider — Route 53 in one install, Cloud DNS in another, Azure DNS in a third — is a plugin.

mTLS between control plane and data plane, certificate rotation, ingress policies — these all have to be cloud-pluggable. The application developer should never have to know.

State portability without “we’ll just sync the databases”

Vector stores are now first-class production infrastructure. So are object stores, queues, and durable execution logs (Temporal histories, for many teams in 2026). A multi-cloud AI platform has to answer the storage question with one of two strategies:

• Managed service brokerage. Your abstract kind is Postgres. On AWS the platform provisions RDS. On GCP, Cloud SQL. On Azure, Azure Database. The application reads a single connection string from a single secret manager kind. The provider plugin handles the rest, including snapshots and restore.

• In-cluster operators. For workloads that need true portability — air-gapped installs, sovereign-cloud installs — the platform runs the database itself, via an operator (CloudNativePG, for example), with the same API on every cloud.

Both strategies have to coexist. Some installs prefer managed services. Some — defense, healthcare, regulated finance — cannot use them. The platform has to support both behind the same manifest.

GitOps Is the Common Denominator

The one piece of plumbing that genuinely is cloud-neutral, and that makes multi-cloud feel possible at all, is GitOps. A repo, a controller, and a reconciliation loop. The repo describes desired state. The controller — Argo CD, Flux, or a platform-native equivalent — drives the cluster toward it.

For AI agent deployments, GitOps is the unlock. A pull request changes a manifest, the preview environment spins up automatically, a reviewer approves, the controller reconciles, the audit log records every step. Roll back is a git revert. Drift detection is built in. The same repo describes deployments on every cloud.

This is also where governance hooks in cleanly. The preview environment’s policies are the same as production’s — because the manifest is the same. A policy violation in a PR is a CI failure, not a Friday-afternoon Slack page from compliance.

Where Astrolift Sits

Astrolift is the multi-cloud AI runtime that operates on this premise. The shape, briefly:

• Provider plugin model. AWS / EKS, GCP / GKE, Azure / AKS, and a vanilla-Kubernetes provider for on-prem, air-gapped, or sovereign installs. The abstract kinds — Ingress, ManagedPostgres, ObjectBucket, WorkloadIdentity — are defined once and translated per cloud.

• One manifest, any cloud. astrolift.toml describes your application. Portable mode says “I do not care which cloud” and the platform picks. Cloud-pinned mode says “I need this specific provider variant.” The variant resolution is explicit and recorded in the audit trail.

• Deep multi-tenancy. Org → Team → Project → App. RBAC + ABAC with custom roles and scope filters. The same identity model your governance layer reads.

• Preview environments per pull request. Spun up automatically on the same cloud as production (or a different one — your call). Same manifest, same policies, real provider variants. No mocked dependencies.

• GitOps delivery. Optional Git-driven CD topology. Drift reconciliation. Magic-link approvals for gated promotions. Deploy tokens for CI.

• Durable workflow runtime. Temporal-backed for agents that need to survive restarts, retries, long-running tool calls, and human approval steps mid-flight.

The point of naming any of this is not “use our platform.” It is to make concrete what a real multi-cloud AI runtime needs to provide so that you can evaluate whether the thing you are building (or buying) actually does.

When Multi-Cloud Is Worth It

Multi-cloud has a real cost: more abstractions, more provider plugins to maintain, more edge cases per release. It is worth it when:

• You serve regulated geographies. EU data residency, sovereign cloud (Bleu, S3NS, Microsoft Cloud for Sovereignty), or air-gapped government installs each need a different substrate. One codebase, multiple substrates, beats N codebases.

• You expect M&A. When you acquire a company on the other cloud, the question is “can you migrate them in 90 days?” — not “what is your three-year integration plan?”

• Your inference economics are volatile. Bedrock pricing changed three times in 2025. Vertex inference offerings shifted in early 2026. If your runtime is portable, you arbitrage. If it is pinned, you absorb.

• Your buyers ask the procurement question. They are asking it. They will keep asking it.

It is not worth it when you are a startup in a single jurisdiction with one product and no regulated buyers. In that case, pick one cloud, ship faster, and revisit when the cost of staying pinned exceeds the cost of becoming portable. Multi-cloud done late is expensive. Multi-cloud done early, by a team that does not need it yet, is also expensive.

What to Build First

If you are starting on a multi-cloud AI runtime today, the order that has worked for us:

1. One cloud, end to end. Get a real platform install on one cloud with a real workload. Do not start with abstraction; start with reality.

2. Define the abstract kinds. Once you have one cloud working, write down what your abstractions are. Ingress, Postgres, Identity, Bucket, Secret. Resist over-abstracting; let the second cloud teach you what the abstraction needs to flex.

3. Add the second cloud. Real install, real workload, same manifest. This is where the abstractions get hammered. Most of them survive; a few need redesign.

4. Add the vanilla Kubernetes provider. This is the forcing function. If your platform runs on bare-metal Kubernetes with in-cluster operators standing in for managed services, you have actually built portability — not just multi-cloud-managed-services.

5. Then add preview environments and GitOps. These are the last 20% of the work that delivers 80% of the developer experience.

Most platforms skip step 4 and call themselves multi-cloud. They are not. They are multi-cloud-managed — which is useful, but is not portability. The day a sovereign-cloud RFP lands, the difference matters.

Closing

In May 2026, the AI infrastructure conversation is shifting from “which cloud” to “how do we stop the cloud from mattering.” Multi-cloud AI runtime is not a feature. It is the architecture decision that determines whether your stack has a five-year horizon or a two-year one. Pick the abstraction. Build for portability. Make the cloud a detail.

Next in this series: giving internal teams a Lovable / Railway experience inside your own cloud , and then real-time GRC for AI agents — and why the EU AI Act’s August 2026 deadline is closer than your roadmap thinks.