Google announced a Gemini agent for work on October 8. Google says a team can create a coworker agent with its own account, email address, calendar, Drive, and directory presence. Colleagues can add it to a Chat space or mention it in a document. Give the agent one bounded assignment and its own access. Then test whether people can tell what it did, what it could not see, and who approved the result. An address in the directory is a useful boundary, not a promotion to employee.
In brief: A shared AI agent needs a defined role, limited access, a place to leave its work, and a person who can stop or correct it. Start there before giving it a company email address.
An identity changes the conversation
A shared chatbot usually lives behind somebody’s login. One person asks it to prepare a brief and pastes the answer into a team channel. Everyone else sees the answer, but not necessarily the sources it used or the permissions under which it worked. If the person leaves, the arrangement may leave with them.
Google’s proposed coworker agent works under a separate identity rather than impersonating the person who asked for help. The announcement says its access follows what a team shares with that agent and which spaces it belongs to. Google also describes agents with persistent roles, memory, and their own storage. Those are product claims about the design, not proof that every deployment will get the boundaries right.
The distinction matters because the old shortcut, “just let it use my account,” hides who acted. A separate identity at least gives a team a way to decide what the agent can read, which channel it can join, and what should be attributed to it. It also makes a mistake easier to investigate than an action buried under a manager’s name. Whether a particular organization can do all of that depends on its configuration and controls; the launch announcement does not substitute for a test in your own environment.
Give it a job small enough to inspect
Imagine an events team that runs a monthly customer briefing. The coordinator spends part of each cycle chasing agenda changes, collecting speaker materials, and assembling a readiness note. A coworker agent could gather updates from the shared planning space, draft the note, and flag missing items for the coordinator. Google gives a similar example: a marketing manager asks an events agent in Chat to draft a launch-readiness document, and the agent posts it back to the group.
That is a better first assignment than “manage events.” The team can state the input, output, and handoff. It can decide that the agent may draft and flag but may not email speakers, change invitations, or publish the note without a person’s review. These boundaries are not defaults guaranteed by Google.
For the first month, I would track two things. How much coordinator time did the preparation take before and after? And how often did someone have to correct a wrong assumption, missing speaker, or outdated agenda? A faster draft that sends people chasing the wrong version is not a gain. Keep the corrections attached to the shared planning record so the next briefing starts with what the team learned, not just the agent’s memory.
Google reports that Orange Spain has deployed more than 1,000 custom Gemini Enterprise agents across functions including HR, IT, sales, and customer service. That is a vendor-reported deployment count, not evidence that your team should create a thousand of them. It shows why the question moves beyond one enthusiastic employee’s experiment: at scale, somebody has to own the roster.
A directory entry needs an owner
When a person joins a team, there is usually a manager, an account, a set of permissions, and an exit process. A coworker agent needs a comparable operational answer, without pretending it is a person. Who requested this role? Who can change its instructions? Which files can it read? Which actions can it take without a check? Who notices when it gets something wrong? And who removes access when the job ends?
A good owner is not someone who approves every draft. The owner defines the work, reviews exceptions, and makes sure the permissions still fit the assignment. In the events example, that could be the coordinator who already owns briefing readiness. IT should be able to inspect and revoke the account; the business owner should be able to say whether its output helped. Neither can cover for the other.
There is a quieter risk here. If an agent retains context across days, it may remember useful corrections, but it may also carry forward an obsolete assumption. Google’s announcement describes persistent memory and work that can continue after you close your laptop. Ask your vendor to demonstrate how a team sees the source of an agent’s claim, corrects a stale instruction, pauses an ongoing task, and removes the agent’s access. A persistent collaborator without a reliable off switch is a liability dressed as continuity.
The announcement does not establish that this coworker setup is enabled in every customer’s plan today. Ask for a demonstration in your tenant and confirm permissions before redesigning a workflow around it.
The agentic organization is not a directory full of synthetic names. It is a team that can assign work across humans and agents without losing track of access, decisions, and responsibility. Give one agent one real job. Let the people who depend on the result inspect and correct it. Its place on the team is earned in that handoff, not granted by the email address.
Research and structure: Mai. Editorial direction and voice: John Lipe.