What travels, what you rewrite, what you re-earn
Lesson 2 of 5 in Choosing a Cloud for Agents: A Decision You Can Defend.
"Are we locked in?" is the wrong question, because the answer is always yes and always no. The useful question is what would a move actually cost, layer by layer — and the answer is remarkably consistent across all three clouds: the parts you thought were the product travel almost for free, and the parts nobody put on a slide are the ones that anchor you.
Think of it as a stack. The top of the stack is yours and moves with you. The bottom is wired into a specific cloud’s directory, network and policy engine, and moving it means re-earning approvals you already fought for once.
The portability stack — top moves free, bottom anchors you
- Prompts, skills, evals, golden datasets — moves for free — keep it in your repo
Your system prompts, task decompositions, golden datasets, graders and rubrics are plain files. They are also the highest-value asset you own, because they encode what "good" means for your business. Every platform will happily run them; none of them will give them back to you in a nicer form than the one you already have. Rule: these live in your source repository, never only in a portal.
- Framework and loop code — moves with a redeploy
The loop itself is the most portable executable layer, because all three platforms deliberately run other people’s frameworks. AWS states AgentCore is framework- and model-agnostic — CrewAI, LangGraph, LlamaIndex, Strands. Foundry hosted agents accept containers or source zips built with Microsoft Agent Framework, LangGraph, the OpenAI Agents SDK, the Anthropic Agent SDK, the GitHub Copilot SDK or custom code. Google’s Agent Runtime supports ADK, A2A, LangChain, LangGraph, AG2, LlamaIndex and fully custom agents, and ADK code can also target Cloud Run, GKE or a self-hosted container.
- Tool surface (MCP and OpenAPI) — mostly travels — the waist of the stack
MCP is doing real work as a portability layer. AWS’s Gateway turns APIs, Lambda functions, Smithy models and existing MCP servers into MCP tools for any MCP-capable agent. A Foundry Toolbox puts curated tools behind a single managed MCP-compatible endpoint that Microsoft describes as Foundry-homed, not Foundry-bound — consumable by Agent Framework, LangGraph, the GitHub Copilot SDK or a custom MCP client. ADK treats MCP tools as a first-class tool type. What does not travel is the registration, credential and approval wiring around each tool.
- Telemetry and memory records — shape travels, contents do not
Traces are the good news on two of the three: AWS emits OTel-format telemetry to CloudWatch and Foundry stores traces in Application Insights using the OpenTelemetry gen-AI semantic conventions, while Google Cloud’s documented path is Cloud Trace and Cloud Logging — confirm the wire format before you assume your OTel collector can fan out from it. Those same two explicitly ingest telemetry from agents running elsewhere — AWS documents observability for on-premises and multi-cloud agents, and Foundry supports registering external agents so spans carrying a matching agent id land in Application Insights for trace-based evaluation. Memory is the bad news. AgentCore Memory has short-term events plus strategy-extracted long-term records in actor namespaces; Google Cloud splits Sessions from an LLM-generating Memory Bank; Foundry has durable conversations plus a keyed state store. Three different record models, no interchange format.
- Identity, policy and network wiring — rewrite plus re-approval — the real anchor
This is where lock-in actually lives. Agent identity is native per cloud: Entra agent identities (a special kind of service principal, created from blueprints, with an optional human sponsor) and OAuth 2.0 on-behalf-of on Foundry; IAM-based agent identity on Google Cloud; AgentCore Identity with a token vault, workload access tokens and an IAM execution role on AWS. Policy expression differs just as much — Cedar policies evaluated at the AgentCore gateway, guardrail controls with tool-call and tool-response intervention points in Foundry, natural-language semantic governance policies over tool calls on Google Cloud. Then add the network: injected VNets and private endpoints, VPC Service Controls, private connectivity interfaces. Moving this layer is not a port. It is a new security review.
Read the stack again and notice the inversion. Teams agonise over the top two tiers — which framework, which SDK — and those are the cheapest things in the picture. Nobody argues about the memory record schema or the policy language, and those are the expensive ones.
The practical response is not to avoid managed services; it is to buy them deliberately, at a price you have named. Below, the same layers as a decision matrix: verdict, the sourced reason, and the one thing to do today that keeps the option open at almost no cost.
| Layer | Verdict | Why (as documented, September 2026) | Cheap insurance to buy now |
|---|---|---|---|
Framework / loop code | Travels | All three platforms run third-party frameworks by design: framework- and model-agnostic on AgentCore; container or source-zip hosted agents on Foundry with several named SDKs; ADK, LangChain, LangGraph, AG2 and LlamaIndex on Google’s Agent Runtime. | Keep platform SDK calls behind one thin adapter module. If your graph nodes import a cloud SDK directly, the loop stops being portable for no benefit. |
Evals, goldens, graders | Travels | These are your files. AWS Evaluations is documented as working for agents on Runtime, Lambda, EKS or non-AWS environments; Foundry runs trace-based evaluation over registered external agents; Google Cloud offers Gen AI evaluation in the Agent Platform. | Store goldens and rubrics in git next to the agent. Portal-authored evaluation sets are the single most commonly stranded asset in a migration. |
Tool definitions | Mostly travels | MCP is the common waist: AgentCore Gateway converts OpenAPI, Lambda, Smithy and MCP targets into MCP tools; Foundry Toolboxes expose an MCP-compatible endpoint explicitly consumable by non-Foundry runtimes; ADK supports MCP and OpenAPI tools. | Define tools once as MCP servers or OpenAPI specs you own, and let the platform gateway front them. Tools authored inside a platform’s tool designer do not have a file to carry away. |
Traces and metrics | Travels in shape | Foundry stores agent traces in Application Insights using OpenTelemetry generative-AI semantic conventions; AgentCore Observability is OTel-compatible with documented third-party destinations; Google Cloud uses Cloud Trace and Cloud Logging. | Emit OTel spans with the standard gen-AI attributes and, if a second backend matters to you, fan out at the collector. Dashboards are cheap to rebuild; a year of history in a proprietary shape is not. |
Managed memory | Locks in | Three incompatible models: AgentCore short-term events plus strategy-extracted long-term records in actor/session namespaces; Google Cloud Sessions plus a Memory Bank that uses generative models to produce memories; Foundry durable conversations plus a keyed JSON state store. Extraction is asynchronous and model-driven, so the derived records are not reproducible byte-for-byte elsewhere. | Decide whether long-term memory is a differentiator or a convenience. If it is a differentiator, keep the canonical facts in your own store and treat platform memory as a cache. |
Platform tool and data integrations | Locks in — and that is often the point | These are the genuinely differentiated surfaces: Foundry’s catalog connectors and managed MCP servers plus SharePoint-class enterprise tools; Gemini Enterprise’s permissions-aware search over connectors such as Confluence, Jira, SharePoint and ServiceNow; AgentCore Gateway’s managed web search that AWS describes as keeping data inside your AWS environment. | Name them in the decision record as chosen dependencies with an estimated replacement cost. Accidental dependency is the failure; deliberate dependency is a purchase. |
Identity, policy, network wiring | Locks in hardest | Native to each cloud’s directory and policy engine, and partly irreversible: Microsoft documents that Foundry network injection is set at account creation and cannot be changed later. Every tool scope, delegation flow and egress rule is re-expressed in a different language on the other side. | Write the invariants down in vendor-neutral language first (lesson 3), so a move re-implements a specification instead of reverse-engineering a console. |
All three vendors have already moved a declarative agent layer under someone’s feet
This is not a knock on any one cloud — it is the base rate of the category, and it is the strongest argument for keeping your differentiated work in files you own.
AWS. The original Amazon Bedrock Agents (November 2023) is now Agents Classic, closed to new customers from 30 July 2026 and in maintenance mode with no new features planned. AWS is explicit that there is no migration deadline and no planned end-of-life date, and that Bedrock itself, Knowledge Bases and Guardrails are unaffected — but the recommended paths forward are the managed AgentCore harness or code-defined agents on AgentCore.
Microsoft. Foundry’s visual workflows (preview) are being retired on 1 December 2026, with migration pointed at Microsoft Agent Framework, Azure Logic Apps or direct A2A connections. Separately, Agents (classic) — the Assistants-style thread/run/message service — is deprecated with retirement announced for 31 March 2027.
Google. Vertex AI Extensions is deprecated, with shutdown after 26 November 2026, and the Vertex AI documentation now carries a banner that it is no longer being updated because those services are part of the Gemini Enterprise Agent Platform.
Notice the pattern in what survived each transition: framework code, tool specifications, prompts and evaluation sets. What needed rework was configuration that lived only inside a platform’s designer.
Myth: "our framework is portable, so our system is portable"
Framework portability is real and it is the cheapest tier of the stack. It is also not what a migration is made of.
Move a LangGraph agent from one cloud to another and the graph compiles on day one. Then you re-register every tool, re-issue every credential through a different broker, re-express every scope in a different policy language, re-approve the network path, rebuild the trace pipeline, and decide what to do about two years of extracted memories that have no export format. The graph was never the problem.
Use framework portability for what it is actually good at: it keeps local development honest, it lets you run the same agent in CI without the platform, and it means an SDK-level regret costs a redeploy rather than a rewrite.
Myth: "multi-cloud from day one avoids lock-in"
Running the same agent on two platforms doubles the identity planes, policy languages, trace backends and on-call runbooks you maintain — and you still cannot move the memory records. Teams that try this early usually converge to the lowest common denominator: no managed memory, no platform tools, no delivery-surface integration. That is a legitimate architecture, but it is self-hosting with extra steps, and you should choose it on purpose (lesson 5 has an outcome for exactly that) rather than arriving at it as a compromise.
The cheaper hedge is asymmetric: one primary platform, plus the four insurance policies from the matrix above — adapters, files in git, MCP-defined tools, OTel-shaped telemetry.
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.