Google unveils Gemini work agent, with key features still in early access

Google announced its Gemini work agent on October 8, describing a service that can tackle documents, code and other business tasks across connected applications. The company says it can run work in the cloud and coordinate specialist sub‑agents, rather than requiring a person to keep a prompt window open. [Google’s launch announcement](https://cloud.google.com/blog/products/ai‑machine‑learning/welcome‑to‑gemini‑at‑work‑2026) sets out the proposed scope. The practical qualification appears on [Google’s product page](https://cloud.google.com/gemini‑enterprise): multi‑step background delegation, mobile and desktop access, and third‑party model choice remain in early access. The page offers a 30‑day Gemini Enterprise Plus trial, but that trial should not be read as a promise that every demonstrated capability is enabled. Teams planning a rollout need confirmation of their specific workflow’s availability before making it a dependency.

Google describes two operating roles: personal assistance and a coworker agent with its own identity. The latter receives access to the context a team shares with it. The announcement also describes agent‑attributed audit logs, sandboxed execution and project spending caps that pause work when reached. These are useful design commitments; a launch description alone does not establish how a particular company has configured them. [Source: Google Cloud](https://cloud.google.com/blog/products/ai‑machine‑learning/welcome‑to‑gemini‑at‑work‑2026) For an existing Gemini Enterprise deployment, [Google’s app‑access documentation](https://docs.cloud.google.com/gemini/enterprise/docs/iam‑policy‑for‑apps) provides a concrete warning: a project‑level Gemini Enterprise User role permits access across the project’s apps, even when narrower app policies exist. Google describes replacing that broad assignment with its Restricted User role, then granting access to the individual apps a person needs. An administrator reviewing a pilot should therefore inspect the project‑level roles as well as the app screen. A carefully restricted app is not sufficient evidence of isolation when broader access remains elsewhere.

Google’s [granular‑access guide](https://docs.cloud.google.com/gemini/enterprise/docs/iam‑policy‑for‑apps‑and‑data‑stores) treats permission to an app and permission to a connected data store as separate requirements. Under that configuration, a user needs both to receive answers from the data store. For supported third‑party connectors, document access also remains subject to permissions synchronized from the source system; granting cloud IAM access does not bypass those source controls. That distinction gives a pilot a useful negative test. Use an account that should access a general project collection but not a confidential collection, then check whether the latter stays unavailable. Repeat with an account that lacks access to the app itself. Scope those checks to the specific connector’s documented permission model. Record the expected result before running them so that a plausible answer does not become the definition of success.

Google’s [connector catalog](https://cloud.google.com/gemini‑enterprise/connectors) distinguishes Business‑edition integrations from those available for Standard and Plus. Its descriptions also differ in capability: Gong is listed for searching accounts and deals, while Freshservice explicitly includes ticket write operations. GitHub’s entry describes repository search, pull‑request tracking and code review. A familiar vendor name in the catalog does not, by itself, establish support for the particular read or write action your workflow requires. Before connecting a live system, list the intended action, the connector and edition it depends on, and the authority required to perform it. Retrieving a ticket and changing that ticket are different acceptance cases. For teams comparing integration approaches, the [OpenTools MCP directory](https://opentools.ai/mcp) offers another discovery route; an MCP listing should likewise be checked against the actual server’s tools and permissions rather than treated as a guarantee of compatibility.

A useful first assignment has a result someone can verify, a defined set of allowed inputs and a clear boundary around external changes. Drafting a status document from an approved project collection is easier to assess than an open‑ended instruction to manage the project. Check the resulting document against its sources, including omissions and stale material, before expanding the workflow. Keep four questions attached to that job: is the needed feature enabled for this account, which identity performs it, which systems can it read or change, and what happens when it reaches its spending limit? The October 8 announcement makes those controls part of the product proposition. The adoption decision still depends on the answers for the specific job a team plans to delegate. Follow [Google’s OpenTools organization page](https://opentools.ai/organizations/google) for the related tools and model catalog. Image credit: GualdimG / Wikimedia Commons. [Google’s Gradient Canopy office in Mountain View, photographed April 7, 2025](https://commons.wikimedia.org/wiki/File:Google%C2%B4s_Gradient_Canopy,_Mountain_View,_California_16.jpg). The photograph and responsive display crops are licensed under [CC BY‑SA 4.0](https://creativecommons.org/licenses/by‑sa/4.0/).