When the Assistant Runs the Office: Gemini, Agents, and the New Workflow Layer

In the second week of October, Google Cloud introduced something it described as an agent for work. The pitch is not a smarter chatbot. It is a system that coordinates tasks across Gmail, Drive, Docs, Sheets, Calendar and connected business applications, using specialized skills and persistent context to finish multi-step jobs rather than only answering questions.

The detail that got less attention is the one that matters most. The agent can orchestrate across Google's own models and Anthropic's Claude models. Google, in other words, is selling itself as the layer that decides which model does which job, including models it does not own.

What an agent actually does in an office

A useful agent is not a search box with a nicer voice. It reads a thread, finds the attachment, updates the right tab, drafts a reply in the right tone, and books the room. Each step is small. The value comes from doing them in order, without a person copying content between four windows.

That is why the enterprise assistants are converging on the same shape. Google's agent coordinates across its productivity suite. Microsoft has been pushing Copilot into the same seat. OpenAI has been building agents with their own desktop and browser environments, and Anthropic has been selling agents that focus on coding and computer use. The competition is no longer about which model writes the best paragraph. It is about which system can be trusted to complete a workflow.

Why the orchestration layer matters

For years the assumption was that whoever had the best model would win the enterprise. That assumption is weakening. Model capability has converged enough that procurement teams stop caring which frontier model is a few points ahead, and start caring about which vendor can wire an agent into the systems where work already lives.

If that is right, the durable position is the orchestration layer, the piece that breaks a request into steps, routes each step to a suitable model, and assembles the result. Owning the productivity suite is a large advantage here, because the agent already has the context and the permissions to act. Owning that layer is also why Google is comfortable routing some work to Claude. If the layer is the product, the models underneath become interchangeable inputs.

The governance problem that arrives with the convenience

An agent that can read email, edit documents and schedule meetings needs a permission model far more complicated than the access control most IT departments run today. That is the honest cost of the feature, and it is where deployments stall.

Microsoft has taken a different approach to the same risk. It has been pushing AI agents onto the PC itself, with execution containers designed to limit what an agent can reach on a machine. Running the agent locally trades some convenience for a tighter boundary around what it touches. Google's approach leans on the cloud and the suite, where the data already sits. Both are attempts to answer the question enterprise buyers now ask before anything else: what exactly can this thing get into.

Regulators are circling the same gap. On October 8, the UK's Information Commissioner's Office reported commitments from ten AI developers to make data-protection improvements and opened a call for evidence on the risks of agentic AI. The framing is telling. When software takes actions on a user's behalf, the questions about consent, logging and liability stop being a single company's problem.

The permission problem in practice

Picture the access list an agent needs to do its job. Reading a thread needs mail access. Finding the attachment needs file access. Updating a sheet needs edit rights on that document. Booking a room needs calendar write access. Each permission is reasonable on its own. Together they describe an entity that can see most of what a person can see and change much of it, and traditional access control was never designed for something that acts on its own at machine speed.

That is why the guidance arriving from standards bodies is shaped the way it is. Treating agents as low-trust, non-human identities sounds bureaucratic until you try to write the audit log. An agent that ran a hundred actions overnight needs a record of what it touched, a way to revoke its credentials quickly, and a rule for which actions require a person to sign off. Most organizations have none of those three things in place, even the ones already running agents in production.

The uncomfortable reality is that convenience and control pull in opposite directions here. The more systems an agent can reach, the more useful it becomes and the more damage a mistake can do. There is no clever setting that resolves that trade. There is only a decision about how much access a given workflow actually warrants, made before the agent is let loose rather than after.

What orchestration buys, and what it costs

The upside of an orchestration layer is real. Routing each step to the right model means a routine step can run cheap and a judgment call can run on the strongest model available. It also means a single interface over tools that used to be separate, which is the part that saves a person's afternoon.

The cost is a new kind of vendor dependence. If the layer that decides how work flows sits with one provider, then that provider decides which models get used and at what price. Google routing some work to Claude is a nice story about choice. It is also Google deciding when that choice applies. The same structure that makes the system flexible for the buyer makes the buyer dependent on whoever holds the routing rules.

That is worth remembering when a suite vendor pitches an agent that only fully works inside its own products and a few partners. Interoperability is easy to promise and hard to verify, and it is the thing to test first.

What teams should actually do

The teams getting value out of these agents are not the ones that turned them on everywhere. They are the ones that picked a narrow, repetitive workflow, gave the agent the minimum access it needed, and logged every action for review. Start where the failure is cheap. Drafting a summary is low risk. Paying a vendor is not.

Three habits are worth adopting early. Keep a live inventory of which agents exist and what each one can touch, because the number grows faster than anyone expects. Use short-lived credentials so a leaked or misused agent cannot act forever. And put a human approval step in front of any action that moves money, changes a contract or contacts someone outside the company.

None of that is glamorous. It is also the difference between an agent that helps for a year and one that makes a headline for a day.

The shape of the next phase

The frontier race has moved from releasing the most capable model to shipping systems that survive security, cost and regulatory review. Google is betting that workflow integration is where advantage lives. Microsoft is betting on local execution. OpenAI is betting on verifiable reasoning. Anthropic is betting on safety-critical deployment.

Whichever bet pays off, the buyer's question has changed. It is no longer "how smart is your model." It is "can I see what it did, limit what it can do, and afford to run it every day." That is a duller question, and it is the one that decides which assistants are still installed next year.