Migrate Gemini Deep Research before 23 October

Google's 8 October 2026 API changelog schedules deep-research-pro-preview-12-2025 for shutdown on 23 October 2026. Its replacements are deep-research-preview-04-2026 and deep-research-max-preview-04-2026. The migration changes the request's agent parameter, rather than a model parameter.

Treat this as a scheduled integration change with an owner and a cutover date. Search application configuration, scheduled jobs, examples copied into internal tools and any worker code that constructs its own requests. An updated main service does not cover a monthly job with a separate configuration.

Choose a replacement against the actual research task

Google's Deep Research guide positions the standard replacement around speed and efficiency and the Max replacement around research completeness. Both identifiers remain previews. Those descriptions provide a starting point for comparison, not an acceptance result for your reports.

Select a small set of representative research briefs. Include a narrow factual comparison, a question with conflicting sources and a topic where the correct result should acknowledge limited evidence. Keep the brief, source constraints and required output consistent between runs.

Write the acceptance criteria before reviewing the new results. They might include verified citations, coverage of specified questions, clear dates and explicit uncertainty. Have the intended report owner judge whether each output is usable with the normal review effort.

Record total elapsed time and cost alongside those judgements. A faster report that leaves the reviewer to reconstruct the missing comparison may not improve the business process. Equally, a longer report can create unnecessary reading when a short factual brief is the task.

Preserve a durable job record

Deep Research is an asynchronous workflow. The guide requires background execution with stored interactions. Keep the returned interaction identifier in the application's job record so a worker restart does not lose the connection between a business request and its research task.

The Interactions overview describes an interaction as a record of the conversation's steps, with optional server-side state carried through previous_interaction_id. Decide deliberately when a task is a continuation and when it is a new request.

For the migration, retain the original business job identifier, selected agent, input revision, creation time and eventual outcome. Record what the application does after a timeout, a worker restart or a terminal failure. An ambiguous local timeout should trigger investigation of the existing interaction before creating a duplicate research job.

Keep the polling and notification paths under the same review as creation. A deployment can successfully submit new work while an older worker still assumes a different result shape or loses unfinished jobs during shutdown.

Validate the report outside the agent

Google documents that structured output is not supported for Deep Research. If downstream software needs a fixed schema, provide a separate parsing and validation stage with an explicit failure route. Do not assume that asking for a particular layout turns a research report into a guaranteed data contract.

Check each critical citation against the source it claims to support. Verify the date and the relevant passage, especially when the brief concerns a current product, price or policy. The research source-control note provides a useful review pattern even though its product examples concern ChatGPT.

Keep research generation separate from consequential action. A completed supplier report can enter a review queue without automatically changing an approved supplier record or sending a message. This keeps migration failures contained within a reviewable output.

If the new report is incomplete, retain the original brief and identify the missing requirement. Decide whether to continue the existing research, create a new task or hand the work to a person. Avoid repeatedly starting the same broad request without learning why the earlier output failed acceptance.

Cut over with an observable queue

Route a limited set of suitable new jobs to the selected replacement and compare their outcomes with the acceptance set. Make the selected agent visible in operational records so support staff can identify which path produced a report.

Before the shutdown date, account for jobs still associated with the retiring agent. Decide how to finish, replace or close them, and tell the responsible internal owner which reports remain outstanding. Keep a manual research route available for work that cannot wait through an integration fault.

After 23 October, a rollback plan cannot rely on continued access to the retired agent. Retain the previous application release for diagnosis, but make the operational fallback an available replacement or a documented manual process. Remove the old identifier from active configuration once the migration record confirms the cutover.

References

• Google, Gemini API changelog, 8 October 2026. Accessed 17 October 2026.
• Google, Deep Research. Accessed 17 October 2026.
• Google, Interactions API overview. Accessed 17 October 2026.