Choosing a platform without regretting it

Four weeks to name a platform — AWS AgentCore, Microsoft Foundry Agent Service, Google’s Agent Platform (formerly Vertex AI), or self-hosting your framework. The recipe: five questions that actually decide it, a two-week bake-off on your own golden set, a ledger of what ports and what anchors you, and the exit plan you write on day one.

Here is the situation this recipe assumes, because it is the one that keeps showing up.

Five engineers. A LangGraph prototype that already does something useful — reads a supplier-invoice exception, checks the ERP, drafts a resolution, and asks a human before it files a credit-memo request. Procurement needs a platform name in four weeks so the commitment lands before the quarter closes. And the inputs contradict each other: the company runs Microsoft Entra for every employee identity, six terabytes of scanned invoices and the ERP read replica already sit in AWS, there is a three-year AWS committed-spend agreement, a contract clause says customer data stays in the EU, and nobody on the team has ever operated Kubernetes.

Left alone, that meeting goes one of two ways. Either the loudest engineer wins on developer experience, or three vendor SAs each build a beautiful demo and you pick the one whose demo you saw last. Both produce a choice you cannot defend in six months, when the regret arrives in a form nobody predicted: not "the runtime was slow" but "our whole authorization story is written in one cloud’s policy language and legal wants the agent in another."

So the deliverable of this recipe is not a platform. It is three artefacts:

a one-page decision record — the five questions, your evidence, the shortlist, the pick, and the two things that would change it
a two-week bake-off result — the same thin slice built twice, measured on your golden set, with numbers you gathered yourself
an exit plan, written on day one, before you are emotionally invested

The theory under all of this is taught elsewhere on the site and this note does not repeat it: Choosing a Cloud for Agents: A Decision You Can Defend carries the weighted axes and the portability stack, The Cloud Agent Landscape: Three Managed Platforms, One Map puts the platforms side by side, and the three deep dives — Amazon Bedrock AgentCore, Service by Service, Microsoft Foundry Agent Service, Three Ways to Run an Agent, and Google’s Agent Stack: ADK, Agent Runtime, and the Names That Keep Moving — tell you what the parts are called. Read this one when you have to actually run the process.

Week one is a research task, not a build task. Five questions, five artefacts, no vendor calls yet — and a question earns its place only if a plausible answer would rule an option out. "Which has the nicer SDK?" rules nothing out; it belongs in the bake-off, where it becomes a number instead of a preference. Most teams find the shortlist is down to two before anyone opens a console.

Current as of September 2026

Every platform capability named here traces to AWS, Microsoft or Google documentation checked in September 2026, and this surface moves faster than anything else on the site. Inside about a year: Azure AI Foundry became Microsoft Foundry; Google’s own docs now say "Vertex AI documentation is no longer being updated. Vertex AI’s services are now part of Gemini Enterprise Agent Platform", with the managed runtime formerly documented as Agent Engine presented as Agent Runtime; and AWS put Bedrock Agents Classic into maintenance mode while AgentCore went generally available on 13 October 2025.

This is an educational resource, not vendor documentation. The durable part is the method — the five questions, the bake-off protocol, the port/anchor ledger, the exit plan. Treat every capability sentence below as a question to re-ask against current docs for your region and your account, and note where this note deliberately stops: wherever no published source settles a comparison, you get a question to put to the vendor instead of an answer.

Key terms: lock-in, data gravity, agent identity, egress control, golden dataset, OTel

The five questions — and the artefact that settles each one. Capability statements are from vendor docs checked September 2026; verify for your region and account.
Question	The artefact that answers it (one afternoon each)	How the answer prunes the list
1 · Where does the data already live?	A table of the ten sources the agent must read or write: size, owner, physical location, and who would have to sign off on moving it. Pull it from your inventory, not from memory.	Six terabytes of documents do not move; the agent does. Running the loop in a different cloud from the corpus means paying egress and a round trip on every retrieval, plus a second set of credentials to reach across. In our example this axis points hard at AWS and it is the heaviest single input.
2 · Which identity provider do you already run?	The name of the employee IdP, the name of the authorization system your downstream APIs actually check, and the name of the person who approves a new service principal. One screenshot and two names.	This is the least portable layer you will build, but it is not an automatic verdict. Foundry gives each hosted agent a dedicated Microsoft Entra identity and, with a user token present, OAuth 2.0 on-behalf-of for delegated calls; Google Cloud documents IAM-based agent identity on Agent Runtime; AWS documents two patterns — IAM SigV4 for callers inside the AWS boundary, or inbound OAuth JWT validated against an authorizer you configure with an IdP discovery URL and allowed clients, naming Amazon Cognito, Okta and Microsoft Entra ID, with outbound OAuth tokens and API keys brokered from a KMS-encrypted token vault. So an Entra shop is not mechanically a Foundry shop. The question to put to each vendor: for our IdP, on this platform, exactly which flow gives the agent a delegated user token — and what breaks when the user’s session expires mid-run?
3 · What have you already committed to?	Four quarters of spend by provider, the text of any committed-spend agreement, and a list of where your account vending, network baseline and policy tooling already work.	A platform outside your landing zone means new accounts or subscriptions, new peering, new policy baselines and a new audit story — months of platform-team time that belongs in the comparison instead of being waved through. Do not let this become a price argument you cannot source: Google publishes Agent Platform pricing as three SKUs (Agent Compute at $0.085 per vCPU-hour, Agent Memory at $0.009 per GiB-hour, and Agent Storage) with a monthly free tier of 50 vCPU-hours, 100 GiB-hours and 1 GiB-month, and states that Runtime idle time between turns is not billed; AWS describes AgentCore as consumption-priced and metered per capability, with Runtime billing CPU consumed and peak memory per second. Compare metering shapes here and take the rates from the live pricing pages on the day you decide.
4 · What must never leave, and where must it stay?	The actual contract or regulator clause, pasted into a table with one row per component: runtime, memory, tool calls, traces, eval data. Not a summary of the clause — the clause.	All three publish controls here and the trap is component coverage, not headline support. Foundry Standard setups require bring-your-own Azure Storage, AI Search and Cosmos DB so agent data stays in your tenant, and its BYO virtual network wants a dedicated subnet delegated to Microsoft.App/environments, /27 or larger — with network injection set at Foundry account creation, not addable afterwards. Google lists VPC Service Controls, CMEK and data residency at rest for Runtime, evaluation, Sessions, Memory Bank and Code Execution — and not for Example Store. AgentCore went GA in nine regions including Frankfurt and Ireland, with VPC, AWS PrivateLink, CloudFormation and tagging support across its services at GA, and runs each session in a dedicated microVM. Walk your clause down the component list and make each vendor point at the doc page.
5 · What can this team write and operate at 3 a.m.?	The languages you ship to production today, an honest yes/no on container practice, and the on-call rota with names.	Language and packaging are real filters. Google’s ADK publishes Python, TypeScript, Go, Java and Kotlin SDKs and deploys to self-hosted containers, Agent Runtime, Cloud Run or GKE. Foundry hosted agents take a container image or a source .zip — Foundry builds the image — with Microsoft Agent Framework, LangGraph, the OpenAI Agents SDK, the Anthropic Agent SDK, the GitHub Copilot SDK or custom code. AWS states AgentCore is framework- and model-agnostic, naming CrewAI, LangGraph, LlamaIndex and Strands Agents, and not tied to models hosted on Bedrock. Notice which happy paths begin with a Dockerfile, then look again at your rota.

Now the two weeks. The rule that makes a bake-off worth its cost is brutal and simple: the same thin slice, built twice, by your own engineers, measured on your own cases. Nothing else produces evidence. A vendor-built demo tells you what the vendor’s best engineer can do with their own sample data on their own laptop, which is not a fact about your team.

The slice is one path through the product, end to end, with the real integration and the real gate: read one exception, call the ERP with a delegated identity, draft the resolution, stop for approval, file the credit-memo request. Not the whole agent. One path that touches every layer you will later have to move.

The two-week bake-off — a run book, not a wish list

Day 0 — freeze the golden set and the slice spec
Thirty real exceptions from the last quarter, with the outcome a human actually chose, in a directory in your repo. Plus a one-page slice spec: the tools, the delegated call, the gate, the definition of done. If you cannot write the spec, you are not ready to compare platforms — you are still designing the agent. Eval Fundamentals: You Cannot Improve What You Cannot Measure is the prerequisite.
Still more than two candidates after the five questions?
Two is the number a five-person team can actually build twice in two weeks. Three means three half-built slices and no evidence. If the five questions did not get you to two, your weights are not written down yet — go back and write them.
Cut to two managed candidates plus a self-host baseline
The self-host baseline is not a candidate you intend to pick; it is your control group. Your LangGraph slice already runs on a laptop — deploy it on your existing container platform with your existing observability and record the same numbers. Without it you cannot tell how much of a managed platform’s value is real. LangGraph is MIT-licensed and runs standalone, Strands Agents is Apache-2.0 with an in-process loop and no hosted control plane, and Google’s ADK is open source and documents self-hosted containers as a target — self-hosting is a supported shape, not a rebellion.
Days 1–2 — build the slice on candidate A, in-house hands only
Your engineer, your keyboard, vendor docs and support tickets allowed, vendor engineers in the room not allowed. The ERP call may run on a stubbed credential for now — day 6 replaces the stub with the real flow — but every other part of the slice is real. Log every hour and every blocker in a shared file as you go. That log becomes the most persuasive page of the decision record, because it is the only artefact a vendor cannot produce for you.
Days 3–4 — the same slice, same engineer, on candidate B
Same order of operations, same tools, same prompts, same model family where you have the choice. Resist improving the design between builds; the second build is a measurement, not a redesign. Anything you learned on A that would change the design goes in the notes for later, not into B.
Day 5 — rebuild the slice on A in half a day
The single cheapest honesty control in this recipe. B always looks faster to build because you learned the problem on A. Rebuild A and compare the third number: if A-again is as fast as B, the gap you were about to write up as a platform difference was your own learning curve.
Day 6 — the identity task, against the real IdP and the real system of record
Make the agent read one record from the actual ERP as the actual requesting user, through the actual identity provider. No static key, no shared service account, no "we will wire that up later". This is where bake-offs go from encouraging to informative, and it is the task vendors are least often asked to demonstrate. Agent Identity, Auth, and Secrets is the material behind it.
Day 7 — the containment task: scope one tool, block one egress, prove the block
Give the ERP tool read access to exactly one account and prove the second account returns a denial. Then have the agent attempt an outbound call to a host you have not allowed, and screenshot the refusal. Foundry expresses egress controls for hosted agents inside the same guardrail as its other controls (in preview at this check); AWS evaluates Cedar policies over tool calls passing through AgentCore Gateway; Google documents natural-language semantic governance policies over tool calls for agents on Agent Runtime. Three different languages for the same idea — the containment ladder from Tool Scoping and Least Privilege: Making the Dangerous Thing Impossible.
Days 8–9 — golden set, three runs each, one model, recorded numbers
Thirty cases, three times, on each build, with the model pinned. Record five columns per platform: pass rate against your graders, p95 end-to-end latency, cost per run, tokens per run, and the number of times you had to read a trace to understand a failure. Averages of one run are decoration; three runs at least show you the spread. Cost and Latency Budgets You Can Defend has the measurement discipline.
Did anything get ruled out on evidence?
A ruling-out is a boundary control that does not exist for a component you need, an identity flow with no documented answer, or a region that is not on the list. It is not "the SDK annoyed me". If you have a real ruling-out, stop early and bank the week — you have your answer and a citation for it.
Day 10 morning — break it on purpose and read the traces
Kill the tool mid-run. Return malformed JSON. Blow the turn limit. Then answer one question on each platform, with a stopwatch: how long until you can say what the agent did and why it stopped? AWS emits OTel-format telemetry to CloudWatch and requires a one-time per-account enablement of CloudWatch Transaction Search before traces appear; Foundry stores traces in Application Insights using the OpenTelemetry gen-AI semantic conventions; Google documents Cloud Trace and Cloud Logging. Trace Anatomy: Reading an Agent Run Like a Professional is the skill you are timing.
Day 10 afternoon — decision record and exit plan, in the same commit
One page, five questions, the numbers, the pick, and the two findings that would reverse it. The exit plan ships in the same commit or it never gets written. The pick itself should feel boring by now — that is the sign the process worked.

1 · The vendor’s engineer built the slice

The most common way a bake-off produces a confident wrong answer. A vendor solutions architect can make any of these platforms look effortless, because they have built this slice forty times and they know which page of the docs is wrong.

Use them — for architecture review, for quota requests, for the awkward question nobody wants to ask in writing. Do not let them touch the keyboard during the timed build. What you are measuring is your team’s time-to-working-slice, and that is the number that will recur every sprint for the next three years.

2 · You ran the vendor’s sample data

Sample data is chosen to make the platform look good, and it will. Your golden set exists precisely because your exceptions are ugly: the scanned invoice with two purchase-order numbers, the one where the supplier changed name mid-quarter, the one where the correct answer was "do nothing".

Freeze thirty of those on day 0 and run the identical set on every candidate. If a platform’s built-in evaluation tooling only accepts data in its own format, that is a finding for the port/anchor ledger — not a reason to switch data sets.

3 · You measured one run and called it latency

One run gives you a number with no error bar, from a system whose defining property is non-determinism. Three runs of thirty cases is 90 data points per platform, which is enough to see whether a two-second p95 gap is a platform difference or noise.

Report the spread, not just the mean, and pin the model. A model swap between builds silently becomes the largest term in your comparison — and on all three platforms the model is swappable, so the temptation is real.

4 · You scored developer experience out of ten

"DX: 8/10" is a preference wearing a number’s clothes, and it is how the loudest engineer wins a decision meeting.

Replace it with things you actually recorded during the build: hours to first working slice, number of blockers that needed a support ticket, number of times the docs were wrong, hours to rebuild after the design changed, and minutes to answer what did the agent do from a trace. Those are still DX — they are just falsifiable.

5 · You counted a preview feature as load-bearing

Previews move, get renamed, and occasionally get retired. As of September 2026 the Microsoft Foundry portal is generally available with agents, publishing to Microsoft 365 Copilot and Teams, Routines and tracing for prompt and hosted agents GA — while workflows, the agent optimizer, Voice Live, tracing for workflow and external agents and several networking experiences remain in preview; hosted-agent egress controls and external-agent registration are documented as preview; and Microsoft has announced it is retiring visual workflows on 1 December 2026, pointing users to Microsoft Agent Framework, Azure Logic Apps or direct A2A connections. Google’s naming and launch stages in this area changed repeatedly between 2024 and 2026, so read the current launch-stage label rather than a blog post.

The rule: if your slice cannot pass its acceptance criteria without a preview feature, write that dependency on the front page of the decision record with the date you checked its status. Then re-check it before the commitment is signed.

6 · You skipped the identity and egress tasks because they needed another team

They always need another team, and that is the point. The two tasks you are tempted to defer are the two whose answers you cannot get from documentation and cannot cheaply reverse.

Concretely reversible: which framework you use, which model you call, how your prompts are written. Concretely not: Foundry’s BYO virtual network requires network injection set at Foundry account creation, and it cannot be added or changed afterwards. That single sentence has forced more than one team to rebuild an account after the pilot. Book the security and network people for days 6 and 7 in week one, before you know which platform you like.

The port/anchor ledger, written by one person while the slices build. "Are we locked in?" is unanswerable; "what would a move cost, layer by layer?" is a spreadsheet — and the layers nobody puts on a slide are the ones that anchor you. Each premium is nearly free on day one and unbuyable later. Platform statements from vendor docs checked September 2026.
Layer	How well it ports	The insurance premium you pay on day one
Prompts, golden sets, graders	Free. They are plain files, and they are also the highest-value asset you own, because they encode what "good" means in your business. All three platforms will happily run them: AgentCore Evaluations scores a session on demand against ReferenceInputs — expected responses, expected tool trajectories, behavioural assertions — and also samples live traffic; Foundry ships built-in evaluators including tool-call accuracy and task completion; Google’s Agent Platform includes evaluation and an Example Store.	They live in your repository, versioned with your code, and the platform’s eval tooling consumes them. The moment someone authors a case in a portal UI, that case exists in one cloud only. Regression Suites in CI: Evals That Run On You is the shape to copy.
Framework and loop code	Ports with a redeploy — deliberately. AWS states AgentCore is framework- and model-agnostic (CrewAI, LangGraph, LlamaIndex, Strands Agents) and not tied to Bedrock-hosted models; 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.	Keep every platform SDK call behind one thin adapter module that owns exactly four verbs: run a turn, read and write memory, fetch a credential, emit a span. Then a port is one file to rewrite instead of a grep across the codebase. The Framework Landscape: Pick One (or None) covers the choice underneath.
Tool surface (MCP, OpenAPI)	Mostly travels — MCP is doing real work as the waist of the stack. AgentCore Gateway converts APIs, Lambda functions, API Gateway stages, OpenAPI schemas, Smithy models and remote MCP servers into MCP tools, presenting attached MCP targets as one consolidated tool list; a Foundry Toolbox puts curated tools behind a single managed MCP-compatible endpoint that Microsoft describes as "Foundry-homed, not Foundry-bound" and that other runtimes can consume; ADK treats MCP tools as a first-class tool type. What does not travel is the registration, credential and approval wiring around each tool.	Own the tool servers yourself and make each platform a client of them. Pin the protocol revision you build against — MCP versions are dates marking the last backwards-incompatible change, and 2026-07-28 is current at this check — and keep the tool contracts and their scopes in your repo. MCP Fundamentals: One Protocol Instead of M × N Integrations is the underlying material.
Telemetry	The shape travels; the contents and the query language do not — and the standard itself is still moving. OpenTelemetry’s gen-AI semantic conventions are marked Status: Development, not stable, and have moved to a dedicated repository; the agent conventions define spans for create agent, invoke agent, invoke workflow, plan and execute tool. AWS emits OTel-format telemetry to CloudWatch (after a one-time per-account enablement of Transaction Search) and documents sending telemetry from agents hosted elsewhere via the ADOT SDK to its OTLP endpoint; Foundry stores traces in Application Insights on the gen-AI conventions and can register external agents so their spans land there for trace-based evaluation; Google documents Cloud Trace and Cloud Logging.	Instrument your own code with OTel rather than relying only on auto-instrumentation, and export to two sinks from day one: the platform’s backend and one you control. A self-hosted collector or Langfuse — which ingests OTLP over HTTP and aims to comply with the gen-AI conventions — costs an afternoon now and is the difference between keeping and losing a year of run history.
Managed memory	Anchors you, quietly, and the anchor grows every week you run. Three different record models with no published interchange format: AgentCore Memory holds short-term events plus long-term records extracted by configurable strategies (semantic, summarisation, user preference, episodic, custom) in actor and session namespaces; Google splits Sessions from a Memory Bank that uses generative models to generate memories rather than storing them verbatim; Foundry keeps durable conversations plus a keyed JSON state store with a 30-day idle window that can hold LangGraph or Agent Framework checkpoints.	Decide on day one whether memory is a product feature or a convenience. If it is a feature, write the facts you actually depend on into your own store as well and treat platform memory as a cache. And ask each vendor the question no pack answers: what is the documented export path for extracted long-term memory, in what format, and how do we test a restore? Memory Architectures: Engineering the Context at Scale is the design behind the answer.
Identity, policy and network wiring	Rewrite plus re-approval. This is where lock-in actually lives, and it is not a code problem. Agent identity is native per cloud — Entra agent identities with OAuth 2.0 on-behalf-of on Foundry, IAM-based agent identity on Google Cloud, AgentCore Identity with a token vault plus an execution role on AWS. Policy is expressed three ways: Cedar policies evaluated over every action through AgentCore Gateway, Foundry guardrail controls with tool-call and tool-response intervention points (both documented as preview for agents at this check), natural-language semantic governance policies over tool calls on Agent Runtime. Then the network: injected virtual networks and private endpoints, VPC Service Controls, PrivateLink.	Write the policy intent in a vendor-neutral table — principal, action, resource, condition, and the evidence that proves it holds — and treat each platform’s policy file as a translation of that table. The table survives a migration and a regulator asking what changed; the policy file does not. Moving this layer is not a port, it is a new security review.

Prune to a shortlist — this ends in a bake-off, not a verdict

Interactive decision tree — outcomes:

One candidate, ruled in by the clause
The cheapest outcome available and worth actively hunting for: the boundary requirement did the work and you have a citation instead of an opinion. Still run one build week — you are no longer testing which platform, you are testing whether the identity task and the operational hour actually work before you sign. Put the doc URLs and the date you checked them in the decision record, because component coverage changes.
Nobody covers the clause — self-host inside your own boundary
A legitimate answer, taken with open eyes: you inherit the runtime, session isolation, credential brokering, memory, tracing and eval plumbing that the managed services were selling. The open-source pieces are real — LangGraph is MIT-licensed and runs standalone, Strands Agents is Apache-2.0 with an in-process loop and no hosted control plane, Google’s ADK is open source and documents self-hosted containers as a deployment target, Langfuse takes OTLP over HTTP — but the on-call is yours. Set a review date: coverage expands (Google’s managed runtime added regions including Zurich, Milan, Seoul, Toronto and São Paulo through December 2025; AgentCore went GA in nine regions and reached AWS GovCloud US-West in May 2026), so this answer has a shelf life measured in quarters.
Your home cloud is the front-runner — bake it off against exactly one challenger
Data gravity plus landing zone plus commitments is the strongest alignment you will get, and the honest thing to do is name it as the front-runner rather than pretend the comparison is open. Then still build the slice twice: the challenger exists to price the front-runner’s weaknesses, and the self-host baseline exists to tell you what the managed layer is worth. Expect the front-runner to win and write down, in advance, the two findings that would change your mind.
Two candidates, one bake-off — this is the case the recipe exists for
Data in one cloud, identity or commitments in another. Do not let either axis auto-win on a slide: AWS documents inbound OAuth JWT authorisation against an authorizer configured with your IdP — naming Amazon Cognito, Okta and Microsoft Entra ID — plus outbound credentials brokered from a token vault, so an Entra estate does not mechanically decide the platform. Make the identity task on day 6 the deciding experiment: real IdP, real delegated call, real expiry behaviour, timed and written down.
The delivery surface is doing the deciding
When the users live in Teams, the publish path is a capability and not a preference: Foundry documents publishing an agent to Microsoft 365 Copilot and Teams by compiling a Teams app manifest, submitting it to the catalogs and enabling the Activity protocol, with organisation-wide scope requiring Microsoft 365 admin approval — and note the wrinkle that projects with public network access disabled must publish via REST, which opens a scoped, source-IP-filtered route for only the Activity protocol endpoint because Microsoft 365 cannot reach private endpoints. Run the slice anyway. A delivery surface is a strong axis, not an architecture.
Your control group might be the answer — for now
Small steady traffic, container practice, one agent: the managed platforms are selling you memory, identity brokering, sandboxes, eval and trace plumbing you can plausibly assemble. Price it honestly both ways — Google publishes a monthly free tier (the first 50 vCPU-hours of Agent Compute, 100 GiB-hours of Agent Memory and 1 GiB-month of Agent Storage) that makes a small workload nearly free to trial, and AWS meters AgentCore per capability with no upfront cost. Then set the trigger for revisiting: the second and third agent, the first multi-tenant customer, or the first auditor who asks who the agent was acting as.

The last artefact is the one that gets skipped, and it is the reason this note exists. Write the exit plan on day one, while you are still indifferent.

Not because you expect to leave. Because the exit plan is what keeps the day-one insurance premiums paid: the adapter module, the second telemetry sink, the graders in your repo, the policy-intent table. A team with a written exit plan does those things as a matter of routine; a team without one does them never, discovers the anchors two years in, and calls the discovery lock-in. Half a page, four sections, re-read once a quarter with the date of the read at the top.

Trigger conditions

The events that re-open the decision, written as things someone could observe — each with an owner and a check frequency. Vague triggers ("if it gets expensive") never fire.

Coverage gap. Our residency or key-custody clause extends to a component or region the platform does not cover. Owner: security. Checked: quarterly, against the current docs.
Preview that never landed. A capability our slice depends on is still in preview past a date we name now, or is announced for retirement — Microsoft’s retirement of Foundry visual workflows on 1 December 2026, pointing users to Agent Framework, Logic Apps or direct A2A connections, is exactly the shape of event to watch for. Owner: tech lead. Checked: monthly.
Unit economics. Cost per successful run exceeds our stated ceiling for two consecutive months, and the cause is platform metering rather than our own prompt bloat. Owner: whoever owns the budget. Checked: monthly.
A second estate. Another business unit or an acquisition brings a different cloud and a different directory, and running two identity planes is now on the table. Owner: architecture. Checked: when it happens.
Our own answer changed. The systems of record moved, or the delivery surface moved. Data gravity is the heaviest input in the recipe, so when it shifts, the recipe re-runs. Owner: tech lead. Checked: annually.

The move, layer by layer

Estimates written before you are under pressure, and the honest word where you do not know.

Layer	If we had to move	Why
Prompts, golden set, graders	Hours	They are files in our repo and every platform runs them.
Framework and loop code	Days to two weeks	One adapter module owns the platform verbs; all three platforms run other people’s frameworks.
Tool surface	Days if we own the servers; weeks if we let the platform host the integrations	MCP carries the interface; the registration, credential and approval wiring is re-done per platform.
Telemetry	Days, because we already export to a sink we own	The OTel gen-AI conventions are still marked development-status, so expect attribute drift, not a clean replay.
Managed memory	Unknown — retrieval APIs exist per platform, but no interchange format or tested bulk-export path is documented, so we mitigate instead	We write the facts we depend on into our own store; platform memory is a cache.
Identity, policy, network	One to two quarters	Native directory, a different policy language, and a fresh security review with the approvals re-earned.

The row that says unknown is the most valuable row in the table. It is the one that turns into a vendor question with a date on it, and it is the reason the mitigation exists.

What lives in our repo, unconditionally

The rule is one sentence: if it only exists in a portal, it does not exist.

System prompts, task decompositions, and every version of both
The golden set, the graders, the judge rubrics and their calibration labels
Tool contracts, their schemas, and the scope each one is allowed
The policy-intent table — principal, action, resource, condition, evidence — that each platform’s policy language is a translation of
The adapter module: run a turn, read and write memory, fetch a credential, emit a span
Infrastructure as code for everything the agent touches, including the eval and trace wiring
The exit plan itself, next to the decision record, in the same commit as the code it describes

What we accept losing

Say these out loud on day one so that nobody discovers them mid-migration and experiences them as betrayal.

The extracted memory history. Long-term records derived by the platform from thousands of sessions — a Memory Bank generated by models, or strategy-extracted records in actor namespaces — have no documented interchange format. We keep the facts we depend on; we lose the derived corpus and its accumulated shape.
Built-in evaluator scores as a time series. Our own graders port; a year of platform-native scores does not compare cleanly to a different platform’s.
Portal dashboards, saved queries and alert wiring. Cheap to rebuild, annoying to rediscover, and always underestimated.
Managed connectors and platform-hosted tools we did not write. Anything we did not build we re-integrate, and that is the price of having moved fast early.
The approvals we already earned. The network path, the data-flow sign-off, the exception in the policy baseline. Re-earning them is calendar time, not engineering time, which makes it the slowest item on the list.

How you know it worked — six checks, six months later

A platform decision is not validated by the platform still being fine. It is validated by these, and every one of them is falsifiable:

Anyone on the team can state the two findings that would reverse the decision. If nobody remembers them, the decision record is decoration.
A new engineer got the slice running from the repo in a day — no portal archaeology, no tribal knowledge about which checkbox in which console.
The port/anchor ledger has been updated at least once, because a capability moved or a preview landed. A ledger that never changes is not being read.
You have never had to ask the vendor what your agent did. Traces land in a sink you own as well as theirs, and you answer that question yourself in minutes.
Cost per successful run is a number you review, not a number you discover — with the metering dimensions understood well enough that a spike points at a cause.
The identity and egress tests from days 6 and 7 still run, on a schedule, against the real provider. They were the hardest evidence you gathered; they are also the first thing a platform change quietly breaks.

If the process failed, the tell is unmistakable and it is not technical: six months on, nobody can find the decision record, and the reason you are on this platform has become because we are. Then the next choice gets made the same way this one did — by whoever talks loudest in the meeting.