Picking one: your existing cloud usually wins
Lesson 5 of 5 in The Cloud Agent Landscape: Three Managed Platforms, One Map.
Here is the unsatisfying answer that is nonetheless right most of the time: use the cloud you are already on.
Not because the platforms are identical — you have just spent three lessons on how they differ — but because the differences that decide a real project are rarely the ones on the comparison matrix. Your agent has to reach systems that already live somewhere. Its callers already authenticate somewhere. Your on-call already watches dashboards somewhere. Your security team has already reviewed one vendor’s data-processing terms and not the others’. Every one of those is a gravity argument, and gravity beats features.
A feature bake-off between three platforms that all ship the same seven capabilities takes six weeks and usually rediscovers gravity anyway — after the window in which shipping something small would have taught you more.
Which managed agent platform — or none?
Interactive decision tree — outcomes:
- Bedrock AgentCore — adopt it in pieces
The modular shape is the point: you can take Runtime alone, or Gateway alone in front of tools an agent hosted elsewhere calls. Sensible first slice — put your existing framework agent on Runtime for session isolation, front your tools with Gateway so credentials leave your code, then add Memory and Policy once you feel the pain they solve. Mind the 8-hour session ceiling and the fact that an open session keeps billing memory. Check current quotas rather than trusting any number in a course.
- Foundry Agent Service — pick your agent type deliberately
Start with a prompt agent if configuration can express the job: no container, no scaling, fastest path to a governed agent. Move to a hosted agent when you need real framework code, and take the automatic Entra identity plus On-Behalf-Of delegation as the main prize — it is the cleanest per-user authority story of the three. Two traps: do not build on the visual workflow designer (retiring 1 December 2026), and do not confuse the retiring classic threads/runs agents with the current Responses-based model.
- Google Agent Platform — build in ADK, deploy to Agent Runtime
The natural path is open-source ADK for the agent plus Agent Runtime for hosting, with Sessions and Memory Bank behind it — and ADK also runs on Cloud Run, GKE, or your laptop, which keeps your exit cheap. Do two things religiously: name capabilities rather than products in your own documents (“the managed runtime”, not last quarter’s brand), and confirm each feature’s launch stage and its row in the enterprise-security matrix before you depend on it. As of September 2026 that matrix is not uniform across services.
- Self-host a framework — and be honest about the seven layers
Legitimate, common, and cheaper to start: run LangGraph, Agent Framework, Strands, or ADK on containers you already operate, keep your own secret store and telemetry, stay portable. The honest part is that you have not avoided the seven layers, you have accepted them as a backlog — session isolation for model-chosen code execution and a real agent identity are the two that teams under-build. A good hybrid exists: self-host the loop, but buy the one layer whose failure you cannot absorb (usually the sandbox, sometimes the credential broker). See the framework landscape module for choosing between the frameworks themselves.
Two habits will keep you honest after this module.
Name capabilities, not products, in your own documents. Write “the managed runtime”, “the tool gateway”, “the agent identity” in your architecture docs and put the current vendor name in a footnote. This module’s research pack watched one vendor’s runtime change brand mid-documentation and another retire the API its own tutorials taught; a design doc written in capability language survives that, and a design doc written in brand language needs a rewrite every quarter.
Check the launch stage of anything you depend on, every time. A meaningful slice of all three platforms is preview or limited preview as of September 2026 — tool search, connector-backed MCP servers, tool-call and tool-response guardrail intervention points, external-agent registration, console observability views. Preview means no SLA and no promise of the current shape. Building a demo on preview is smart; building a compliance control on preview is not.
Tool: Cloud Deployment Wizard — Walk a real scoping exercise end to end in the Deployment Wizard: describe a workload — identity plane, data gravity, session length, tool inventory, guardrail requirements — and see which managed platform (or self-hosted stack) the trade-offs actually point at, and what it would cost you in each dimension.
Interactive flashcard deck.
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.