Hyperscaler Agent Platforms in 2026: Bedrock AgentCore vs Agent 365 vs Gemini Enterprise
AWS bills your agents by the vCPU second. Microsoft and Google bill by the person. That single difference decides more about your bill than any model choice.
The interesting question about agent platforms is not which model they call. You will change models within a year. It is where the agents run, who holds their identity, and what unit shows up on the invoice.
On that last point the three hyperscalers have picked genuinely different answers, and the difference is large enough that a fleet that costs a few hundred dollars a month on one can cost six figures on another without either vendor being dishonest about it.
All prices below came off vendor pricing pages and product documentation on 21 August 2026.
Three billing units
AWS meters compute. Bedrock AgentCore charges $0.0895 per vCPU hour and $0.00945 per GB hour for its runtime microVMs, and it does not bill I/O wait. An agent that spends most of a request waiting for a model to answer is not consuming vCPU during the wait, so you are not paying for it. Gateway invocations are $0.005 per thousand, tool search is $0.025 per thousand, and memory has its own per record rates.
Microsoft meters people. Agent 365 went generally available on 1 May 2026 at $15 per user per month standalone, or bundled into Microsoft 365 E7. Microsoft’s own wording is that a license covers “an individual who manages or sponsors agents, or uses agents to do work on their behalf,” which is worth reading twice, because it means the license count is a policy decision about who touches agents rather than a fixed multiple of headcount.
Google also meters people. Gemini Enterprise is sold per seat, with Google’s billing documentation describing a $30 monthly seat fee, and several editions (Business, Standard, Plus, Frontline, and pay as you go) that differ in user counts, pooled storage, and model access. The platform absorbed what used to be sold as Vertex AI, which is a packaging change more than a technical one: existing workloads keep running.
What the compute meter means in practice
Take a fleet handling a million tool calls a month, each burning roughly three seconds of vCPU. That is about 833 vCPU hours, or about $75 of AgentCore runtime, plus $5 of Gateway invocations and some memory charges. Under a hundred dollars for the runtime layer.
The model tokens for those same million calls will cost one to two orders of magnitude more. This is the part that most platform comparisons get backwards: the runtime is close to a rounding error next to inference, so choosing a runtime to save on runtime is optimizing the wrong line. What the runtime choice actually decides is which model prices you are exposed to, how much engineering time the plumbing costs, and whether your security team signs off.
The seat model inverts the same math. Ten thousand Agent 365 licenses is $150,000 a month regardless of whether those agents handle a thousand tool calls or a billion. If a fraction of that population actually uses agents weekly, the effective cost per active person is what matters, and Microsoft’s licensing definition gives you room to license only the people who sponsor or use agents rather than the whole directory.
What you actually get for the money
AgentCore’s argument is the Gateway: Lambda functions, REST APIs, MCP servers, and container tasks sit behind one signed endpoint with IAM mapped permissions, so agents stop carrying their own credentials. That is the feature that gets a security review to a yes, and it is why AgentCore reads as the least opinionated of the three. It is a runtime rather than a product surface. Nothing about it puts an agent in front of an end user, and wiring that up is your work.
Agent 365’s argument is the opposite one. Agents get identities in Entra, which means conditional access, data loss prevention, and the existing audit pipeline apply to them the same way they apply to employees, and they show up inside Teams and Outlook without an integration project. Microsoft has also shipped registry sync with AWS Bedrock and Google Cloud in public preview, so agents running elsewhere can be discovered and inventoried from the same control plane. That is a deliberate bet: Microsoft does not need to win the runtime if it owns the identity and audit layer above all of them.
Gemini Enterprise’s argument is the Workspace side. If your company’s documents, mail, calendars, and warehouse tables already live in Google’s stack, the no code builder covers the large fraction of agent work that is honestly just reading a calendar and sending a message. It is also where the lock in is sharpest, because anything assembled in a visual canvas does not port anywhere.
The portability that is real, and the part that is not
Agent code moves better than people expect. The common frameworks run on more than one of these platforms, and the model layer is a swap. What does not move is the wiring: how tools are catalogued, how identity propagates between agents, how traces are collected. Budget for rewriting the glue rather than the logic if you switch.
Anything built in a no code canvas is a full rewrite. Treat those builders as the fast path for agents you would be willing to throw away, not as the foundation for the ones you would not.
Choosing
If the agents are infrastructure, serving traffic rather than sitting next to employees, AgentCore’s meter is the honest one and the Gateway is the reason to stay. Accept that you will build the user facing surface yourself.
If the agents are colleagues, working inside mail and chat for people who already have Microsoft licenses, Agent 365 is the shortest path and the identity story is genuinely ahead of the others. Model the license count before anyone quotes you a per user number times total headcount.
If the company already runs on Workspace and BigQuery, Gemini Enterprise removes the most integration work per agent, and the seat price is the simplest of the three to forecast.
Running more than one is the normal outcome rather than a failure, and it is what Microsoft’s cross cloud registry preview is aimed at. If you expect to land there, put a vendor neutral tracing layer in from the start. That is the piece that determines whether the second platform is an addition or a migration.
Before any of this, count how many people would need a license under each vendor’s definition, and put that number next to your current monthly token spend. If the seat total is larger than the token total, you are buying a productivity product and should evaluate it as one.