AgentCore vs Foundry vs Vertex AI Agent Engine vs Cloudflare Agents: Nobody Is Selling You the Loop

Two of these four bill the agent loop at roughly nine cents per vCPU-hour, and the two prices are 3.6% apart; the other two do not charge for running the loop at all. That should tell you the loop is not the product. What each of them is really selling is a place to keep the conversation — and on 30 July 2026 AWS closed its first attempt at this to new customers, which is the clearest available evidence about which half of a managed agent runtime you can afford to rent.

At a glance

Four managed runtimes, four different answers to "where does the agent's state live when nobody is looking at it".

Runtime	What it meters	Where conversation state lives	Buy it when
Amazon Bedrock AgentCore	Runtime at $0.0895/vCPU-hour and $0.00945/GB-hour, plus separate meters for Gateway, Memory and the rest.	AgentCore Memory — a managed primitive, but one you can call on its own.	You want the pieces sold separately and are willing to assemble them.
Microsoft Foundry Agent Service	Nothing for running the agent. You pay model tokens, tools, and thread storage per GB.	Microsoft-managed on Basic setup; your own Cosmos DB for NoSQL on Standard.	The threads have to sit in a database you already own and audit.
Vertex AI Agent Engine	$0.0864/vCPU-hour and $0.0090/GB-hour, plus $0.25 per 1,000 stored session events or memories.	Sessions and Memory Bank — managed, and the only one of the four metered per write.	You want managed memory extraction and will design around paying per event.
Cloudflare Agents	Workers duration and requests; SQLite storage has billed since 7 January 2026.	One Durable Object per agent instance, each with its own embedded SQLite database.	You want state to be a real SQL database you can query, per agent, at the edge.

The column that decides your exit cost is the second one, and it is the column the pricing pages bury.

The compute line is a commodity and everyone has already priced it that way

Where a per-vCPU-hour rate exists at all, the two published rates are 3.6% apart.

AgentCore Runtime bills $0.0895 per vCPU-hour and $0.00945 per GB-hour. Vertex AI Agent Engine bills $0.0864 and $0.0090. That is a 3.6% gap on CPU and a 5% gap on memory — which is the spread you see in a market where the good is undifferentiated and both sellers know it. Google additionally gives away 50 vCPU-hours and 100 GB-hours a month, which is a marketing decision, not a cost structure.

Both also share the same billing subtlety, and it is the one that makes the comparison mostly academic: CPU is charged for active cycles, not for the wall-clock time your process spends blocked on a model or tool call. An agent loop is overwhelmingly I/O wait. The compute meter on a real agentic workload runs for a small fraction of the session's duration, which is why neither vendor is fighting over the rate — there is not enough revenue in it to fight over.

Microsoft makes the same point by charging nothing at all: creating and running Foundry-native agents carries no separate charge, and you pay for model tokens, for tools, and for storage. Cloudflare charges Workers duration and requests, with the agent itself getting no special meter. Four vendors, three pricing philosophies, and one shared conclusion — running the loop is not where the money is, so it is not where the differentiation is either.

Who holds the thread

Four of the five layers move in a sprint. The highlighted one is a migration project.

Every one of these runtimes decomposes into roughly the same five things: a place to execute your code, a loop that decides what to call next, a gateway that reaches tools, an identity broker that decides whose credentials the call travels on, and a store that remembers what happened. The first four are all portable in the sense that matters — you can rewrite them, and if you wrote your agent against a framework rather than against the vendor's loop, you barely have to. The fifth is not portable, because it is not code. It is accumulated data with vendor-specific structure, and the longer the deployment runs the more of it there is.

This is where the four genuinely diverge. Microsoft's Standard setup puts thread messages and conversation history in an Azure Cosmos DB for NoSQL account that belongs to you, which is a different claim from every other option here: the exit is a data migration you can plan, from a database you can already query, rather than an export request. Cloudflare's answer is structurally similar and philosophically different — each agent instance is a Durable Object holding its own SQLite database, so the state is real SQL you can read, but the object lifecycle and the placement are Cloudflare's, and nothing outside the Workers platform has that shape.

AWS and Google both keep conversation state inside a managed service. AgentCore Memory is at least an independently callable primitive rather than something welded to the loop. Google's Sessions and Memory Bank go further in the other direction: Memory Bank does the extraction — deciding which facts from a session are worth keeping — and bills $0.25 per 1,000 stored events or memories, with the stored bytes billed again as Agent Storage at $0.30 per GiB-month. Note what per-write pricing does to design. On Vertex you have a standing financial incentive to write fewer memories, which is a reasonable incentive and also a vendor-specific one that will quietly shape your memory policy.

What AWS's first attempt actually proved

Amazon Bedrock Agents launched in November 2023 as a config-defined managed loop: declare a model, some action groups and a set of instructions, and AWS ran it. As of 30 July 2026 it is Bedrock Agents Classic, closed to new customers and in maintenance mode. Existing workloads keep running, no new features arrive, and the model catalog is frozen at the maintenance-mode date. That last clause is the part worth staring at — a frozen model catalog means the deprecation is not a cosmetic rename you can ignore until a shutdown notice arrives. It is a slow expiry, and it starts the moment a model you want is one the service will never offer.

The obvious reading is that config-defined agents failed. The obvious reading is wrong, because AWS shipped another one: AgentCore Harness reached general availability on 17 June 2026, and it is the same pitch — declare the model, the tools, the skills and the instructions, and AWS assembles and runs the loop, managing context, isolating sessions and recovering from failures.

What changed is not the loop. It is that the loop is now one optional consumer of primitives you can also use directly. AgentCore sells Runtime, Gateway, Memory, Identity, Observability, Policy, Evaluations, Browser and Code Interpreter as separately usable, separately metered services. Bedrock Agents Classic sold one bundle in which the loop, the state and the model catalog were the same purchase, so freezing any of them froze all of them. That is the actual lesson, and it generalises past AWS:

When a vendor offers to run your agent loop, ask what you would still hold if the loop product were frozen tomorrow. If the honest answer is "nothing", you have not bought a runtime — you have bought a product whose end-of-life is your migration.

Run that test across the four and it sorts them cleanly. On AgentCore you would still hold the memory store, the gateway and the identity broker, each callable on its own. On Foundry Agent Service with Standard setup you would still hold your Cosmos DB, because it was never theirs. On Cloudflare you would still hold Durable Objects, which existed before the Agents SDK and are not an agent product. On Vertex you would still hold Sessions and Memory Bank, which are separately billed services — but the extraction policy that decided what went into them is Google's.

When to pick which

Situation	Pick	Because
Conversation history is regulated data your auditors already have a process for	Microsoft Foundry Agent Service, Standard setup	Thread storage in your own Cosmos DB is the only option here where the state was never in someone else's boundary to begin with.
You want managed pieces but refuse a bundled loop	Bedrock AgentCore, primitives only	Runtime, Gateway, Memory and Identity are independently callable, so you can take the substrate and write the loop yourself.
Long-lived per-user agents, low per-session cost, latency matters	Cloudflare Agents	One Durable Object per agent with its own SQLite, hibernating between turns — state that survives without a session service in the path.
You want memory extraction as a managed service, not a thing you build	Vertex AI Agent Engine	Memory Bank decides what is worth remembering across sessions. Budget for it: $0.25 per 1,000 events is cheap per write and unbounded per deployment.
You are prototyping and expect to be somewhere else in a year	Any of them, on one condition	Write the agent against a framework, not the vendor's loop, and keep an export path for the thread store. Both are cheap now and neither is retrofittable.

The choice that actually binds is narrower than the comparison suggests. Compute is a commodity, the loop is replaceable, gateways are configuration. Pick on where the conversation lives, on whether the primitives survive the product, and — since you now have one worked example of a hyperscaler retiring exactly this category of service in under three years — on how the vendor behaved the last time it changed its mind.

FAQ

Is Bedrock Agents Classic shut down?

No. It closed to new customers on 30 July 2026 and entered maintenance mode. Existing workloads continue to run, but no new features are added and the model catalog is frozen at the maintenance-mode date, so the practical deadline is whenever you need a model it will never carry.

Which of the four is cheapest?

The question does not survive contact with the bills, because they meter different things. Where a compute rate exists, AgentCore and Vertex are 3.6% apart on vCPU-hour and both bill only active CPU rather than time blocked on model calls. Foundry charges nothing for the agent runtime and Cloudflare folds it into Workers. In every case the dominant line is model tokens, and the fastest-growing line is state.

Can I keep conversation state in my own database?

On Microsoft Foundry Agent Service, yes — Standard setup supports bring-your-own thread storage on an Azure Cosmos DB for NoSQL account. On Cloudflare the state is a per-agent SQLite database inside a Durable Object, which is yours to query but lives on their platform. On AgentCore and Vertex AI Agent Engine the conversation store is a managed service, so ask about export before you accumulate a year of threads.

Does a config-defined agent lock me in more than code?

Not by itself. Bedrock Agents Classic locked people in because the loop, the state and the model catalog were one purchase, so there was nothing left when it froze. AgentCore Harness is also config-defined but sits on primitives that are separately callable — same interface, very different exit.

What is the difference between this and picking an agent framework?

A framework decides how you express the loop; a managed runtime decides who operates it and who holds the session. They are orthogonal, and the durable advice is to buy the runtime and write the loop against a framework, so that the layer you can port is the one carrying your logic.

What should I benchmark before committing?

Not throughput. Measure how much state a typical session accumulates in a month, then price that at the vendor's storage and per-event rates, then ask what an export of it looks like. Those three numbers decide more than any latency figure you can collect in a trial.