Written by Jeremy Souffir Founder, JTS Tech Services
The short version, and the direct answer if you read nothing else. On 8 October, at its Gemini at Work event, Google announced a single "Gemini agent" for work and, with it, coworker agents. You describe a role, and Google sets up an agent that receives "its own Workspace account, including an email address, calendar, Drive, and presence in your company directory", at an address on a separate agents subdomain. It acts under its own identity, it sees only what people share with it, and every action it takes is written to an audit trail attributed to the agent rather than to a person. That is a genuinely better starting point than an agent running on somebody's password. But it moves the agent into the category of things your company already has rules for: accounts, mailboxes, group memberships, leavers. The software gives you the account. It does not give you the manager, and on the evidence of the announcement, nobody is going to assign one for you.
What did Google actually announce?
- A single agent for work. Google describes it as taking "objectives, not instructions", running jobs for hours or days in the cloud after your laptop closes, and choosing between Gemini models and Anthropic's Claude for each job.
- Coworker agents with a staff-style identity. Each gets a Workspace account with an email address on an agents subdomain, a calendar, persistent storage and a directory entry. Google says each identity is cryptographically attested and "governed like an employee, with least-privilege permissions".
- Access by sharing. A coworker agent "sees only what you share with it", and access follows the sharing and group membership your team already uses.
- Logging under the agent's name. Every action goes into an audit trail attributed to the agent, and the identity is stamped into any virtual machine it starts to run code.
- Controls at the edges. Agents run in a sandbox with its own network boundary, all traffic passes through what Google calls Agent Gateway, permissions are role-based and approved by your security administrators, and hard spend caps are set per project in the Cloud Billing Console. When a cap is hit, that project's agent pauses until someone resumes it.
- Reach beyond Google. It can be used from Microsoft 365 and Slack as well as Workspace, and it can connect to any MCP server inside or outside your network.
- What is not published. No price, no plan list, no general availability date and no data regions. The only availability Google states is for industry packs, in preview for financial services and legal. It has not said whether a coworker agent takes a Workspace seat, or how an agent is retired.
How this differs from last week's agents
On 1 October we wrote about OpenAI's dots, agents that each get their own cloud computer but are configured by the individual who subscribes, so the company finds out last. Google has gone the other way: the agent is provisioned into the company's own directory, under administrator-approved permissions, with logs the company owns. If you have to pick a shape for workplace agents, this is the easier one to govern. It is not the same as governed. A directory entry is a place to hang rules, and the rules still have to be written by someone inside your business.
Why does an email address change anything?
Because an email address is, by design, a thing other people send things to. Until now, most agents only read what you put in front of them. An agent with a mailbox has an inbox that fills on its own, from colleagues, from customers who reply to something it sent, and, depending on how your mail rules treat the agents subdomain, from anyone on the internet. Every message it reads is an instruction it might follow. We have written before about prompt injection, the habit agents have of believing everything they read. A mailbox is the most convenient delivery route for it yet invented, because sending an email to an address is exactly what that address is for.
Google's announcement says all traffic in and out passes through its gateway, enforcing your policies. It does not say, in the announcement, whether coworker agents accept mail from outside your domain by default. That is not a criticism, it is a question, and it is the first one to settle before the first agent goes live. Most agents doing internal work have no business receiving mail from strangers. The ones that do, a support triage agent for example, should be treated the way you treat a shared support inbox, with filtering, and with nothing in that inbox able to trigger an action without a person seeing it.
"Sees only what you share" is a promise about today
Google's access model is the right one: the agent starts with nothing and gets what people share. The catch is that access follows the sharing and membership your team already uses, and that is rarely tidy. People share whole folders to get one file across. People add a new colleague to the big team group so they can see the project channel, and the group happens to have the finance drive attached. Do that with an agent and it inherits the folder, the group and the drive, quietly, on the first afternoon.
With a human, this gets caught eventually by the human: someone notices they can see the salary spreadsheet and says so. An agent will not say so. It will use what it can see, because seeing things is its job. The question is not whether Google's model is safe on the day the account is created. It is what the account can reach after three months of colleagues being helpful, and whether anyone looks.
Logged under the agent's name. Then who answers for it?
Attributing every action to the agent rather than to a person is a real improvement for investigations. When something goes wrong you can see exactly what the agent did, without untangling it from the employee who launched it. But a log entry that says the agent did it is the start of a question, not the end of one. Who asked it to? Who approved the permissions it used? Who decides whether it keeps running tomorrow?
Microsoft has answered that in its own agent identity system by requiring a sponsor, a named business owner, for every agent identity. Google's announcement does not describe an equivalent requirement for coworker agents. That may come. In the meantime nothing stops you writing your own rule: no agent account without a named person who owns it, the way no shared mailbox should exist without one. It costs nothing and it is the single thing that makes the rest of the logging useful.
The two conclusions that both get this wrong
It's Google, the controls are built in
The controls are good, and they are controls, not policy. An administrator-approved role, a gateway and a spend cap all have to be set to something, and the defaults suit an average company, not yours. The spend cap is a good example: it is per project, so one runaway job pauses every agent in that project. Whether that is a sensible safety net or a way to stop your month-end close depends entirely on how you split projects, and Google cannot know that for you.
We're on Microsoft 365, so this is someone else's news
Two reasons it is not. The Gemini agent works from inside Microsoft 365 and Slack, so a team can adopt it without anyone moving off Microsoft. And Microsoft's own agent identities follow the same pattern: an account per agent, with an owner, in your directory. Whichever vendor your team ends up using, agents are becoming directory objects, and the questions below apply to all of them.
What is worth doing before the first agent account exists?
- Write a one-page agent register now, while it would have zero rows. Columns: agent name, what job it does, the named owner, what it can read, whether it can receive outside mail, its spend cap, and a review date. Starting it empty is easy. Starting it after twenty agents exist is an audit.
- Decide the mail rule for the agents subdomain. Default to internal-only. Any agent that needs outside mail gets a written reason, filtering, and a rule that nothing arriving from outside can trigger an action without a person approving it.
- Keep agents out of the big groups. Share specific folders and channels with agent accounts, never "everyone" or the all-company group. Ask whoever runs Workspace whether group membership can be restricted for the agents subdomain, and turn it on if so.
- Decide where the spend caps sit. Put each agent with a business-critical job in its own project, so a runaway job somewhere else cannot pause it, and so its cost lands on the right department.
- Write the leaver process for agents. When an agent's job ends, or its owner leaves, what happens to its mailbox, its Drive and its permissions? The answer for a human is already in your offboarding checklist. Add one line for agents.
- Ask your Workspace reseller or Google rep three questions. Does a coworker agent use a paid seat? Can external mail to the agents subdomain be blocked by default? How is an agent's access revoked in one step? The answers are not published yet, and they decide what this costs and how you run it.
The genuinely encouraging part
In August the honest description of most workplace agents was a static key, pasted once, owned by nobody. Last week it was a personal agent the company found out about last. This week one of the two largest office platforms shipped agents as named accounts in the company's own directory, with their own logs, under administrator approval. That is the shape security people have been asking for. It means agent governance can be done with tools your company already understands, accounts, groups, owners and leavers, rather than invented from scratch. The companies that write the register this month will spend the rest of the year adding rows to it instead of hunting for agents.
Where we fit
None of this is a build. It is a set of decisions about ownership, access and cost that somebody senior has to make once and then keep honest, and in most growing companies that person does not exist yet. That is what our Fractional Head of AI & Digital engagement is for. A few focused days a month, we set up the agent register and the rules behind it, decide with you which jobs deserve an agent and which do not, put the right owner on each one, work with whoever runs your Workspace or Microsoft 365 to set the mail, group and spend rules, and review the list every month so access does not drift. When Google publishes the price and the general availability date, you will be deciding how many agents to run, not discovering how many you already have.
Sources
- Google Cloud — Welcome to Gemini at Work 2026 (8 October 2026, Thomas Kurian's keynote post and the primary source: coworker agents with their own Workspace account, email, calendar, Drive and directory presence, "sees only what you share", audit trail attributed to the agent, attested identity, Agent Sandbox and Agent Gateway, per-project spend caps, Gemini and Claude models, MCP, Microsoft 365 and Slack, industry packs in preview)
- The Next Web — Google launches workplace AI agent that gets its own email address (independent summary, and for what the announcement leaves unspecified: pricing, general availability, regions and how permissions are revoked)
- Microsoft Learn — Administrative relationships in Microsoft Entra Agent ID (owners, sponsors and managers) (for the sponsor requirement on Microsoft's agent identities)
- JTS Tech Services — OpenAI's new agent has its own computer, its own browser and a 24/7 shift (1 October, OpenAI's dots and the personal-agent ownership gap)
- JTS Tech Services — Your AI agents are anonymous traffic inside your own SaaS stack (26 August, static API keys and agent identity tokens)
- JTS Tech Services — Your AI agent is a brilliant employee who believes everything it reads (prompt injection explained, the reason a mailbox matters)
