A director of operations asked me last quarter why her staff still could not find the shipping policy in under three clicks, months after my team had shipped two grounded search apps for her group. The apps worked; the trouble was that nobody outside the pilot knew they existed, and the two people who did had bookmarked a raw Cloud Run URL.
That gap is what this part is about. Everything in this series up to now has been the builder side of Google Cloud: how you construct an agent, ground it, tune it, and run it. None of it puts the agent in front of the four thousand people who will never open a console. Gemini Enterprise is the distribution layer. It gives every employee one branded search box and a gallery of agents they open like any other internal app, and it draws a governance boundary around the lot.
What Agentspace became in 2026
Google launched Agentspace in late 2024 as an enterprise search and agent hub: one place where an employee types a question and gets an answer drawn from company data, with agents attached. At Cloud Next in April 2026 Google folded that product into a single brand called Gemini Enterprise, and at the same event renamed the developer platform, the thing this series has called Vertex AI, to the Gemini Enterprise Agent Platform. Two products, one family name.
The split is worth stating plainly because the docs are mid rename and search results still mix both terms. The Gemini Enterprise app is the employee facing product: search, the agent gallery, single sign on, and admin governance. The Agent Platform, formerly Vertex AI, is the developer product where you build with the Agent Development Kit and deploy to Agent Engine. If you read an older page that says Agentspace, it means the app that is now called Gemini Enterprise. My advice for the next year of reading Google docs: treat Agentspace and Gemini Enterprise as the same product, and treat any Vertex AI page as the Agent Platform. The console path moved too, so bookmark the new location rather than trusting an old link.
Where Gemini Enterprise sits in the stack
Picture three layers. At the top is the app your employees see. In the middle are the agents, both the ones Google ships and the ones you register. At the bottom is the Agent Platform where those custom agents were actually built. Employees only ever touch the top. Developers live at the bottom. The middle is the meeting point, and getting an agent from bottom to top is the whole trick of this product.
The prebuilt agents you get on day one
The reason to buy on day one rather than build for a month is the set of agents Google ships in the box. Three matter. Deep Research is a multi step research agent: it plans a set of sub questions, searches your connected sources and, where you allow it, the public web, then returns a written report with citations back to what it read. NotebookLM is the grounded notebook: you give it a fixed set of documents and it answers strictly from those, which makes it the safer choice when you never want it to wander outside a defined corpus. Idea Generation is structured brainstorming, useful for planning and naming work but dependent on a prompting habit most staff do not have yet.
The distinction between Deep Research and NotebookLM is the one people get wrong. Deep Research is allowed to range; NotebookLM is deliberately fenced. If a compliance team asks whether an answer could ever cite something outside an approved document set, NotebookLM is your answer and Deep Research is not. Pick per use case, not per preference.
How a question moves through the system
When an employee types a question, the app searches first. It runs blended search across the sources you connected, Google Workspace, SharePoint, Jira, ServiceNow and the rest through managed connectors, and it respects each source document ACL as it goes. If the question only needs an answer, it returns grounded text with citations and stops. If the question implies an action, book the leave, file the ticket, draft the summary, it hands off to an agent from the gallery, which calls the tool or connector and comes back with a result. Search is the default path; an agent is the branch you take only when a plain answer is not enough.
flowchart LR
U[Employee question] --> S[Gemini Enterprise search]
S --> R{Needs an action?}
R -->|No| A[Grounded answer with citations]
R -->|Yes| G[Agent from the gallery]
G --> T[Tool or connector call]
T --> A
Register a custom agent from the gallery
Prebuilt agents cover the common cases. The reason you keep a developer team is the uncommon ones. You build a custom agent on the Agent Platform with the ADK, the same pattern from Part 13 and Part 21, deploy it to Agent Engine, then register it into Gemini Enterprise so it appears in the gallery for the right group of people. Once registered it behaves like any other agent in the app, with the same identity and governance around it.
The employee side is mostly no code, but the app is API addressable underneath, which matters when you want to test retrieval quality or wire the search into another internal tool. Here is a grounded query against an enterprise search engine, which still rides the Discovery Engine API surface under the covers.
# Query a Gemini Enterprise (Agentspace) search app for a grounded, cited answer
# The engine still uses the Discovery Engine API surface under the covers
PROJECT=my-proj
ENGINE=my-enterprise-search-engine
curl -X POST
-H "Authorization: Bearer $(gcloud auth print-access-token)"
-H "Content-Type: application/json"
"https://discoveryengine.googleapis.com/v1/projects/$PROJECT/locations/global/collections/default_collection/engines/$ENGINE/servingConfigs/default_search:answer"
-d '{"query":{"text":"What is our parental leave policy?"},"answerGenerationSpec":{"includeCitations":true}}'Expected output: a JSON answer object with an answer text field and a citations array pointing at the source documents the retriever used. Failure mode: a 403 usually means the caller lacks the Discovery Engine viewer role, and a 404 on the engine path almost always means the servingConfig id is wrong, not that the engine is missing. Copy the engine resource name from the console before you guess it.
What a seat actually costs
This is the part that changes how you budget. The Agent Platform bills per token and per runtime hour, the model from Part 21. Gemini Enterprise bills per seat per month, like any other productivity licence. That flips the buying question from how heavily will people use it to how many people get a licence at all. Below are the published Agentspace era tiers; treat the numbers as the shape of the pricing, because the rename may have reshuffled the tiers.
| Tier | Per seat / month | What a seat includes |
|---|---|---|
| NotebookLM Enterprise | ~$9 | NotebookLM grounded on documents you provide, with enterprise controls |
| Gemini Enterprise (standard) | ~$25 | Blended enterprise search, summaries, citations, people and multimodal search |
| Enterprise Plus | ~$45 | Follow up questions, actions in first and third party apps, upload and QA, custom and research agents |
Worked example
Take 500 employees on the standard tier at about $25 a seat. That is $12,500 a month, roughly $150,000 a year, before a single custom agent. Now move the 80 people who actually run actions and research agents to Plus at about $45 and leave the other 420 on standard: 80 times $45 plus 420 times $25 is $14,100 a month, about $1,600 more than putting everyone on standard and far less than the $22,500 you would pay to blanket all 500 on Plus.
So the design call is concrete: buy Plus for the power users, standard for everyone else, and do not put the whole company on the top tier for a feature most will never open.
Agentspace or build it yourself?
You can build almost everything Gemini Enterprise does on the Agent Platform yourself. The question is whether you should. The packaged product wins when you want reach across non technical staff, fast time to value, managed connectors, and identity and governance you did not have to wire. A custom build wins when the surface is narrow, embedded in your own product, needs a bespoke interface, or runs at a scale where per token beats per seat. Most companies want both: the app for the broad internal audience, a handful of custom agents for the workflows that are actually yours.
| Factor | Gemini Enterprise (buy) | Build on Agent Platform |
|---|---|---|
| Audience | Every employee, non technical | A specific app or workflow |
| Time to first value | Days, prebuilt agents on | Weeks of engineering |
| Search across sources | Included, connectors managed | You build ingestion and index |
| Identity and access | SSO and ACL aware in the box | You wire IAM and doc ACLs |
| Cost shape | Per seat, predictable | Per token plus runtime |
| Custom UX and embedding | Limited to the app surface | Full control |
For the contrast on another cloud, Amazon packages a similar employee assistant as Amazon Q Business, which I covered in the AWS series. The shape is the same across vendors: a per seat search and agent product on top of a per token developer platform.
Who can see which agent?
The governance that justifies the per seat price lives in the admin console. You decide which connectors are on, which agents appear for which organizational unit, and what data leaves the tenant. Agent visibility is scoped by organizational unit, so the finance agent shows only for finance and the HR agent only for HR, without building separate apps for each. Every query and answer is logged, which matters the day someone asks why an agent surfaced a particular document.
Two controls I check first on any rollout. The data residency setting, because a regulated customer will ask where the index and the prompts live, and the answer needs to be a named region rather than a shrug. And the connector scope, because the default is often wider than the pilot needs. Set both narrow, widen later. This is also where the audit trail and factsheet style records come from when compliance wants proof; it is far easier to turn logging on from day one than to reconstruct history after an incident. Governance is the reason a buyer picks the packaged product over a weekend of glue code, so treat the admin console as the real product, not an afterthought.
Is a Gemini Enterprise seat worth it?
For the broad internal audience, yes, and I do not say that about many packaged products. The distribution problem is real: a good agent nobody can find returns nothing. Gemini Enterprise solves the one thing custom builds keep failing at, which is getting the agent in front of everyone with search, single sign on and governance already handled. Start with NotebookLM and Deep Research on a pilot organizational unit, price the standard tier for the many and Plus for the few, and only build custom agents for the workflows that are genuinely yours. Where I would not buy it: a small technical team that wants one embedded agent in its own product, where per token on the Agent Platform is cheaper and the app surface only gets in the way.
Next in the series I move from the packaged app to how you measure whether any of these agents are actually good, with the Gen AI evaluation service. If you take one action from this part, run the pilot on one organizational unit before you licence the company.
References
Gemini Enterprise Agent Platform, formerly Vertex AI (Google Cloud)
Google Agentspace enables the agent driven enterprise (Google Cloud Blog)
Gemini Enterprise app product page (Google Cloud)
NotebookLM Enterprise, Gemini Enterprise, or both (Google Cloud docs)
About The Author
DrJha