Vertex AI Extensions Shut Down November 26: Three Migration Paths for Agent Platform

Google quietly deprecated Vertex AI Extensions on May 26, 2026, and set a hard shutdown date of November 26, 2026 — exactly six months out. For engineering teams that built agent workflows on top of Code Interpreter, Google Search, or Custom Extensions, this is a forced architecture migration with a real deadline. Here is what changes, why it matters, and how to approach the migration.

What happened

Vertex AI Extensions was a managed runtime layer that let Gemini models invoke pre-built or custom tool servers as part of a generation request. The three primary extension types were:

• Code Interpreter — a managed sandbox for executing AI-generated code mid-conversation
• Google Search — grounded search retrieval injected into model context
• Custom Extensions — user-defined OpenAPI-spec tools registered with Vertex

Google has now migrated these capabilities into the Gemini Enterprise Agent Platform (formerly Reasoning Engine / Agent Engine), its next-generation managed agent runtime. The Extensions API will stop accepting requests after November 26, 2026. There is no grace period after that date.

Why it matters for AI engineering teams

Vertex AI Extensions was often the glue layer in enterprise Gemini deployments. Teams that used it for:

1. Code execution in data science or finance workflows — replacing the Code Interpreter extension is a multi-step SDK change, not a config toggle.
2. RAG pipelines with Google Search grounding — the search extension is being replaced by native Gemini grounding and the GoogleSearch tool in the Agent Platform SDK.
3. OpenAPI-spec custom tools — Custom Extensions require a migration to Agent Platform's FunctionTool or MCPTool pattern, including re-registering schema definitions and updating invocation logic.

The extension-based approach put orchestration logic in Vertex's managed layer. Agent Platform shifts control toward the Agent Development Kit (ADK), which means more code to write but also more portability.

The three migration paths

Code Interpreter → Agent Platform Code Execution Sandbox

The direct replacement is AgentEngineSandboxCodeExecutor in the ADK or the code_execution tool in the google-genai SDK. Both run isolated, stateful sandboxes. The main difference from the operator perspective: sandbox resource names must now be provisioned separately and passed at runtime. Teams running many parallel sessions should evaluate sandbox pooling and session lifetime management.

Google Search extension → Native Gemini Grounding

The GoogleSearch tool is now a first-class parameter in Gemini generation requests. For teams that routed through the Extensions API to get web-grounded answers, switching to tools=[types.GoogleSearch()] in the SDK removes the extra network hop and extension registration overhead. For teams using Vertex AI Search (enterprise corpus), the equivalent is VertexAISearch.

Custom Extensions → Agent Platform Function / MCP Tools

Custom Extensions were defined as OpenAPI specs registered in the Vertex console. The Agent Platform equivalent is FunctionTool (inline Python functions), OpenAPITool (external OpenAPI specs), or MCPTool (Model Context Protocol servers). The MCPTool path is the most portable — if you already expose tools via MCP, the migration is largely a registry update. Custom extensions with complex request/response schemas will need schema mapping work.

The routing and cost angle

If your team routes to Google through TheRouter's OpenAI-compatible gateway, the deprecation itself does not change the routing configuration — model IDs and endpoint behavior are not affected. What changes is the tool-calling architecture upstream of the routing layer.

The migration is also a good time to evaluate whether your agent's tool invocations should live inside the Vertex managed runtime at all. The ADK is designed for Vertex-native deployments, but teams that need provider portability — running the same agent against Anthropic, OpenAI, or DeepSeek — may prefer a provider-agnostic tool-calling layer.

Key decision: ADK vs. provider-agnostic orchestration

What to do before November 26

1. Audit your Extensions usage — list all registered extensions in the Vertex AI console and map them to the three categories. Custom Extensions with complex auth flows take the longest.
2. Test Code Interpreter replacements — the ADK sandbox executor and the code_execution tool have different session semantics. Validate statefulness requirements for your workload.
3. Migrate Search extensions first — lowest effort; GoogleSearch tool is a one-line SDK change for most workloads.
4. Validate Custom Extension schema mappings — OpenAPI → FunctionTool translations can fail silently on schema edge cases (nullable unions, allOf/anyOf patterns). Test with representative inputs.
5. Update your observability hooks — Extensions produced its own audit trail in Vertex logs. Agent Platform logging is different; update your monitoring queries.

The November 26 deadline gives teams roughly five months. That sounds comfortable until you factor in staging, load testing, and the typical slowdown of Q3 engineering cycles. Starting the audit now is the right move.

Reference

• Vertex AI Extensions deprecation announcement
• Migration guide: Extensions → Agent Platform