Use What You Already Pay For: An AI Tooling Strategy for a Google Workspace Company

This is an adapted digest of an internal strategy memo. The company runs on Google Workspace, and the memo's starting question was deliberately unglamorous: before buying anything new, what does the AI budget we are already paying actually cover?

That framing turned out to shape every subsequent decision, so it is worth writing down.

Four principles ran through the whole document:

- Do not reinvent the wheel. If a standard tool covers it, do not build it.
- Stay in proportion, and stay legitimate. No over-investment, and no workarounds that route around policy.
- Separate the roles. Most staff use. A small number build.
- Measure demand before you stack. Deploy the standard tools first, measure how much of the demand they absorb, and only then size the investment for the remainder.

That last one is the one most organizations skip.

Start from what is already paid for

Since January 2025, Gemini has been included in Google Workspace plans — Gmail, Docs, Sheets, Meet, NotebookLM — with no separate AI charge. For a Workspace company, that is a capability already on the balance sheet. Exhausting it is the correct first move, not a fallback.

Tier one: share the Gem, not the prompt

The first step for non-builders is not training on prompt engineering. It is Gems — custom Gemini configurations that one person builds and everyone else reuses.

The point is to stop prompt craft from dying as individual technique. When someone finds a formulation that reliably produces a good contract summary or a good meeting digest, that formulation should become a shared asset rather than a habit locked in one person's head. Gems make that transfer concrete, and they stay inside Workspace with no additional billing.

The second pattern is more consequential:

GAS organizes the data  →  a Spreadsheet sits in the middle  →  a human feeds it to Gemini

The temptation is to wire the data source straight into the model. The memo argues against it. Putting a spreadsheet in the middle gives you a visible intermediate form: a human can inspect and correct the data before it reaches the model, and when an API is unavailable the same pipeline still runs on a CSV export. It refuses to make the process a black box, at the cost of one manual step.

Then measure. In most workplaces the majority of real demand is satisfied at this tier. So rather than jumping to custom GAS development, specialized tools, or a VPS, deploy tier one broadly first and measure two numbers: how much demand the standard tools absorb, and how much remains. The size of the remainder — not enthusiasm — determines whether the next tier is justified.

Specialized tools: pick freely, but draw the data line first

A Google core does not mean a Google-only stack. Where Gemini is weak, specialized tools fill the gap — Claude and Claude Code for involved implementation and judgment work, presentation and diagramming tools for specific outputs.

The risk with picking tools freely is not the tools. It is that "what data may I put in this?" never gets answered. So the line gets drawn before anyone starts picking:

- Confidential and personal data does not go in, as a default rule.
- Anything needed for real work goes through an application process that establishes three things: where the data goes, whether it is used for training, and whether the account can be recovered when the employee leaves.
- Subscriptions are never signed up for by individuals — cancelling them later becomes disproportionately difficult.

Draw that one line and you can graze freely without losing control.

The Microsoft comparison: where do your data and identity live?

The structural difference shows up in the billing model.

Google includes Gemini in the Workspace plan. Microsoft has historically sold Copilot as a per-seat add-on layered on the base licence — which tends to produce a two-tier organization where only the high-value seats get AI, and which costs more on an ongoing basis for the same headcount.

That model shifted on July 1, 2026, when Microsoft raised commercial Microsoft 365 prices by roughly 5% to 43% depending on tier, folded Copilot Chat into every base subscription, and introduced bundled "with Copilot" plans. Office 365 E3 went from $23.00 to $26.00 per user per month; Microsoft 365 Business Standard from $12.50 to $14.00. Existing customers stay on current pricing until renewal.

But the pricing is the surface. The real question is: which box do your documents, your identity and your communications already live in? If they live in Microsoft, Copilot's depth of grounding is a genuine draw. If they live in Google, there is no motivation to move — and the switching cost is paid in the one currency that matters, which is where identity is anchored.

One related note from the memo: Microsoft's AI Builder is credit-consumption based, which makes cost forecasting difficult and tends to get expensive once it is running real workloads. For a Google-based organization there is little reason to reach for it.

(Assessment of which platform performs better overall is the memo's own judgment, not a benchmark result.)

The free-CLI era is over

This is the section that changes an actual engineering habit.

"Keep costs down by using the free command-line tool" no longer describes reality. Gemini CLI stopped serving Google AI Pro, Ultra and free-tier requests on June 18, 2026, replaced by Antigravity CLI — invoked as agy, a closed-source Go binary built for asynchronous multi-agent workflows that the previous single-agent TypeScript architecture could not support.

What changed materially:

The weekly compute cap is the part that bites: heavy users report exhausting it quickly and then waiting out multi-day cooldowns.

The open-source Gemini CLI itself still exists, and it still runs if you supply your own metered API key. So the practical cost-optimization move is not "find the free CLI." It is call the cheap Flash-class models through a metered API key and treat inference as a line item. It is no longer free, and designs that assumed otherwise need revisiting.

Worth noting who was not affected: organizations holding Gemini Code Assist Standard or Enterprise licences, or using paid API keys, kept uninterrupted access. The companies with proper contracts absorbed the smallest shock — which is itself an argument for operating inside a managed, licensed setup rather than on consumer free tiers.

Partner networks: contract first, then technology

For a franchise or partner network, the approach is to pull everyone onto the same Google estate: headquarters issues Workspace accounts to each location, work happens inside that estate, and headquarters retains the ability to audit the data.

The ordering here is the interesting part. The legitimacy of that audit capability does not come from the technology. It comes from the franchise agreement — consent to "use Google Workspace" and "permit headquarters data audit" is obtained at the point of joining. Establish the legal basis, then deploy the technical control. Not the other way around.

Self-hosted infrastructure (a VPS behind Cloudflare Access) is reserved for cases where the standard tools genuinely cannot cover the requirement, sized to actual load rather than anticipated load.

There is a threshold worth identifying early: the moment headquarters starts aggregating customer data across all locations for cross-store statistical analysis, the personal-data obligations step up considerably. That needs explanation and consent from both the franchisees and the end customers — and it is a contract design problem before it is a technical one. Deciding whether "headquarters aggregation and analysis of customer data" belongs in the joining agreement is much cheaper to settle early than late.

Leak prevention runs on two wheels

Once customer data is centralized, protection has to be designed as technology and people together. Neither wheel holds alone: technology detects and blocks, human practice keeps the assumptions behind that technology intact.

Technology side. Pattern-flagging for personal data (names, phone numbers, card numbers) ahead of any AI input or external transmission, including secret-scanning against accidental commits. Access and operation logging, held in tamper-resistant form, with unusual volume or timing surfaced as anomalies. Scheduled automated sweeps for the failures nobody notices — over-broad sharing links, public settings left on, dormant accounts, expiring certificates. Commercial endpoint and vulnerability tooling for the areas that are unwise to build yourself. Restricted reachability: server maintenance over a P2P VPN with SSH never exposed to the internet, user access consolidated behind Cloudflare Access and Tunnel. And data minimization, which is the only measure that is unconditionally effective — data you do not hold cannot leak.

Human side. Device inventory, no customer data on personal machines, MDM with disk encryption and remote wipe. This includes an uncomfortable case worth naming explicitly: someone photographing a screen or recording audio to process information outside the managed environment. That incentive exists and has to be addressed rather than assumed away. Credentials never pasted into code or chat, only shared through a secrets mechanism, with revocation wired into the leaver process. A register of every port opened and tunnel established, reviewed periodically and closed when no longer needed — "opened it temporarily" is how permanent exposure happens. Least privilege, promptly revisited on role change. And training that assumes human error will occur, so the operating goal is to notice and reverse, not to prevent perfectly.

Audit: the part that is usually skipped

Automations and internal apps do not get to be finished. They get reviewed — quarterly by default, and on any significant change.

The memo enumerates checks per target: GAS automations (who owns them, are any left behind by departed staff, trigger health, external destinations, over-broad sharing), metered API keys (who issued them, are they hard-coded anywhere, sudden usage or billing spikes, unexpected callers, quota alerts configured), third-party AI services (was it approved, does the input contain confidential data, is training opt-out set, can the account be recovered), internal apps (does the permission design match the spec, retention scope, is it quietly obsolete), infrastructure (patch status, exposure, log review, certificate expiry, restore procedure), and source control (committed secrets, repository visibility, stale access).

Above those sits the control that most organizations get only half right — the approval process, before and after.

Before: every new AI service, external tool, API or environment goes through an application that must state its purpose, the categories of data going in, where that data goes and whether it trains on it, expected cost, and recoverability on departure — plus whether a standard tool could do the job instead. With one caveat the memo is emphatic about: vague, non-technical refusals, or refusals with no alternative offered, create chaos. Whoever holds the approval authority has to actually understand the technology.

After: approved does not mean compliant. The application register gets reconciled against reality — actual accounts, API keys, billing, access logs — to surface unapproved usage, drift from what was approved, and abandoned permissions.

Pre-approval alone becomes a rubber stamp. Post-audit alone arrives too late. The register is the source of truth, and the discipline is reconciling it against what is actually running.

And do not put it all on one person. Three moves distribute the load: push anything mechanizable into automation (usage, access logs, secret detection, vulnerability scanning collected automatically and reported on a schedule, so humans only read exceptions); bring in an outside eye at a fixed interval, such as an annual external security assessment that verifies the internal review; and build toward mutual review, where whoever builds a thing is not the person who reviews it — a staffing goal even if it is not achievable yet.

What generalizes

Strip out the company-specific parts and three things survive:

Measure demand at the cheapest tier first. The instinct is to scope the ambitious build. The discipline is to deploy what you already own, see what is left over, and size the build to the remainder.

Get the legal basis before deploying the technical control. Auditability that rests only on your admin privileges is brittle. Auditability that rests on a signed agreement is not.

Design the approval process in both directions. Almost everyone builds the intake form. Far fewer reconcile the register against what is actually running six months later, which is where the drift lives.

---

Adapted from an internal strategy memo. Product pricing and specifications change; the Google and Microsoft figures here reflect publicly reported terms as of 2026-08-16 and should be re-checked against current sources before anyone acts on them.