Google's new universal Gemini agent is not a Copilot horse race — it's a boundary question. Here is the layer-by-layer split between what to hand the suite agent and what has to stay in an orchestration layer you own.
Last Updated: October 16, 2026
Google Cloud's Gemini agent, announced 8 October 2026, is genuinely strong inside the perimeter where identity, data and audit already exist: Gmail, Drive, Docs, Sheets, Chat, Calendar. It is weak at the seams that actually kill rollouts — ERP write-back, vendor portals with no API, telephony, non-Google CRMs, and any action that needs verification plus rollback. For a company already on Workspace, roughly 40–60% of a typical n8n or Make pilot is read-mostly retrieval and drafting that should be deleted and handed to the suite agent. The rest is your action tier and should stay on infrastructure you own. The three costs nobody models in month one are the identity model, memory and state ownership, and the per-seat-plus-quota meter colliding with per-run economics.
What Google actually shipped on 8 October
At Gemini at Work 2026, Thomas Kurian introduced a single agent that answers questions, handles knowledge work, generates media, and writes and runs code from one prompt box, reachable from web, iOS, Android, Windows, Mac, the command line, Workspace, Microsoft 365, ServiceNow and Slack (SiliconANGLE, October 2026). It runs persistently in the cloud with shared memory, spins up temporary sub-agents with their own identities, and supports long-lived “coworker” agents that hold a Workspace account, storage and an @agents.company.com address (Futurum Group, October 2026). Model routing covers Google's own models plus Anthropic's Claude today, with other closed and open models promised (Constellation Research, October 2026).
The governance story is the part worth reading twice. Google reduced agent governance to four questions — who the agent is, what it may do, what it did and where you can see it, and what it must never touch — answered with cryptographically attested agent identity, role-based permissions propagated through OAuth, and an audit trail where every action is attributed to the agent rather than to a person (Google Cloud, October 2026). Spend control is a hard cap set per project in the Cloud Billing Console; when it trips, that project's agent pauses and an admin resumes it with one click.
You delegate an outcome and come back to finished work.
— Thomas Kurian, CEO, Google Cloud, Constellation Research
The honest caveat, which most coverage skipped: the Gemini agent itself is in private preview, with no published price and no published general-availability date for the agent, its sub-agents or coworker accounts — the product page's call to action is contact sales (eesel, October 2026). Industry-specific versions for financial services and legal are in preview, with government, healthcare and retail next (Reworked, October 2026). You cannot architect a 2027 budget around an unpriced private preview, and you should not let a procurement conversation pretend otherwise.
Perimeter work and seam work are different products
A suite-native agent inherits three things you would otherwise spend a quarter building: an identity system that already knows who everyone is, a data layer where the documents already live with ACLs attached, and an audit surface your security team already accepts. Inside that perimeter the Gemini agent is not competing with your orchestration layer on features; it is competing on the fact that you never have to write a connector, mint a token, or explain to compliance where the vectors went.
Seam work is everything else. A seam is any point where the agent has to cross into a system Google does not control, with a side effect that matters: posting a journal entry to NetSuite, updating a quote in a non-Google CRM, submitting a claim through a vendor portal with no public API, placing an outbound call, writing to a 15-year-old ERP whose only integration surface is a nightly SFTP drop. Seams are where the hard engineering lives — idempotency keys, retries with backoff, compensating transactions, dead-letter queues, replay from a known offset, and a rollback path that a human can trigger at 2am.
Google is explicit that the agent connects outward through an Agent Gateway and propagates identity via OAuth. That is the right design, and it is also the tell: it assumes the far side speaks OAuth and exposes an API with semantics the agent can reason about. A large share of the integrations that break enterprise automation do neither. The gateway is billed on Agent Compute vCPU-hours like everything else (Google Cloud pricing), which tells you Google treats egress to your systems as a runtime, not as a guaranteed-delivery messaging tier. Guaranteed delivery is your problem.
The four-question boundary test
If the workflow only reads, summarises, drafts or routes inside Workspace, stop here. Give it to the suite agent.
A draft email is reversible. A posted invoice, a shipped order, a sent SMS and a filed regulatory form are not. Irreversible writes need an owned action tier with a compensating transaction.
If the answer is screen-scraping, SFTP, SOAP with a shared service account, or a telephony leg, the agent should call your tool, not the system.
Anything with an on-call owner needs run history, replay and alerting you control. A paused agent and a silent agent look identical from the prompt box.
The layer-by-layer split
This is the table I would put in front of a steering committee. It is deliberately boring: the split follows side-effect class, not vendor preference.
| Layer | Hand to the Gemini agent | Keep in an orchestration layer you own |
|---|---|---|
| Retrieval over corporate documents | Yes, if the corpus is Drive, Gmail, Chat and Calendar — ACLs are already enforced | Only for non-Google corpora: on-prem file shares, legacy DMS, data you cannot index in Google's cloud |
| Drafting, summarising, translating, media | Yes — this is the strongest case and the cheapest to migrate | Only where you need deterministic templates or a specific model you have already evaluated |
| Inline Workspace actions | Yes — filing, labelling, scheduling, slide and sheet manipulation | Rarely worth owning |
| Scheduled and event-triggered jobs | Low-stakes internal digests and research runs | Anything with an SLA, a customer-facing output, or a downstream dependency |
| Writes to ERP, finance, billing, inventory | No — propose the write, do not perform it | Yes: idempotency, two-phase approval, compensating transactions, audit of the attempt as well as the result |
| Non-Google CRM and ticketing | Read and draft via connector | State transitions, assignment rules, SLA clocks |
| Vendor portals, RPA, browser automation | No — brittle, session-bound, and the failure is silent | Yes, with screenshot evidence and a human verification step |
| Telephony, SMS, WhatsApp | No | Yes — latency budgets, call state and regulatory recording live here |
| Human approvals and rollback | Can request approval | Must own the state machine, the timeout and the undo |
| Cross-system reconciliation | Can explain a discrepancy | Must decide and act on it |
The pattern underneath: let the suite agent decide and propose, let your layer execute and prove. In practice that means exposing your existing workflows as callable tools rather than retiring them — which is exactly what an Agent Gateway and an agent-callable API are for. We build that action tier as plain, versioned, replayable services; see how we structure automation builds if you want the shape of it.
The 40–60% of your pilot that should be deleted
If your company is already on Workspace and you stood up an independent agent stack in the last 18 months, a large chunk of it is now redundant. Delete, specifically: RAG pipelines you built over Drive; Gmail triage and labelling flows; meeting-notes and transcript summarisers; document-generation chains that fill a template from a sheet; internal Q&A bots over policy docs; Slack notifiers whose only logic is string formatting; and any manually triggered prompt chain that a person runs by pasting into a form. Each of these is a connector, an embedding store and a permissions mirror that you are maintaining in order to reproduce an ACL model Google already enforces for you.
Do not delete: anything whose output is a side effect in a third-party system; anything with a runbook; anything where the data source is not Google; anything running at volumes where quota ceilings bite; and anything a regulator might ask you to reconstruct. The test is not “could the agent do this?” It is “if this silently stops for six hours, does anyone find out from the system rather than from a customer?”
Keeping your own RAG index over Google Drive
It feels like an asset because it took a quarter to build. It is a liability: you are now responsible for re-indexing on every document change, for mirroring sharing-permission changes into your vector store, and for the moment a stale ACL leaks an HR file into a chat answer. Permission drift in a mirrored index is the single most common silent data-exposure bug I see in agent stacks, and it never shows up in testing because test corpora do not get reshared.
Three lock-in costs that only appear in month four
1. The identity model
Attributing every action to a cryptographically attested agent identity rather than to a borrowed human account is the correct design, and it is a real advance over the shared-service-account mess most automation stacks run on. The cost is that agent identity now originates in Google's directory. Coworker agents hold Workspace accounts, which means provisioning, licensing, offboarding and discovery obligations follow them. When an agent has to act in a system that cannot consume a propagated OAuth identity — the legacy ERP, the bank portal, the EDI gateway — you fall back to a credential your layer holds, and the clean attribution chain breaks at exactly the point an auditor cares about. Plan the fallback explicitly: a broker in your tier that exchanges the agent's assertion for a scoped, short-lived credential and logs both sides of the swap.
2. Memory and state ownership
Persistent memory and a personalization graph in the cloud are what make multi-day tasks work. They also mean your operational logic starts migrating into a store you cannot diff, branch or code-review. Six months in, nobody can say why the agent routes a certain vendor's invoices differently, because the reason is in learned memory rather than in a file in git. Treat memory as a cache of preferences, never as the system of record for business rules. Keep rules in versioned config your layer reads; let the agent personalise presentation, not policy.
3. Per-seat plus quota versus per-run
Two meters run at once. Seats carry daily quotas — 160 assistant queries per user per day on Standard and 200 on Plus, pooled storage of 30 GiB versus 75 GiB, Deep Research runs capped at 3 and 10 per day, and no-code agent creation limited to one agent per day on Standard against ten on Plus (Google Cloud Documentation). Underneath, agent execution is metered: Agent Compute at $0.085 per vCPU-hour after 50 free hours per account per month, Agent Memory at $0.009 per GiB-hour, billed to the second, with idle time between turns excluded and one- and three-year savings plans dropping the compute rate to $0.0765 and $0.068 (Google Cloud pricing). Throughput has its own ceilings — 90 agent queries per minute and 300 session event appends per minute on the platform defaults (Google Cloud Documentation).
Per-seat pricing assumes a human in the loop consuming their own quota. Event-triggered automation does not work that way: ten thousand webhook-driven runs do not map to ten thousand seats, and a single power user can exhaust a daily allowance by lunchtime. Kurian's own framing was that an agent programme succeeds or stalls on whether it can be governed and whether it can be afforded, noting per-token prices have fallen 98% since 2024 while volume exploded (PPC Land, 2026). Cheap tokens do not make a per-seat meter behave like a per-run meter. Model both. If your workload is machine-triggered and high-volume, the orchestration layer is almost always cheaper per unit of work — and the comparison is worth re-running whenever model pricing shifts.
Treating a spend cap as a cost control instead of an outage
Project-level spend caps pause that project's agents when the limit trips, resumable with one click in the console. Finance loves this. It means a budget event is now a production event: if a customer-facing workflow sits behind the capped project, your SLA breach starts the moment the cap fires, on a weekend, with no page to anyone.
A migration sequence that does not strand you
The failure mode is committing to one side. Teams that rip out the orchestration layer discover in month three that half their value was in the seams; teams that ignore the suite agent keep paying engineers to maintain a worse copy of Drive search.
Inventory every workflow by side-effect class, not by department: read-only, reversible write, irreversible write, external party. This list, not a feature comparison, is the decision document.
Freeze net-new builds in the read-only category. Stop adding connectors to Google-resident data. Nothing gets deleted yet.
Run the read-only category in parallel on the suite agent and measure answer quality against your existing pipeline on a fixed question set. Parallel running is the only honest evaluation; retrospective satisfaction surveys are not.
Expose your action tier as callable tools with explicit schemas, idempotency keys and a dry-run mode. The agent proposes; your tool executes and returns a verifiable receipt.
Replay 90 days of real run volume against both meters — seats plus quota versus per-run compute — before signing anything multi-year. This is the month the surprise arrives, so make it arrive in a spreadsheet.
Procurement note: the agent is in private preview and unpriced, so any commitment you sign now is a commitment to Gemini Enterprise seats and platform consumption, not to the agent you watched in the keynote. Ask for the agent's pricing model in writing before accepting a multi-year seat commitment, and ask what happens to coworker-agent accounts at renewal. If you want a second pair of eyes on the boundary and the contract read, that is what our AI integration work is for.
Where the honest answer is still “do not automate this yet”
Four categories remain genuinely unsafe to hand to any agent, suite-native or otherwise. Irreversible financial writes without a human-verified receipt — payment initiation, payroll runs, regulatory filings — because the agent's confidence is uncorrelated with the transaction's correctness and the rollback is a phone call to a bank. Vendor portals with no API, where a layout change turns a successful-looking run into a silent no-op. Real-time telephony with a write side effect, where latency budgets and call state make retry semantics ugly. And cross-organisation agent-to-agent interaction, where you are trusting a counterparty's identity model with no way to audit it.
Gartner's forecast that over 40% of agentic AI projects will be cancelled by the end of 2027 attributes the failures to escalating costs, unclear business value and inadequate risk controls — not to model capability (Gartner, June 2025). A suite-native agent materially improves two of those three: cost visibility through per-project caps and chargeback, and risk controls through attested identity and action-level audit. It does nothing for the third. Unclear business value is a scoping problem, and consolidating onto one vendor's prompt box does not scope anything.
One last read on the market. The orchestration layer is not a doomed category being absorbed — SAP put a strategic investment into n8n in May 2026 at a $5.2B valuation alongside a commercial agreement to embed it inside Joule Studio (Sacra, 2026). The system-of-record vendors are buying orchestration precisely because the seams between their systems are where the work is. The suite agent owns the prompt box. Somebody still has to own the handoff, and the economics of that layer have never looked healthier. If you want help drawing the line for your stack, start here.
Frequently Asked Questions
Does the Gemini Enterprise agent replace n8n, Make or a custom agent stack?
It replaces the read-mostly half. Retrieval over Drive and Gmail, drafting, summarising and inline Workspace actions are cheaper and safer as suite-native features because identity, permissions and audit already exist there. It does not replace the action tier: writes to ERP and non-Google systems, vendor portals, telephony, approval state machines and rollback logic still need orchestration you own and can replay.
How is the Gemini agent priced?
The agent itself is in private preview with no published price or GA date. What is published is the surrounding platform: Gemini Enterprise seats carry daily quotas such as 160 assistant queries per user on Standard and 200 on Plus, while agent execution meters Agent Compute at $0.085 per vCPU-hour after 50 free hours per account per month and Agent Memory at $0.009 per GiB-hour.
What are the real lock-in risks?
Three. Identity: agent identities originate in Google's directory and coworker agents hold Workspace accounts, so provisioning and offboarding follow Google. Memory: persistent agent memory is not a versionable artefact, so business rules drift into a store you cannot diff. Pricing: a per-seat meter with daily quotas behaves badly for machine-triggered, high-volume work that your orchestration layer prices per run.
Which workflows should I delete from my orchestration tool first?
Start with any RAG pipeline you built over Google Drive, Gmail triage and labelling, meeting-notes summarisers, template document generation from Sheets, internal policy Q&A bots, and Slack notifiers whose only logic is string formatting. These duplicate permission models Google already enforces and carry real ACL-drift risk. Keep anything with an external side effect, a runbook, a non-Google data source or a regulatory audit trail.
Do the project spend caps create an availability risk?
Yes, by design. A hard cap set in the Cloud Billing Console pauses that project's agents when it trips, and an admin resumes with one click. That is excellent cost governance and a genuine outage mode for anything customer-facing. Isolate critical workflows in their own project, alert at 70% and 90% of budget, and keep a non-agent fallback for the handful of flows that cannot pause.
How does this compare to Microsoft's suite-native agent strategy?
The boundary logic is identical regardless of which suite you are on. Both vendors are strongest where their own identity, content and audit systems already sit, and both weaken at writes into third-party systems of record. Choose by where your documents and directory live, not by feature checklists, and keep the action tier vendor-neutral so a suite decision never becomes an automation migration.
Can the Gemini agent call my existing workflows?
That is the intended integration pattern. Google exposes outbound connectivity through an Agent Gateway with OAuth-propagated agent identity, so your workflows become callable tools with explicit schemas. Build them with idempotency keys, a dry-run mode and a verifiable receipt returned to the agent, so the agent proposes an action and your layer executes, proves and can reverse it.
Research digest
AI Research Briefing
Honest insights on AI agents, Small Language Models, and local RAG. No hype. Only when we have something worth sending.
- No hype, just measurable outcomes
- Read by 2,400+ engineers
- Unsubscribe anytime
