The decision tree, and one scenario walked to a recommendation

Lesson 5 of 5 in Choosing a Cloud for Agents: A Decision You Can Defend.

Everything so far feeds this. Walk the tree with a real project in mind — not a hypothetical one — and answer with evidence you could show someone. The order of the questions is deliberate: constraints that can disqualify come first, preferences that can be changed come last. A boundary requirement outranks data gravity, gravity outranks the identity plane, identity outranks the delivery surface, and everything outranks SDK taste.

Two honest caveats before you start. The tree produces a starting hypothesis to test with a bake-off, not a verdict — and its leaves include self-hosted and hybrid, because "pick one of the three clouds" is not the only defensible answer.

Requirements to platform: walk it with a real project

Interactive decision tree — outcomes:

Stop — build the component map before choosing
A hard boundary constraint plus unverified coverage is how compliance debt is created. Build a table: for each component you would use (runtime, session store, long-term memory, tool traffic, traces, evaluation data), name the control that satisfies the constraint, its launch stage, and your region. Expect gaps — Foundry documents network egress controls as preview and hosted-agents-only, Google Cloud’s enterprise-controls matrix has per-service gaps, and every platform’s region lists differ by component. Then come back to this tree with evidence.
Start on AWS — Bedrock AgentCore
Your data and identity plane are AWS-native, so the agent should be too. Buy the modular pieces you need rather than all of them: Runtime for isolated sessions (microVMs up to 8 hours, or Instance sessions up to 14 days when a workload must survive days), Gateway to turn your APIs, Lambda functions and existing MCP servers into one governed MCP tool surface, Identity’s token vault so credentials never touch the context, Policy for Cedar rules evaluated on every action at the gateway. Verify: which regions carry each component, and enable CloudWatch Transaction Search once per account or your traces will not appear. Keep portable: the loop stays framework-agnostic code, goldens stay in git, and Evaluations can score agents running on Lambda, EKS or off AWS entirely.
Start on Microsoft Foundry
An Entra estate — and especially a Teams or Microsoft 365 Copilot delivery surface — makes this the path of least resistance, because agent identity and the publish path are the two least portable things in the stack and both are native here. Choose the agent type deliberately: prompt agents are configuration only (no code, no container, inference plus tools), hosted agents are your container or source zip and add container compute. Verify at creation time: network injection cannot be added or changed after the Foundry account exists, and standard setups need bring-your-own Storage, AI Search and Cosmos DB. Keep portable: put tools behind a Toolbox — Microsoft describes it as Foundry-homed, not Foundry-bound, consumable by non-Foundry MCP clients — and avoid building on any layer whose retirement is already announced.
Start on Google Cloud — Gemini Enterprise Agent Platform
With Google Cloud IAM as the identity plane and the corpus in BigQuery, Cloud Storage or Workspace, Agent Runtime plus Sessions and Memory Bank is the coherent choice, and ADK gives you the widest language surface of the three (Python, TypeScript, Go, Java, Kotlin). Verify: the enterprise-controls matrix per service — VPC Service Controls, CMEK and residency are listed for Runtime, evaluation, Sessions, Memory Bank and Code Execution, with gaps elsewhere — and check current launch stages, because this platform has been renamed and restructured repeatedly. Keep portable: the same ADK agent can target Cloud Run, GKE or a self-hosted container, which is a genuine exit ramp; exclude the monthly free tier from any cost projection.
Hybrid — your compute, their hard parts
Run the loop where your team is already competent (Kubernetes, Cloud Run, ECS, EKS) and buy only the components that are genuinely hard to build: a credential broker, a sandboxed code interpreter or browser, managed memory extraction, a trace store. This is a supported shape rather than a hack — AWS documents sending telemetry from on-premises and multi-cloud agents into AgentCore Observability and evaluating agents that run outside AWS, Foundry supports registering external agents so their spans land in Application Insights for trace-based evaluation, and a Foundry Toolbox is explicitly consumable by non-Foundry runtimes. The cost: you own the runtime, the scaling and the isolation story, and you must resist the drift where "just this one more managed piece" quietly becomes a full platform commitment without a decision.
Self-hosted framework — and that is a real answer
If you already run containers at scale, have a working secrets and network story, and your compliance narrative is built around infrastructure you control, a framework on your own compute is defensible: LangGraph, ADK, Microsoft Agent Framework or Strands, an MCP tool layer, OpenTelemetry to your existing backend, evals in CI. You give up managed session isolation, managed memory extraction, platform tool catalogues and first-party delivery surfaces — enumerate those honestly rather than discovering them later. Revisit when you need per-session sandbox isolation for untrusted code, a first-party surface such as Teams, or the on-call cost of the runtime starts crowding out work on the agent itself.
No axis dominates — run the bake-off, then decide
You reached this leaf because no constraint disqualified anything and no commitment pulls you anywhere: a genuinely open field. Do not resolve it by preference. Run the seven-rule bake-off from lesson 4 on two candidates (never three — the marginal insight does not pay for the third integration), frozen task set, matched model class, cost per resolved task with p50 and p95 latency, plus platform-team hours counted at their real price. Then write the flip conditions down, because a decision made on small margins is one you will legitimately want to revisit.
Two identity planes — you are signing up for double operations
Data in two clouds, each reachable only with its own native identity, means two directories, two policy languages, two audit pipelines and two on-call runbooks — for one agent. Sometimes that is genuinely the situation, but treat it as a finding to escalate rather than an architecture to accept quietly. The cheaper fixes, in order: consolidate the corpus behind one governed tool layer so the second cloud is reached as an MCP tool rather than a second home; federate the identity planes so one principal can be delegated across both; or split the problem into two narrower agents, each single-cloud, coordinating over an agent-to-agent protocol. If none of those is possible, pick the platform where the higher-risk data lives and reach the other one read-only.

Tool: Cloud Deployment Wizard — The Deployment Wizard runs this tree against harder inputs — contradictory constraints, preview-only controls, a corpus that straddles two clouds — and grades the recommendation you defend.

The worked example

The situation. A European insurer wants an agent that triages motor-claim submissions: read the claim and its attachments, pull policy terms, check the loss against cover, either propose a settlement band or route to a human adjuster with a summary. Concretely:

The corpus is roughly 40,000 policy and procedure documents in SharePoint plus a claims store in Cosmos DB. Actuarial reference tables live in a BigQuery warehouse on Google Cloud.
Every employee and every internal API authenticates through Entra ID. Adjusters are emphatic that they will not leave Teams for another web app.
The regulator requires claim data to remain in EU regions, in resources the insurer owns, under its own keys — and the security team wants default-deny egress from anything that reads customer documents.
The team is six engineers, mostly .NET and Python, with two platform engineers and an existing Azure enterprise agreement. There is no Kubernetes practice.

Walking the tree. Boundary constraint: yes, contractual — so the first move is a component map, not a platform pick. Data gravity: overwhelmingly one cloud, with a single named exception. Identity: Entra. Delivery surface: Teams. That path reaches Foundry before the team’s skills or commitments are even considered — which is the point of ordering the axes by disqualifying power. Commitments and skills then agree with the answer instead of driving it, which is the comfortable case; when they disagree, the constraint wins and you budget for the retraining.

The decision record — the artefact you actually hand over
Axis	Weight	Evidence (not opinion)	Where it points
Boundary constraints	Fatal if unmet	Regulator clause requires EU residency, customer-owned resources, customer-managed keys. Security standard requires default-deny egress for document-reading workloads.	Foundry standard setup, because bring-your-own Storage, AI Search and Cosmos DB keeps agent data in the insurer’s tenant — conditional on a component-by-component check, and on treating the preview status of hosted-agent egress controls as a tracked risk with a compensating network control.
Data gravity	Highest	40,000 documents in SharePoint; claims in Cosmos DB; one dependency (actuarial tables) in BigQuery.	Azure. The BigQuery dependency is reached as a governed tool through the toolbox, not by giving the agent a second home. One read-only tool is cheaper than a second identity plane.
Identity provider	Very high	Entra ID for all employees; downstream APIs authorise on Entra tokens.	Azure. Hosted agents receive a dedicated Entra identity and can use OAuth 2.0 on-behalf-of so the agent reads only what the signed-in adjuster may read — the invariant that would take a quarter to approximate anywhere else.
Delivery surface	High	Ten interviewed adjusters; all work claims inside Teams all day.	Azure. Foundry documents a publish path that compiles a Teams app manifest and submits it to the Microsoft 365 and Teams catalogs, with admin approval for org-wide scope. Note the wrinkle: portal publishing is unsupported when public network access is disabled, so plan the REST publish path.
Commitments and landing zone	Medium-high	Existing Azure enterprise agreement; subscription vending, network and policy baselines already automated on Azure.	Azure — agrees with the constraint-driven answer, so it adds confidence rather than deciding anything.
Team skills and on-call	Medium	Six engineers, .NET and Python, two platform engineers, no Kubernetes practice, no 24/7 rotation.	Managed runtime, not self-hosted. Within Foundry, start with a hosted agent so the loop stays portable code, and keep prompt agents for the small auxiliary agents where configuration genuinely suffices.
Exit cost (bought deliberately)	Named, not minimised	Dependencies accepted: Entra agent identity and on-behalf-of wiring, Teams publishing, Foundry conversations and state store, Toolbox connectors.	Insurance bought: loop written against Microsoft Agent Framework or LangGraph in a container; goldens, prompts and graders in git; tools defined as MCP or OpenAPI specs behind the Toolbox; traces emitted as OTel gen-AI spans into an Application Insights resource the insurer owns.

The recommendation, written so someone can disagree with it

"Build on Microsoft Foundry hosted agents in an EU region, standard setup with bring-your-own Storage, AI Search and Cosmos DB, network injection configured at account creation, tools behind a Toolbox, traces to our own Application Insights, evals in the repo. Three findings we accept: hosted-agent egress control is preview, so we add a network-level compensating control and track it; publishing to Teams from a private-networking project requires the REST path; the BigQuery dependency is a read-only tool, not a second runtime.

This flips if: (1) adjusters move off Teams to a first-party web app, which removes the delivery-surface weight entirely; (2) the actuarial data becomes the primary corpus, which moves data gravity; (3) the residency clause is satisfied by fewer components than our map assumed, in which case we re-run the tree from the boundary node."

That is the whole deliverable: a choice, the evidence, the accepted risks, and the conditions that would reopen it. A platform decision without flip conditions is not a decision, it is a habit — and this is exactly the artefact the deploying-and-versioning module expects you to keep under version control alongside the agent.

Interactive flashcard deck.

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.