An AI connection notice should not automatically become a project to rebuild every mail integration. A business can use an AI assistant and still have ordinary programmes calling Workspace REST APIs. The first migration question is which connection actually calls a Workspace MCP server, and whether it shares an OAuth client with non-agent features.
Google's October 12 developer announcement requires OAuth clients calling its Workspace MCP servers to be marked for use by an AI-powered agent. It explicitly distinguishes non-agent integrations that only call Workspace REST APIs. The related MCP services are in developer preview, so an integration owner should first establish whether the business uses them at all.
For an overseas operations team working with developers or a supplier team in China, this is a scope decision. Product names such as Gmail or Docs are not enough to identify the affected connection. The same application can expose several features backed by different interfaces, and a familiar interface can conceal a newer connection underneath.
Inventory the calls, not just the applications
Ask the integration owner to identify the actual interface and client used by each AI feature. Distinguish it from ordinary mail collection, notifications or document processing. A list saying only “Gmail automation” cannot establish whether that function depends on the MCP service covered by the notice.
Where an existing client serves both agent and non-agent features, Google's stated approach is to create a separate client for the agent, mark only that client as agentic and retain the existing client for the ordinary features. The purpose is to separate uses, not to enlarge the application's access.
This can be checked without moving secrets into a group chat. The team needs a clear mapping between a client and its purpose, plus an accountable person who can make the relevant configuration change. Credentials should remain in their controlled storage. A migration handover is not a reason to circulate them more widely.
Test the two paths separately after the necessary application update. An agent successfully reading permitted data does not establish that the old mail process still works. Conversely, a normal mail job running successfully does not show that the agent connection meets the new client requirement. Each result answers only the connection question it exercised.
Use a limited, appropriate test within existing permissions. Do not add mailbox access merely to make the migration test easier. If an integration is managed by an external provider, obtain an explanation of the affected interface and client arrangement rather than assuming that every customer should recreate its own configuration.
Keep the two announced dates distinct
The notice says Workspace MCP servers will begin rejecting requests from unmarked clients on November 11. It separately says clients still unmarked by November 12 will remain non-agentic, requiring a new agentic client for later MCP use. Those are distinct statements in the announcement; do not turn them into an assumed extra day in which existing calls are guaranteed to work.
An operation with a real MCP dependency should plan the necessary classification, separation and application update before the change takes effect. An operation using only ordinary REST integrations can record why this specific change does not affect them. It does not need to manufacture a migration simply because the company also uses AI elsewhere.
Client classification is also different from the permission to perform a business action. Marking a client for an agent does not determine which messages it may read or which documents it may modify. Existing account consent, access restrictions and platform procedures still matter. Our article on time-bounded AI email access addresses when granted access should end; a client migration is not a reason to extend it.
A useful handover names the agent features moving to the new client, the ordinary features staying on the existing client and what was tested on each path. That is more actionable for the next support shift than a general statement that the Google connection was upgraded. It also narrows fault-finding if only one path later has a problem.
Leave the handover with named features beside their clients and a test result for each path. With no MCP use, retain the basis for leaving the ordinary integration alone. With mixed use, the notice directs separation of the agent client, not replacement of unrelated mail processes or broader powers for the assistant.
Sources
- Google Workspace developer release notes, October 12, 2026 notices for Workspace MCP OAuth clients; includes the November 11 and 12 schedule and mixed-use client guidance.

