Google changed the model behind "stable" in Agent Search. If you never chose one, your answers changed too
On October 16, Agent Search's stable answer-generation model moved from Gemini 2.5 Flash to Gemini 3.5 Flash. Stable is also the default. Why a moving alias belongs on the change calendar.
Listen to this article · 4 min
AI-generated narration of the full article.

If your company’s search application on Google Cloud Agent Search generates answers and nobody ever set the model version, its model changed on October 16.
That day, Google updated the stable answer-generation model from gemini-2.5-flash/answer_gen/v1 to gemini-3.5-flash/answer_gen/v1. Gemini 3.5 Flash had been available for answer generation since August 13 for anyone who chose it explicitly. What changed is the alias. And according to Google’s documentation, stable is what an application gets when it does not specify a version at all. The same page says the model behind stable “changes periodically as new models and versions become available.”
This is a narrow change: Agent Search answer generation, not the Gemini API in general, and the release note sets no retirement date for the old model. It is still the kind of change that slips past every control most enterprises have, because nothing in your code, prompts or configuration moved.
Same week, same pattern
A day later, DeepSeek’s alias deepseek-flash started serving its updated model as well. Two providers, two aliases, one week. Moving aliases are a convenience: applications get better models without a deployment. They also mean the provider decides when your application’s behavior changes.
For enterprise search the stakes are specific. Answer generation turns retrieved documents into a response an employee or customer reads as the company’s answer. A new model can cite differently, summarize more or less aggressively, answer where the old one declined for lack of grounding, or decline where it used to answer. Each of those is a behavior change in a system that may sit in front of HR policy, product documentation or regulated content.
What to check this week
Find the applications on the alias. Search your code and configuration for answer requests that pass stable or pass no model version. Those changed on October 16. Those with an explicit version did not.
Run the regression set you would run for a release. For grounded answers, the useful checks are citation accuracy (does each claim point to a passage that supports it), behavior when retrieval finds nothing, answer length, latency and cost per query. If you kept answers from before October 16, compare them on the same questions. If you did not, start keeping them now.
Decide alias or pin, per application. An internal assistant answering questions about the cafeteria menu can ride stable. An application answering customers about contract terms or patients about medication should pin an explicit version and move deliberately, with a test run and an approver, as we argued when model retirements turned into change calendars. Pinning has its own duty: explicit versions retire too, and the documentation ties Agent Search models to the lifecycle of their base models. Pinning moves the date of the change into your hands; it does not remove the change.
Record the model with the answer. If an answer is ever disputed, you will want to know which model produced it. Log the resolved model version alongside the query, the retrieved sources and the response.
The broader rule
A model dependency that resolves at request time is a dependency you do not control. Every enterprise AI inventory should record, for each application, not only which provider and model it uses, but whether it calls a fixed version or an alias, and who is told when the alias moves. Most of the time the answer to the second question today is nobody.