What Google shipped in August 2026, and why it changes the question
Gemini Enterprise is Google enterprise agent platform: the place a US company connects its own data, deploys agents against it, and gives staff an assistant that can actually do things in the business. It is the product formerly sold as Google Agentspace, renamed on 9 October 2025 and closed to new Agentspace sales at the end of that year, with the developer platform folded in during 2026 as the Gemini Enterprise Agent Platform. If your company runs on Google Workspace, this is the path of least resistance into production agents.
On 26 August 2026 Google announced flexible billing and cost controls for agents, and the headline is worth stating plainly because it is genuinely better than what the competition ships: you can now set hard monthly caps on AI spend and projects. Google own wording on what happens when the ceiling is reached is unambiguous. If a project hits its limit, the agent API calls temporarily pause. The documentation repeats it: when your project reaches this spend limit, overage usage is automatically stopped.
That is a refusal, not a notification, and it puts Google ahead of every other vendor we have measured this year. Salesforce sends threshold alerts. Microsoft expresses no monetary amount near an agent at all. AWS shipped a number but scoped it to a single session. Google shipped a cap that turns things off.
So the useful question is no longer whether Google gives you a ceiling. It does. The question is what that ceiling is attached to, because a cap is only as precise as its scope, and scope is the kind of thing that is decided in a schema rather than in a launch post. That is what we measured.
Gemini Enterprise pricing, read from Google own page
Most of the pricing articles on this topic quote each other. We read the figures below off the Google Cloud Gemini Enterprise page on 16 September 2026, and they are the prices Google itself publishes rather than a partner reconstruction. Google publishes two seat prices and one zero.
Business is starting at 21 USD per seat per month, aimed at small businesses and teams, with 25 GiB of storage and data indexing per seat pooled across the tenancy, and a ceiling of 300 seats. Standard and Plus share one price card at starting at 30 USD per seat per month, which is worth noticing: two editions with different quotas behind a single starting-at number means 30 dollars is Standard floor and Plus is a sales conversation. The third option is the one the August announcement added. Pay-as-you-go, for organizations with 20 or more seats, carries a 0 dollar seat fee and bills at standard rates for tokens, memory, compute and storage. Google notes it is rolling out gradually.
The shape matters more than the numbers. A seat price is a fixed cost that a procurement team already knows how to model, and it is bounded by headcount. Token, memory and compute billing is a variable cost bounded by agent activity, and agent activity is the thing the whole program exists to increase. Pay-as-you-go removes the seat floor entirely and hands you a meter with no headcount ceiling behind it, which is exactly why Google shipped the caps in the same announcement. The two go together on purpose.
Alongside that sit Flexible Savings Plans: commit to a monthly spend and take 10 percent off token costs for a one-year term or 20 percent for three years, with, in Google words, no minimums, no maximums, and no new billing silo to manage. Google also previewed deferred execution pricing, where eligible agent workloads are scheduled into off-peak windows at up to half the inference cost.
How we measured what Google can express about agent spending
Vendor marketing is a poor source for this and opinion is worse, so we do the same thing on every vendor page: we read the published API model. Google is unusually good to work with here, because every Google API ships a machine-readable discovery document that anyone can fetch without a key, and those documents are the ground truth that the console, the CLI and the client libraries are all generated from. If a field is not in the discovery document, it does not exist in the product.
On 16 September 2026 we pulled four of them. Discovery Engine, which is the API behind Gemini Enterprise and Agentspace, at v1alpha (2,323,112 bytes, revision 20260914) and at v1 (2,049,833 bytes, revision 20260915). Vertex AI Platform v1 (3,867,717 bytes, revision 20260904), which carries the Agent Engine runtime. And Cloud Billing Budgets v1 (32,956 bytes, revision 20260906), which is where the spend cap actually lives, a fact we will come back to because it is the whole finding.
Across the alpha Discovery Engine model that is 1,053 schemas, 3,516 properties and 385 methods. We flattened every schema to its property names and ran two vocabulary passes. The money pass matched amount, currency, budget, spend, price, cost, payment, invoice, monetary, credit limit, dollar, purchase, billing, charge, fee, USD, wallet and quota. The policy pass matched merchant, category, MCC, vendor, counterparty, allowlist, approval, daily, monthly, cumulative, aggregate, payee, threshold, cap and ceiling.
Then, because a regex that finds nothing is usually a broken regex rather than a discovery, we ran the same passes against a positive control: the Cloud Billing Budgets API, a Google service whose entire job is money. A working method has to light that one up.
The cap is a Cloud Billing budget, and a budget cannot see an agent
Start with how an administrator actually sets the Gemini Enterprise limit, because the documented procedure gives the answer away. You open Gemini Enterprise, go to Usage and Spending, find Project monthly spend limit, click Set limit, and Google hands you off to Cloud Billing to configure a budget with Vertex AI (aiplatform.googleapis.com) selected from Services. The Gemini Enterprise spend cap is not a Gemini Enterprise object. It is a Cloud Billing budget pointed at one service.
That matters because it means the cap inherits the budget object model exactly, and we measured that object model. A Budget lives at billingAccounts/{billingAccountId}/budgets/{budgetId}, which is the top of the Google Cloud hierarchy and the furthest possible point from an individual agent. Its budgetFilter is where scope is decided, and the Filter object publishes exactly nine dimensions: projects, services, labels, resourceAncestors (folders and organizations), subaccounts, creditTypes, creditTypesTreatment, calendarPeriod and customPeriod.
Read that list again with an agent in mind. Every dimension is a billing or infrastructure container. Not one of them is an identity. There is no user, no service account, no agent, no counterparty, no merchant, no category. The finest grain available is a project, or a label on a resource, and a label is a string you attach to infrastructure rather than a control the platform enforces against an actor.
The consequence is concrete and it is the thing to take into your architecture review. One Gemini Enterprise cap covers every agent in the project, indivisibly. If you run twelve agents and one of them loops, the cap fires for all twelve. Your invoice-reconciliation agent, your support triage agent and your research agent all stop together because a thirteenth one misbehaved. You cannot give the risky agent a small allowance and the safe one a large one, not because Google decided against it but because there is no field in the schema to hold it.
The Agent resource has twenty-one properties and not one is an amount
The obvious next question is whether the limit lives closer to the agent somewhere else in the product, so we looked at the agent itself. Discovery Engine v1alpha contains 31 agent-named schemas carrying 85 properties between them, and the central one is Agent, with 21 properties. Here they are in full, because the list is more persuasive than any summary of it: name, displayName, description, icon, languageCode, customPlaceholderText, starterPrompts, state, createTime, updateTime, sharingConfig, authorizationConfig, observabilityConfig, managedAgentDefinition, adkAgentDefinition, a2aAgentDefinition, dialogflowAgentDefinition, suspensionReason, rejectionReason, creationFailureReason and deploymentFailureReason.
Zero of the 85 agent-schema properties match the money vocabulary. The policy pass returned six hits, and all six are the same two fields repeated across API versions: effectiveTpmThreshold and tpmThresholdNextUpdateTime on the agent search token subscription status. A TPM threshold is tokens per minute. It is a throughput ceiling on a subscription, read-only and output-only, and it is a rate rather than an amount. It is the closest thing to a limit anywhere near a Gemini Enterprise agent, and it is not money.
What makes this a design decision rather than an unfinished corner is what is on the object. authorizationConfig is real governance: it holds the authorization required to invoke the agent, and a separate list of tool authorizations for the resources the agent reaches. sharingConfig.scope governs who can see and use it. The state enum runs to ten values including ENABLED, DISABLED and SUSPENDED, so Google can switch an agent off. The governance vocabulary is present, mature and carefully thought through. It governs identity, access, visibility and lifecycle, and it stops exactly where money begins.
Google does model commerce for agents. It points the other way.
There is one place in the agent model where Google does talk about money, and it is the most quotable detail we found, because of which direction it faces.
An agent defined through the A2A protocol carries a2aAgentDefinition, and inside it sits cloudMarketplaceConfig with two properties. entitlement is required, formatted projects/{project}/entitlements/{entitlement}. order is output only, formatted billingAccounts/{billing_account}/orders/{order}.
So Google does attach an agent to a commercial object. An entitlement and an order are commerce primitives, and they sit directly on the agent definition. They describe you buying the agent from Google Cloud Marketplace. There is no matching object anywhere in the model for the agent buying something on your behalf. The commerce vocabulary exists, it is wired to the agent, and it runs in exactly one direction: money flowing to Google.
That is not a complaint. It is a fair description of the boundary Google drew, and it lines up with the boundary Microsoft, Salesforce and AWS drew independently. It is just worth being clear-eyed that the presence of billing language on an agent record does not mean the platform has any view on the agent as a spender.
The control worked, so the zero is real
A finding built on a regex is worthless without a control, and this one has a strong positive control that we ran the same day with the same expressions.
The Cloud Billing Budgets API is tiny: 11 schemas, 36 properties, 5 methods. The money pass matched 9 of those 36 properties, a hit rate of 25 percent, against Budget.amount, BudgetAmount.specifiedAmount, BudgetAmount.lastPeriodAmount, Budget.budgetFilter, ThresholdRule.spendBasis, Filter.creditTypes, Filter.creditTypesTreatment, Money.currencyCode and the list response. The method is not blind. Point it at a Google API that models money and it fires hard.
The same control produced a second finding worth having, and it is the one that explains why Google shipping a hard cap was news at all. A Cloud Billing budget, on its own, does not stop anything. Google own description of Budget.thresholdRules is that they are rules that trigger alerts, meaning notifications of thresholds being crossed, when spend exceeds the specified percentages. The attached NotificationsRule has five properties and every one of them is a delivery channel: a Pub/Sub topic, monitoring notification channels, default IAM recipients, project-level recipients and a schema version. There is no deny action, no stop action and no enforcement field anywhere in the object.
So the generic Google Cloud budget is an alarm. What Google added in August was a specific enforcement behavior on top of it for Gemini Enterprise overage, which is a genuine improvement and is worth paying for. It is also, by construction, an enforcement behavior wearing a budget scope, which is why it lands at the project and cannot land on an agent.
What the cap protects and what it leaves open
Be precise about the boundary, because getting this wrong in either direction costs money. The Gemini Enterprise cap protects what you owe Google: token, memory, compute and storage consumption beyond your pooled quota, across the Gemini Enterprise app, the Gemini Enterprise Agent Platform and AI coding tools such as Antigravity. Within that scope it works, and it is the best-behaved control of its kind we have measured.
Two things sit outside it.
The first is everything the agent buys. An agent that has a tool wired to a supplier portal, a payables system, an ads platform, a metered vendor API or a checkout can move real dollars, and none of it touches a Google meter. Google charges you a fraction of a cent for the inference that decided to place the order. The order itself is somebody else invoice. A project spend limit filtered to aiplatform.googleapis.com cannot see it, and no amount of tuning the cap will make it see it, because the spend never enters Google Cloud billing in the first place.
The second is which agent, which follows from the nine filter dimensions. Without an identity dimension there is no per-agent allowance, no per-team allowance, no counterparty rule and no approval threshold. Google can tell you that the project has spent 80 percent of its budget. It cannot tell the budget to care that one particular agent is responsible for most of it, and it cannot hold a single expensive action for a human while letting the cheap ones through.
The failure nobody plans for is an agent that stops mid-task
A hard cap has a failure mode, and it is worth walking into the rollout meeting with this one already understood, because it is the practical cost of choosing enforcement over alerting.
When the ceiling is reached, Google words are that the agent API calls temporarily pause, and end users see a Usage limit reached error in the Gemini Enterprise app. Nothing is rolled back and nothing is queued. An agent halfway through a multi-step task simply stops in the middle of it, which is an inconvenience for a research agent and something worse for an agent that had already committed to the first half of a workflow. Google went out of its way in the August announcement to say the pause protects your budget without affecting the rest of your production infrastructure, which is true and is also the point: the blast radius is your agents, all of them, at once.
There is also a documented accuracy caveat that belongs in any forecast. Google states that because stopping usage can take a few minutes to take effect, you might incur charges that exceed your limit. The cap is a fast brake rather than an exact one. For a workload measured in tokens per second, a few minutes of continued spend past a ceiling is not a rounding error.
The alert side is more conventional. Automated email alerts arrive at 50, 80 and 100 percent of the budget. That is a sensible cadence for a human watching a monthly trend and an unhelpful one for an agent that can burn a month of tokens in an afternoon, which is the same mismatch we found in Salesforce Digital Wallet and in AWS session limits.
Where a spend policy layer fits on top of Gemini Enterprise
None of this is an argument against Gemini Enterprise, and there is nothing here to compete with. Google owns the model, the enterprise data grounding, the connectors, the agent runtime and the identity model, and it now owns a working consumption ceiling as well. The layer the schema shows is empty is the one in front of the money: the decision about whether a particular payment, at this amount, to this counterparty, at this point in the month, is allowed to happen at all.
That is what agent spend controls do. You keep Gemini Enterprise as the platform and keep the project cap doing its job on your Google bill, and you put a policy between your agents and your money: a budget that aggregates across a day, a week and a month per agent rather than per project, a merchant-locked virtual card so an agent authorized to renew one vendor cannot pay a different one, an approval threshold that holds a payment for a named human above an amount you choose, a velocity rule for the looping-agent case, and an audit trail that reconciles to your books in dollars rather than in tokens. Because the policy layer is rail neutral it does not care whether the agent pays by card, through an ACP checkout, under an AP2 mandate or over x402.
The test for whether you need one is short and honest. If your Gemini Enterprise agents only search your corpus, summarize documents and draft replies, you do not need anything beyond the project cap, and you should stop reading here. If any agent has a tool that can cause money to move outside Google Cloud, you are currently relying on a ceiling that was designed to size an infrastructure bill.
How Gemini Enterprise compares with the other agent control planes
Five vendors, five published schemas, one pattern, and Google comes out of it best. We have now measured the models behind the major agent control planes shipped in 2026 using the same method each time, and the results are consistent enough to be useful as a buying frame.
Microsoft Agent 365 is agent-aware right down to the conditional access vocabulary and expresses no monetary amount anywhere near an agent: 48 agent-governance types, 623 properties, zero money. Salesforce Agentforce documents 178 money objects and 41 agent objects in 1,757 standard objects, with an intersection of zero, and Digital Wallet alerts rather than refuses. AWS AgentCore shipped a genuine number, one optional per-session USD amount on a session that lives at most eight hours, with no cumulative total in the model, so every new session restarts at the full maximum. The payment MCP servers hand a model write access to live payment APIs with no ceiling at all. Since then we added a sixth: ServiceNow AI Control Tower, whose SDK writes 84 agent columns with no amount among them and whose only dollar limit belongs to a human approver.
Google is the only one of the five with a cap that actually refuses work, and that is a real advantage worth weighing when you choose a platform. It is also scoped to a billing container rather than to an actor, which is the same line every other vendor drew, arrived at from a different direction. Five independent engineering organizations, with different architectures and different commercial incentives, all govern identity, access and capability and all decline to govern the amount a specific agent may commit to a specific counterparty. That is a defensible line. It is also a line, which means something has to sit on the other side of it. For the wider category, AI agent governance covers the control frameworks in general, and AI agent payment platforms compares the vendors who do this specific job.