Agent Execution Engines Explained: Runtime Is the Product

Gartner reports that only 8% of organizations have agentic AI in production, and the reason isn’t model intelligence — it’s that the infrastructure layer for running autonomous agents has been a build-it-yourself problem until very recently. Agent execution engines, the managed runtimes that give each agent session isolated compute, memory, and filesystem with scale-to-zero billing, are the category that emerged to fix that. The problem is that vendors have converged on a shared architecture while competing on who can lock your agent’s memory layer most effectively, making switching costs cognitive and financial rather than technical. If you’re evaluating where your agents should actually run, you need to understand what these runtimes do, what they cost, and where the lock-in lives.

The Managed Agent Runtime Has a Shared Architecture

Every major managed agent runtime — AWS Bedrock AgentCore, Google Vertex AI Agent Engine, Microsoft Foundry, Cloudflare Agents, and Vercel Sandbox — now provides per-session isolated compute, memory, and filesystem with scale-to-zero billing. That shared shape is the tell. The industry has agreed on what an agent runtime is: a sandboxed environment that holds a session open, keeps one user’s reasoning state away from another’s, scales from zero to a thousand concurrent conversations, and bills you nothing while the session sleeps.

The differences are in the isolation mechanism and the memory story. AWS Bedrock AgentCore provides per-session microVM isolation with dedicated CPU, memory, and filesystem per user session, supporting sessions up to 8 hours. Google Vertex AI Agent Engine leads with two GA memory services: Sessions for stateful context inside one interaction and Memory Bank for managed long-term storage across sessions. Microsoft Foundry Hosted Agents provides a per-session sandbox with persistent files, a 15-minute idle timeout with resume capability, and a durable long-run mode.

What I call the substrate lock-in pattern is visible here: the compute layer is converging, so vendors compete by differentiating the memory layer. Once your agent’s long-term memory lives in Google’s Memory Bank or AWS’s managed memory, moving to another runtime means rearchitecting state — not just redeploying code. That’s the cognitive switching cost. The financial switching cost comes from incompatible billing units, which we’ll get to.

Sandbox Isolation: You Get What You Pay For (Or Don’t)

The sandbox layer is where security requirements collide with cost optimization, and the tradeoffs are sharper than vendors admit. Google Cloud Run Sandboxes are in public preview at no additional charge over existing compute, with approximately 500ms cold start at 1,000-sandbox scale. That’s a compelling pitch — zero-premium isolation colocated with compute you already run. The catch: Google’s preview documentation does not specify the isolation mechanism. No gVisor claim, no microVM claim. Enterprise security reviews require hardware-virtualized boundaries that only dedicated microVM vendors can document.

Here’s the contrast. E2B costs approximately $0.000168 per second of sandbox time using Firecracker microVM isolation — a hardware-virtualized boundary you can point to in a security review. Fly Machines cost $0.0000019 per second per shared-CPU machine with Firecracker microVM isolation and idle-free Sprites persistence. Modal serverless compute starts at $0.000054 per GB-second. These are purpose-built sandbox vendors whose entire product is the isolation boundary. Cloud Run Sandboxes are a feature layered onto existing compute, and the boundary is unspecified.

The honest decision axis is one line: do you need isolation-strength-plus-persistence as a first-class product, or is good-enough isolation at near-zero premium the better trade? If you’re running untrusted, LLM-generated code, you need the former. If your agent calls APIs and synthesizes text, the latter might suffice. Just don’t confuse “no additional charge” with “no additional risk.”

Sandbox	Isolation	Pricing	Best For
Cloud Run Sandboxes	Unspecified (preview)	No premium over existing compute	Zero-cost isolation on GCP
E2B	Firecracker microVM	~$0.000168/second	Security-reviewable code execution
Fly Machines	Firecracker microVM	$0.0000019/second/shared-CPU	Low-concurrency VM-per-agent patterns
Modal	gVisor + syscall filtering	$0.000054/GB-second	Python serverless with GPU support

The Open-Source Frameworks Are Becoming a Free Front-End

Here’s the contrarian observation: the open-source agent framework ecosystem is becoming a free front-end for proprietary managed backends. LangChain, AutoGen, OpenAI Agents SDK, and Microsoft Agent Framework are all open-source with zero platform cost and framework portability. That’s the pitch. The reality is that all three hyperscalers now sell managed runtimes that absorb agent memory onto their substrate, and the frameworks are simultaneously adding hosted orchestration layers that move execution off your infrastructure.

The OpenAI Agents SDK 0.18.x, released July 7–11, 2026, changed the default model to GPT-5.6 and added hosted multi-agent beta support for running orchestration on OpenAI’s infrastructure. The changelog frames it as a feature. It’s a strategic move. Until now, the runtime for agent fan-out was yours — your process, your server, your pager. Hosted multi-agent changes where that orchestration runs: against OpenAI-managed infrastructure instead of your own. The appeal isn’t speed; it’s that the pager stops being yours. That’s worth real money to a small team, and worth scrutiny before you hand over the part of your system that’s hardest to get back.

Microsoft is doing the same thing. Microsoft Agent Framework Python 1.11.0, released July 10, 2026, made the Skills API stable (GA) and added message injection middleware for steering live agent runs mid-turn. The .NET 1.13.0 release added per-user session isolation for Foundry Hosting on the v2 protocol. Google’s Managed Agents in Gemini API, updated July 7, 2026, added background execution for async interactions, remote MCP server integration, custom function calling, and credential refresh across interactions. The frameworks are not the product. The runtime that silently absorbs your agent’s memory is the product.

Enterprise Pricing Is Deliberately Incomparable

The enterprise agent platform market has consolidated around three incumbents with four incompatible billing shapes, and vendors design their units so you cannot compare them. Salesforce Agentforce charges $2 per conversation. Microsoft Copilot Studio charges $200 per tenant per month for 25,000 credits ($0.008 per credit) or $0.01 per credit pay-as-you-go. ServiceNow AI Agents are bundled in ITSM tiers at $100–150 per user per month. Per-conversation, per-credit, per-seat — none of which line up.

Here’s why that matters. A mid-size firm running 50,000 customer-service interactions per month would spend roughly $100,000 per month on Agentforce conversation fees alone — before Service Cloud seat licenses, before Data Cloud, before implementation. That’s the difference between reading a rate card and modeling it. The pricing units aren’t just inconvenient; they’re a procurement trap. You can’t build a TCO model when the denominators don’t match, and vendors know it.

The underlying LLM costs add another layer. A standardized test agent making three LLM calls per run (3,000 input tokens, 800 output tokens) plus one web search costs approximately $0.029 per run in LLM and search costs using Claude Sonnet 4.5 at $3 per million input tokens and $15 per million output tokens plus Tavily at $0.008 per search. And Claude Sonnet 5’s introductory pricing of $2 per million input tokens and $10 per million output tokens is promotional through August 31, 2026 — so agentic workloads budgeted at that rate should plan for the step-up after. Most platform pricing pages show you the platform fee. They do not show you what that platform spends on your behalf in LLM API calls.

Platform	Pricing Unit	Cost	Target Audience
Salesforce Agentforce	Per conversation	$2/conversation	CRM-embedded sales/service teams
Microsoft Copilot Studio	Per credit	$0.008/credit (25K for $200/mo)	M365 internal knowledge agents
ServiceNow AI Agents	Per seat	$100–150/user/month	IT/HR workflow automation

Governance Is the Real Production Barrier

The 8% production adoption figure isn’t a technical failure — it’s a procurement and governance failure. Enterprises are stuck because vendor pricing is deliberately incomparable and memory lock-in is effectively irreversible, making TCO modeling and contract negotiation impossible. The standard software delivery lifecycle doesn’t transfer to agents because non-deterministic behavior breaks reproducibility. A test that passes once offers no guarantee it will pass the next time.

This is why the governance tooling matters more than the runtime features. AWS Loom is an open-source reference platform for governing AI agents at enterprise scale, built with Strands Agents SDK and running on Amazon Bedrock AgentCore Runtime. It packages identity provider integration, scope-based authorization, and lifecycle management for agents, memory resources, MCP servers, and agent-to-agent integrations. The identity propagation problem it solves is the hard one: when an agent acts on behalf of a user and calls an MCP server, which calls a REST API, each hop needs an access token that preserves the originating user’s identity and permissions.

On the enterprise integration side, SnapLogic MCP Server exposes enterprise integration operations as governed MCP tool calls, with 1,000+ pre-built Snaps for enterprise systems. Tencent Cloud ADP 4.0 includes nearly 40 Connectors and over 150 Skills for enterprise agent development. The pattern is clear: the teams that succeed are the ones that treat agents as infrastructure requiring governance, not as chatbots requiring prompts. For a deeper look at how memory architectures fit into this picture, our AI agent memory systems guide breaks down why the synthesis bottleneck matters more than storage, and why audit receipts should outweigh leaderboard scores.

How to Actually Decide

The decision framework comes down to three questions, and the order matters.

First: what isolation level does your agent actually need? If it runs code it wrote itself, you need a hardware-virtualized microVM boundary from a vendor that documents it. If it calls APIs and synthesizes text, a platform-bundled sandbox at near-zero premium may suffice. Don’t pay for Firecracker if you don’t need it, and don’t skip it if you do.

Second: where does your agent’s memory live, and what happens if you need to move it? The managed runtimes all want to absorb your memory onto their substrate. That’s the lock-in. If you choose Google’s Memory Bank, you’re choosing to rearchitect state if you ever leave. If you choose AWS Bedrock AgentCore’s per-session microVM model, sessions are torn down after use — but long-term memory still needs a home. The emerging AI agent stack prioritizes vendor-neutral memory and governance over framework selection, and that’s the right instinct. Teams that own their memory layer can switch runtimes. Teams that don’t, can’t.

Third: what’s your billing unit, and what happens at 2x and 5x your current volume? Per-seat pricing simplifies budgeting but overcharges passive users. Per-conversation pricing aligns cost with value but becomes volatile at scale — that $100,000/month Agentforce bill is what happens when you don’t model volume before signing. Per-second sandbox pricing is the most transparent but requires you to understand your actual session durations. If you’re building multi-agent systems that fan out across many concurrent sessions, the per-action and per-second models compound quickly.

The managed agent runtime market has converged on a common architecture. The vendors haven’t converged on pricing, memory portability, or governance. Your job is to pick the runtime whose lock-in profile matches your tolerance for rearchitecting state — because that’s the cost you’ll pay if you ever need to switch. The question isn’t which runtime is best. It’s which runtime’s memory layer you can afford to leave behind.