Where your agent actually runs: Lambda, Bedrock AgentCore, Anthropic Managed Agents, Vertex Agent Engine
Writing an agent is one thing; hosting it so it runs reliably, holds state, and scales is another. A tour of the runtimes — from general-purpose serverless to purpose-built agent platforms.
Your agent code has to run somewhere, and that 'somewhere' — the runtime — quietly decides how it handles state, scaling, isolation, latency, and cost. The options split into two groups: general-purpose serverless you adapt to agents, and newer runtimes built specifically for them.
General-purpose serverless: AWS Lambda
Lambda runs your code on demand with no servers to manage and scale-to-zero economics. You can absolutely host an agent in it — but Lambda is stateless and caps execution time, so long-running, multi-step agent sessions need extra plumbing: external stores for memory and state, and orchestration for steps that outlast a single invocation. It's excellent for short, event-driven tool functions; more work for a long agent loop.
Purpose-built agent runtimes
A newer class of runtime is designed around what agents actually need: long-running sessions, memory, tool and identity management, and strong isolation between runs.
- Amazon Bedrock AgentCore — AWS's managed runtime for agents, with session isolation, memory, a gateway for tools, and identity. It's framework-agnostic and built for secure, long-running execution.
- Anthropic Managed Agents — server-hosted agent execution with a managed sandbox, so Anthropic runs the agent loop and the tool sandbox for you instead of you operating that infrastructure.
- Google Vertex AI Agent Engine — a managed runtime on Google Cloud for deploying, scaling, and operating agents, with sessions and memory, integrated with the rest of Vertex AI.
How to choose
- Reach for Lambda when — your 'agent' is really a few short, stateless tool calls or event-driven glue, and you already live on AWS.
- Reach for a managed agent runtime when — you need long-running, stateful sessions, memory, tool governance, and isolation without building that platform yourself.
- Match your existing cloud — these managed runtimes lean on their provider's identity, security, and model ecosystem, so aligning with the stack you already run saves real integration pain.
The trend is clear: agents outgrew 'just run my function', and now have runtimes shaped around their needs. Pick based on how stateful and long-lived your agent actually is — not on which logo you recognise.
Choosing a runtime is choosing how much of the agent's plumbing — state, memory, isolation, tools — you want to operate yourself.