Google’s Gemini coworker arrives with its own identity, limits and audit trail

Google has introduced a Gemini agent designed to behave less like a chat window and more like a persistent worker. It can accept an objective, continue after a laptop closes, use enterprise tools, create temporary subagents and operate as a named coworker with its own email address, storage and directory presence. The announcement also separates the agent from the model underneath it: jobs can be routed across Google’s Gemini family and Anthropic’s Claude models.[1]

That combination changes the unit of adoption. Buying a model gives an organization a system that can generate or reason. Deploying a coworker agent gives the organization a new actor inside its operational environment. The actor can receive messages, open files, run code, create documents and coordinate other agents. Its usefulness therefore depends as much on identity, permissions, memory and stopping conditions as on model intelligence.

The email address is more important than it looks

A human employee’s account is a security boundary. It determines which files can be opened, which transactions can be initiated and whose name appears in an audit trail. Google is applying the same logic to coworker agents: the agent acts under its own identity, sees shared context and leaves actions attributed to that identity. A distinct account makes permissions and attribution easier to manage. It becomes a narrower boundary only when its actual access is limited; a separate identity with broad privileges can still cause broad harm.[1]

The central operational question is whether the assigned identity has only the permissions the task requires. An events agent may need a calendar, selected Drive folders and permission to draft messages. It probably does not need payroll files, production databases or authority to send contracts. Least privilege is not a one-time launch setting either. Roles expand, teams reorganize and shared folders accumulate. An agent that was appropriately constrained in January can become over-permissioned by June.

Memory creates value—and a correction problem

Google describes the agent as learning from interactions, prior work and organizational context. That can reduce repeated briefing and make long-running work more coherent. It can also preserve an obsolete assumption. A changed pricing rule, an abandoned product strategy or a corrected customer record may remain in a procedural or episodic memory unless the system has a clear way to replace, expire and audit what it learned.

The practical requirement is not simply a delete button. Organizations need to know which memory influenced an output, which source outranks it, how corrections propagate, and whether an old procedure can silently reappear. The more persistent the agent becomes, the more its memory should resemble governed operational data rather than an informal conversation history.

Model choice can hide responsibility

Routing a simple task to a cheaper model and a difficult one to a frontier model is economically sensible. But dynamic model choice introduces another record that must be preserved. When an output is challenged, the organization should be able to see which model handled each step, which tools it used and whether a later routing change alters the result. “Gemini did it” is too imprecise when Gemini is the orchestrator and several models may have contributed.

The new agent is therefore best understood as an operating layer for work, not merely another model release. The strongest deployments will make its identity, permissions, memory, model routing, evidence and costs visible together. A coworker earns trust not because it acts independently, but because the organization can tell exactly what it was allowed to do, what it actually did and how to stop or correct it.

Report an error or suggest a correction