Gemini can now act inside Microsoft 365. Does your collaboration suite still pick your agent platform?

For years, the enterprise AI platform decision had a shortcut: if you run on Microsoft 365, you use Copilot; if you run on Google Workspace, you use Gemini. The collaboration suite chose the assistant.

That shortcut is getting weaker. On September 18, Google added preview actions to Gemini Enterprise that let its agents act, not just read, inside Microsoft’s core services.

What changed

According to Google’s release notes, the following actions are available in public preview:

• OneDrive: copy folders, move and rename files and folders, share files or folders, update file properties.
• Outlook: create and update calendars, RSVP to events.
• SharePoint: create, read and update list items, list lists and fields, share resources, update file properties and pages, discard document check-outs.
• Teams: create channels and chats, add channel members, update channels, chats and messages, create schedules and manage time-off entries.

The same month’s notes include two governance changes worth reading alongside them. On September 21, Google let administrators transfer ownership of shared agents, including to users in a Workforce Identity Federation pool, and disable any schedules or event triggers on transfer until the new owner re-enables them. On September 28, it added resource-level IAM so specific apps and data stores can be restricted without granting access to the whole Google Cloud project.

1. User in Microsoft Entra
2. Gemini Enterprise agent
3. Connector and identity mapping
4. Microsoft 365 permission
5. Action in SharePoint, Teams or Outlook

• Google Cloud: Gemini Enterprise agent · Connector and identity mapping
• Microsoft 365: Microsoft 365 permission · Action in SharePoint, Teams or Outlook

Agent platformCollaboration suite

What cross-vendor agents really cost

An agent built on one vendor that acts inside another vendor’s suite is technically possible now. Operationally, it multiplies the work in exactly the places that decide whether security signs off:

Two identity systems. Your users live in Microsoft Entra. The agent platform has its own identity and IAM model. Someone has to map who the agent acts as in Microsoft 365, and keep that mapping correct as people join, move and leave.

Permission translation. When a Gemini agent updates a SharePoint list, the question is not whether it can, but under which permissions, and whether those match what the requesting user could do directly.

Two audit trails. Actions are initiated in one platform and executed in another. An investigation needs both sides, correlated.

Two governance models. Agent inventories, ownership, approval rules and admin roles now exist on both sides, with different names for similar controls.

Data movement. Content read from Microsoft 365 is processed by a different provider, which is a data-flow decision your privacy and security teams need to approve explicitly.

When a cross-vendor setup makes sense

There are good reasons to accept that overhead:

• Your data and AI workloads already live in Google Cloud while collaboration runs on Microsoft 365, and agents need to sit close to the data.
• You are deliberately avoiding a single-vendor AI stack, and have the governance capacity to run two.
• A specific agent capability exists on one platform and not the other, and the use case justifies it.

It makes less sense when the only argument is feature parity, or when nobody owns the identity mapping and cross-platform audit.

A better question than “which suite?”

The collaboration suite is becoming one integration target among several. The platform decision should follow three other questions:

1. Where does the data and process live that the agent needs to act on?
2. Where can you enforce identity, permissions and audit most consistently for that use case?
3. Who will operate it, and can they run another governance model well?

Neither vendor “wins” by default. What changes is that the decision is now yours to make deliberately. It is also a practical example of being platform-native without being platform-only, which we explore in our 2026 stack guide.

What to do now

• Treat the new actions as preview. Test in a non-production Microsoft 365 environment with test accounts.
• Map the identity path end to end before enabling any write action: user, agent, connector, Microsoft 365 permission.
• Decide where the combined audit trail lives, and test it with a mock investigation.
• Check model routing settings. Google’s notes show some models are available in global, US and EU locations, and that routing to the global endpoint from unsupported locations requires an admin to accept a warning. Make that an explicit decision, not a click.