For several years, most workplace AI has lived in a side panel. Someone opens a chat, asks a question, copies the answer, and pastes it into the email, spreadsheet, or ticket where the work actually happens.
Google wants to change that narrative.
During its Gemini at Work event, Google Cloud described a different arrangement: Gemini as a standing agent that can be given an outcome and left to finish the work inside systems a company already runs.
The product is the 'Gemini agent,' aimed first at business customers rather than the consumer Gemini app.
Google Cloud chief executive, Thomas Kurian, framed the change as a move from instructions to objectives.
The agent is meant to plan the steps, call skills and tools, connect to internal systems, and return finished work in documents, inboxes, and developer environments. Google says it can be reached from the web, phones, Windows and Mac desktops, the command line, Google Workspace, Microsoft 365, and Slack, with context kept in the cloud so the session does not reset when the person changes device.
Reporting from the event put the rollout in private preview for enterprise customers, with broader Workspace availability planned later.
What sits underneath is no longer a single model.
Google says the agent runs each job on the model that fits it, drawing today on the Gemini family and on Anthropic's Claude models, with other private and open models planned later.
Users can override the default and pick the model themselves.
The company presents the split as a cost and quality control: a smaller model for a routine step, a stronger one for a harder one, without moving the company’s context or data when the model changes.
In that design, Gemini is less a model people talk to and more a coordination layer through which other models can be called under one set of permissions and spend limits.
The tool layer is similarly broad on paper.
Google lists connections to Workspace, Microsoft Office and Teams, Slack, Confluence, Jira, Git, Salesforce, ServiceNow, BigQuery, Databricks, Postgres, and Snowflake, plus files on a desktop and any Model Context Protocol server inside or outside the company network.
Teams can publish tools to a company registry.
A data skill is meant to let both analysts and nontechnical staff ask questions in plain language and get reports, including generated code for engineers. Industry skills for financial services and legal work are in preview, with government, healthcare, and retail versions described as coming later.
Some of these agents are also given a workplace identity.
Coworker agents can receive an address at agents.company.com, their own storage, and a directory entry, and they can show up in version history under that name. A tasks view is supposed to show planning, delegation to subagents, skill loading, and progress.
Security is placed outside the model.
Each agent gets a cryptographic identity in a central registry, traffic passes through an Agent Gateway that can enforce rules such as blocking documents classified need-to-know, and code runs in isolated virtual machines with audit logs.
The uses follow from that design.
A scheduling request can draw on calendar context without the user restating who is free. An inbox can be sorted, and a reply drafted, inside Gmail rather than in a separate chat. An operations question can query a warehouse or a customer system and land back in a shared document. A developer task can touch Git and Jira and return code.
None of this intent is unique.
OpenAI and Meta have also shipped agents that act across apps, and other enterprise platforms already route work to more than one model.
Google’s bet is that the router, the connectors, and an existing Workspace install can sit in one product, with data left where it already lives.
The constraints are the usual ones for this class of software.
The agent is not a general release. Connecting it to mail, files, tickets, and databases concentrates access, which is why the registry, gateway, and audit trail are part of the announcement rather than a later add-on.
Routing across vendors also means quality and cost depend on which model is chosen for which step, and on whether the connectors return current data. If the routing and the logs hold up, Gemini functions as infrastructure that other models and tools run through.
If they do not, it remains another chat surface with a longer list of integrations.
Google is not alone in this shape of product. Other labs and enterprise platforms are also selling agents that hold context, call tools, and keep an identity across apps.
The difference Google is arguing for is that the agent, the model router, the Workspace apps, and the policy layer ship as one system, so customers do not assemble that stack themselves.
Whether that holds is an implementation question, not a launch-day one.
It will turn on connector reliability, on whether the audit trail is complete enough for a regulated team, and on whether routing across Gemini and Claude, and later other models, stays predictable once real workloads replace the demo.
Until those are visible outside the preview, the agent is a control plane with a wide set of promised connections, not yet a settled way of getting work done.
