Google's coworker agents get an email address, a calendar and a directory entry. Who offboards them?

Somewhere in a company directory next year, between a new analyst and a contractor, there will be an entry ending in @agents.company.com. It will have a calendar, a Drive folder and colleagues who share files with it. Nobody in HR will have hired it, and nobody may know how to let it go.

That is the picture Google drew on October 8. In his Gemini at Work keynote, Thomas Kurian presented Gemini as “a single, universal agent for work” that runs in the cloud, keeps working “after you close your laptop” and splits large jobs across sub-agents. Two kinds of agent in that design carry their own identity.

Coworker agents have “a persistent, defined role and operational presence across days, sessions, and multiple changing responsibilities”. In Workspace, Google says, such an agent “receives its own Workspace account, including an email address, calendar, Drive, and presence in your company directory”, and it can only see the context that people give it.

Sub-agents are “temporary, job-specific agents, each with their own identity”, created on the fly for multi-step tasks that can run for hours or days.

Around them, Google described the controls: identities that are “cryptographically attested and governed like an employee”, role-based permissions approved by security administrators, OAuth propagation when an agent reaches an external system, an audit trail “attributed to the agent rather than to a person”, an Agent Sandbox with its own network boundary, and an Agent Gateway that inspects traffic into, out of and between agents.

A caution before planning around any of it. Apart from the industry editions, which Google says are in preview, the keynote gives no release status, pricing or regional availability for these pieces. Read it as an architecture direction and check the product documentation before you commit a roadmap to it.

Two kinds of agent, two identity clocks

The design is more useful than its marketing because it separates two problems that enterprise identity teams already know, and already handle in different places.

A coworker agent behaves like an employee. It joins, takes on responsibilities, changes role and eventually leaves. In most companies, that lifecycle is driven from HR records and run through identity governance: a joiner gets a baseline, a mover triggers an access review, a leaver is disabled the same day.

A sub-agent behaves like a workload. It exists for one job, should hold credentials only for that job, and should vanish with it. That lifecycle belongs to platform teams, short-lived credentials and automation, not to quarterly reviews.

Google puts both inside one product. Your organization still has to decide which process owns each, because the vendor can issue the identity but cannot decide who is accountable for it.

How long an agent identity lives

One jobMonths

1. Sub-agentIssued per task, must expire with it
2. Long-running jobKeeps running for hours or days
3. Coworker agentEmail, calendar, Drive, directory entry
4. Dormant coworkerStill holds access nobody uses

The mover is the hard case

Google’s phrase “multiple changing responsibilities” is the part to read twice. When a person changes role, the transfer is an event that someone can attach a review to. When an agent’s responsibilities drift because colleagues keep handing it new work, there is no event. The permissions, the shared folders and the four kinds of memory Google describes (session, semantic, procedural, including “skills it writes for itself”, and episodic) all stay unless someone removes them.

Access creep takes years with people. An agent given new duties every week can accumulate the same sprawl in a month.

There is a quieter point in the design too. If a coworker agent can only see “the context that you or your team members provide”, then sharing a folder with it is how it gets provisioned. Most companies do not review Drive sharing as an access grant. With coworker agents, they will need to.

What retiring an agent means

Offboarding a person is well rehearsed: disable the account, transfer the files, revoke the tokens. A coworker agent adds items that no current checklist has:

• Memory and self-written skills. Keep, archive or delete? Skills an agent wrote for itself may encode how a team actually works.
• Grants in other systems. When identity is propagated through OAuth, tokens and consents live in the external systems, not only in Google’s console.
• The mailbox. Suppliers and customers may keep writing to an agent that no longer exists, and someone should own what arrives.

Microsoft’s own IT gives a useful reference point from the other side of the market. Its internal guide, published the same day, sets a 60-day inactivity threshold for agents built in Microsoft 365 Copilot’s Agent Builder, with alerts and automated cleanup. Inactivity rules like that one are a reasonable floor for coworker agents as well.

Attribution is half of accountability

Recording actions under the agent’s own identity, rather than a person’s, fixes a real problem: auditors can finally tell an employee’s action from an agent’s. But “the agent did it” is only half of what an investigation needs. The other half is who gave the agent the objective and who approved its permissions. That is why we argued that agents need what employees already have: an ID, and also a manager, a budget and a file.

The same logic applies to the Gateway. A policy such as Google’s example, “agents may not open documents classified Need to Know”, is only as good as the labeling behind it. For coworker agents, label coverage becomes agent security coverage.

None of this argues against Google’s design. Separate, attested identities with their own audit trail are what we would ask for. The work it creates sits on the customer side: decide which lifecycle owns each kind of agent, define what triggers a review when an agent’s role drifts, and write the leaver checklist before the first coworker agent gets its email address.