Why managed agent platforms exist

Lesson 1 of 5 in The Cloud Agent Landscape: Three Managed Platforms, One Map.

You already know how to build an agent: an LLM with tools, run in a loop, with a stopping condition. You can write that loop in an afternoon. What takes the next six months is everything underneath it.

Run the exercise honestly. To put one agent in front of real users you need somewhere to execute untrusted model-chosen actions with per-user isolation; somewhere durable to keep conversation state when the process dies; a way to expose a hundred internal APIs as tools without pasting a hundred credentials into a prompt; an identity for the agent itself, separate from the human it acts for; an enforcement point where a rule actually binds instead of being a sentence in the system prompt; traces you can debug a bad run from; and an evaluation harness so you know whether last week’s prompt change helped.

None of that is your product. It is the undifferentiated heavy lifting of agents — the same seven layers, rebuilt badly, at every company on earth. That is precisely the gap AWS, Microsoft, and Google are selling into.

What sits under an agent in production

  1. Your agent’s judgment — the only layer that is your product

    The prompt, the tool set, the task decomposition, the domain knowledge, the definition of done. This is where your advantage lives, and no platform sells it to you. Everything below is table stakes you either buy or build.

  2. Evaluation and observability — did it work, and why did that run fail?

    Structured traces and spans per run, plus scored evals over a golden set and sampled production traffic. Managed versions of this layer are the newest and the least uniform across vendors — check launch stages before you depend on them.

  3. Guardrails and policy enforcement — the rule that binds because it is not in the prompt

    Content filtering, injection detection on tool output, and deterministic allow/deny on tool calls. The value of a managed layer here is placement: outside the agent process, where the model cannot reason its way around it.

  4. Tools and credential brokering — a hundred APIs, zero secrets in the prompt

    A gateway that turns existing APIs into MCP tools, holds the credentials for each backend, and keeps tool schemas from flooding the context window. Every vendor now ships one. AWS’s Gateway and Foundry’s Toolbox both present themselves as MCP-compatible endpoints; on Google Cloud, MCP is an ADK tool type while Agent Gateway is documented as routing and authorization rather than as an MCP server.

  5. Session state and memory — because the runtime is ephemeral on purpose

    Short-term conversation history plus, on AWS and Google Cloud, a second service that derives long-term memory — user preferences, facts, summaries — retrievable across sessions: AgentCore Memory strategies and Google’s Memory Bank. Foundry’s documented equivalents are durable conversations and a keyed state store, not a derivation service, so on Foundry the extraction step is yours to build.

  6. Runtime isolation and agent identity — the floor everything else stands on

    Per-session compute isolation strong enough to run model-chosen actions, plus an identity for the agent that is distinct from the user’s. Get this wrong and every other layer is decoration: cross-session leakage and over-broad credentials are the two failures no prompt can fix.

So the pitch is real. The question is what you hand over in exchange, and it is not mainly money.

You hand over placement of the boundary. A managed platform decides where your agent process ends and its infrastructure begins — and that seam is where your data model lives. Your memory records are shaped by their extraction strategies. Your tools are registered in their gateway. Your traces land in their telemetry store, in their schema. Migrating an agent between platforms is rarely about the loop (frameworks are portable, and all three hosts run the popular ones); it is about re-creating that seam somewhere else.

You also hand over pace. Managed agent services in 2026 ship monthly, rename quarterly, and mark a meaningful fraction of their surface area preview. That is a fine trade when you want capability you cannot build — and a bad one when you build a compliance dependency on a feature with no SLA.

Interactive sorting exercise: You are scoping an agent for production. Sort each concern: is it differentiated work only you can do, undifferentiated plumbing worth buying, or a boundary decision the platform makes *for* you?

Key terms: managed runtime, agent identity, tool gateway, memory, guardrails, vendor lock-in

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