InsightsGemini Enterprise
How we put one workflow live on Gemini Enterprise in 30 days
Week by week, the licences, identity, roles, data access, testing and go-live gates that put one workflow live on Gemini Enterprise, and what sets the real date.
- Written by
- CloudMagic engineering team
- Published
- Reading time
- 9 minutes
The short answer
Thirty days is enough to put one workflow live on Gemini Enterprise when the clock starts after access is approved and the scope is one queue with an owner who can say yes. Week one sets up licences in the right project and location, identity, roles and data connections, and files every access and privacy request. Weeks two and three build the agent and score it against your own past cases. Week four runs it with the people who do the work, and it goes live only if it passes the gates everyone agreed at the start.
Our first engagement with a new client is one workflow, live on Gemini Enterprise in thirty days, at a fixed fee. This post is how those thirty days run, with the Google settings and approvals that decide whether day 30 is a real date. Product details were checked against Google's documentation on November 11, 2026.
Two things come before day one. First, a call with one of our engineers, where you bring the workflow and the systems it touches. Then a fixed-fee discovery: we sit with the people who do the work, check what data the agent can reach, and write down what we would build, how we would test it and what it would cost. It ends with a written recommendation, and sometimes that recommendation is not to build.
What has to be true before day one?
Four things: one workflow with an owner who can say yes, a few hours a week from the people who do that work today, past cases with known outcomes to test against, and approved access to the systems involved. The thirty days count from the day access is approved, because that approval is the step a build team cannot speed up.
"One workflow" means one queue: prior authorizations for one service line, one type of AML alert, customer questions about one part of the catalog. When the scope crosses five departments, we split it and start with the one queue that matters most.
What happens week by week?
Week one sets up licences, identity, roles and data connections and fixes the answer key, weeks two and three build and score the agent, and week four runs it beside your team against the go-live gates. Discovery and the access requests come before day one, so the build never waits in an approval queue.
| Week | What happens | Who we need from you | Google settings and approvals | What exists at the end |
|---|---|---|---|---|
| Before day 1 | Discovery, written plan, access requests filed | Workflow owner, the people who do the work | Which edition, project and location | A plan with a scope, a test set outline and a fee |
| 1 | Licences, identity, roles, data connections; the answer key agreed | Your Google Cloud admin, identity team, workflow owner | Licences in the right project and location; identity provider; admin and user roles; data store connectors; tracing switched on | A working Gemini Enterprise app with your data connected and the gates written down |
| 2 | Build the agent and its tools; first scored runs | The people who do the work, for questions | Agent hosted on Agent Runtime; Model Armor called in the agent's code | An agent that runs end to end on test cases |
| 3 | Fix what the scores show; misuse and exposure tests; runs repeated | Workflow owner reviews results | Agent registered into Gemini Enterprise by an admin | Scores from every run against your past cases |
| 4 | Runs beside the team on real work; go-live decision | The team, the owner, security or compliance as needed | Admin preview; sharing with the chosen users or groups | One workflow live, or a written list of what failed |
What happens in week one?
Week one is setup and paperwork, and most of the risk to day 30 sits here.
Gemini Enterprise licences are specific to a Google Cloud project and a location. A user who needs access in both the US and global locations needs two licences, so decide where the app lives before anyone buys seats. Subscriptions are monthly or annual and belong to a billing account. Licences can be assigned by email address or automatically the first time a user signs in.
Edition matters for this work. The Business edition cannot run custom agents built in code. Standard, Plus, Pay-as-you-go and Frontline can. Frontline needs 150 or more Standard or Plus users in the organization, and Frontline users only get agents an administrator provisions for them. Plus can be tried at no cost for 30 days, which is often enough for discovery.
Then identity and roles. Admins get the Gemini Enterprise Admin role and users get the User role. We file the access requests for every system the agent will read in the first week, because those queues set the real date. If patient data is involved, a business associate agreement with Google Cloud has to be in place first: Gemini Enterprise and Gemini Enterprise Agent Platform are on Google's list of covered products, and you remain responsible for configuring them correctly, which we document control by control.
We also switch on Cloud Trace and the OpenTelemetry settings now, so the agent can be monitored after launch without a second round of approvals.
Do we need Google Workspace, or can we run it with Microsoft 365?
You do not need Google Workspace. Google Identity is Google's recommended identity provider, and a third-party provider that supports OIDC or SAML 2.0, such as Microsoft Entra ID or Okta, also works through Workforce Identity Federation.
One detail catches teams out. If Gemini Enterprise ingests data from SharePoint, OneDrive or Outlook, those sources require Microsoft Entra ID with Workforce Identity Federation, and document access follows Entra ID groups, even if another provider handles sign-in. Sources connected through federation instead of ingestion do not have that requirement. Decide which path each source takes in week one.
What happens in weeks two and three?
We build the agent and score it, every day, against the answer key agreed in week one.
Most first workflows need code: the agent reads systems of record, checks rules, keeps protected data out of the model's reach and writes figures that must match the source. We build those with the Agent Development Kit and host them on Agent Runtime, which is where Gemini Enterprise requires custom ADK agents to run. An administrator then registers the agent into your Gemini Enterprise app, which needs the Discovery Engine API on and draws on a pooled daily registration quota tied to your licences: one registration per Standard user per day, ten per Plus user and none for Frontline. Workflows that live entirely in your people's documents and email can sometimes be built in Workflow Builder (formerly Agent Designer), Gemini Enterprise's no-code builder, with no custom code at all.
Two settings are easy to miss. Model Armor settings in the Gemini Enterprise console do not protect custom ADK agents automatically, so the agent calls Model Armor from its own code. And the agent receives the signed-in user's email address from Gemini Enterprise, which is how it knows who is asking and what that person may see.
Testing runs alongside the build from the first day. Every case runs several times, next to a prompt-only version on the same model, with refusal tests and a count of the sensitive records the model received. Our post on how we test an AI agent before it does real work describes the method in full, with results from our demos.
What happens in week four, and what decides go-live?
The agent runs beside the team on real work, and the go-live decision is made against the gates agreed in week one.
Administrators can preview an agent before users see it, then share it with chosen users, groups or workforce identity pool groups. We share it first with the people who do the work, who use it alongside their normal process and tell us where it is wrong. The gates are the ones written before the first run: the right outcome on your past cases in every run, zero sensitive records outside scope reaching the model, every misuse request refused and logged, and a person approving anything that leaves the system.
If a gate fails, the workflow does not go live on day 30. You get a written list of what failed and what fixing it takes.
Which approvals usually set the real date?
Access approvals set the real date in almost every project, and the build is rarely the slow part. Each industry has its own queue, and we file every request in the first week.
| Industry | What usually slows it | What we do about it |
|---|---|---|
| Healthcare | EHR interface and access requests; privacy and data use reviews | File in week one; bring a written data flow the privacy officer can approve |
| Financial services | Model validation queues; vendor and security reviews; production data access | Give model risk the test set early; answer the security questionnaire before the build; start on masked copies |
| Retail | Code freezes before peak; catalog data that disagrees between systems | Plan around the trading calendar; list the conflicts in week one and agree which system wins |
What do we own on day 30?
You own everything: the code and configuration in your own repository, the test set and every score it produced, the runbooks, dashboards and audit log, and the Google Cloud project, which is yours from the first day.
After day 30 the choice is yours. We stay to run and improve the workflow, or your team takes it over with the code, the runbooks and the test set. Either way, the next workflow reuses the identity setup, the data connections, the test harness and the monitoring, so it starts well ahead of the first. Keep the test set running after launch too: rerun it whenever Google updates the model or you change a prompt or tool, and let online monitors score live traffic between runs.
When do we tell a client not to build?
When discovery shows the agent would not pay for itself or could not be trusted. The usual reasons are that nobody owns the workflow, there are no past cases with known outcomes to test against, the data the agent needs cannot be reached in a reasonable time, the volume is too low to matter, or a product the client already licenses does the job. Discovery ends with a written recommendation either way, and a no is a useful result.
Frequently asked questions
Which Gemini Enterprise edition do we need for a custom agent?
Standard, Plus, Pay-as-you-go or Frontline. The Business edition cannot run custom agents built in code, and Frontline users only see agents an administrator provisions.
Can we start with the free trial?
Gemini Enterprise Plus can be tried at no cost for 30 days. That is usually enough for discovery, and licences for the build should be bought in the project and location the app will live in.
What does it cost?
Discovery is a fixed fee, and the build is a fixed fee quoted at the end of discovery, once the scope and the test set are written down. Ask us whether Google funding applies to your project.
What if our documents are in SharePoint?
That works. Ingesting SharePoint, OneDrive or Outlook data needs Microsoft Entra ID with Workforce Identity Federation, so plan that setup in week one with your identity team.
Can we stop after discovery?
Yes. Discovery is a fixed fee on its own and ends with a written recommendation you keep, whether or not you build with us.
Sources
- Before you begin with Gemini Enterprise, Google Cloud
- Gemini Enterprise licences, Google Cloud
- Gemini Enterprise editions, Google Cloud
- Configure an identity provider, Google Cloud
- Register and manage ADK agents, Google Cloud
- Agents overview, Google Cloud
- Share custom agents, Google Cloud
- Gemini Enterprise release notes (Workflow Builder), Google Cloud
- HIPAA compliance on Google Cloud, Google Cloud
- Online monitors for agents, Google Cloud
- Gemini Enterprise product page (Plus trial), Google Cloud