6 min read Model Strategy

Gemini 3.5 Pro's delay: why your roadmap should never depend on a single model

Gemini 3.5 Pro's delay: why your roadmap should never depend on a single model

On 21 July 2026, Google DeepMind released three new Gemini models: 3.6 Flash, 3.5 Flash-Lite, and a Flash Cyber variant specialised in finding vulnerabilities. None of them was Gemini 3.5 Pro. The flagship model, unveiled in May with general availability promised for the following month, remains unavailable, and the Pro line has not been updated since February. Five days earlier, Bloomberg reported that the launch had been held back because the model was falling short of Google's internal performance targets, particularly on coding tasks.

The instinct here is to read the sequence as a verdict on the model race: Google is slipping, OpenAI and Anthropic are pulling ahead. That was the dominant framing in the financial coverage, and it is the least useful one for a technical team. The delay says little about who wins the race. It says a great deal about the fact that a vendor with near-unlimited resources can miss an availability date by months, without notice and without any commitment to a replacement. The question is not whether you picked the right model. It is what changing models would cost you.

That question extends the one raised in the article on the harness rather than the model: if most of an agent's behaviour comes from its configuration rather than the underlying model, a well-built architecture should absorb a vendor change without a rewrite. The Gemini 3.5 Pro delay is a chance to check whether that holds in your case.

Roadmap platform resting on three pillars, one of them incomplete and dashed
A product roadmap anchored to a model that has not shipped hands a scheduling decision to a vendor who never signed for it.

Timeline of a six-month slip

Google introduced Gemini 3.5 Pro in May alongside the 3.5 Flash launch, saying the Pro version was already in internal use and would roll out the following month. June came and went. On 16 July, Bloomberg reported, based on accounts from current and former employees, that the release was blocked by coding results below internal targets, and that a training data update in late June had made performance worse rather than better. Alphabet closed that day down 4.4%, erasing roughly $200 billion in market capitalisation.

It was not the quarter's first shock. On 22 June the stock had already fallen more than 5%, close to $225 billion, after five senior DeepMind researchers left for rival labs in a single week. Among them were John Jumper, 2024 Nobel laureate in chemistry for AlphaFold, who joined Anthropic, and Noam Shazeer, Gemini co-lead and co-author of the founding Transformer paper, who joined OpenAI.

Competitors shipped during the same window. OpenAI released GPT-5.5 and began rolling out GPT-5.6 on 9 July. Anthropic launched Claude Opus 4.8 in late May, Claude Sonnet 5 on 30 June, and widened access to Fable 5 in June. On 21 July, Google DeepMind product lead Logan Kilpatrick said Gemini 3.5 Pro was in partner testing and that the team hoped to land it soon, while announcing the start of the most ambitious pre-training run yet for Gemini 4.

One detail is worth noting, because it cuts against the catastrophist reading: over the same period Google Cloud revenue grew 63% year over year to $20 billion, and the segment's operating income roughly tripled. A delay on a flagship model is not an industrial collapse. It is an execution setback, which is exactly what makes it instructive: execution setbacks happen to everyone, including the strongest vendors.

What a vendor delay actually costs

The common mistake is treating an announced launch date as a roadmap commitment. Nothing in a model pre-announcement is contractual, not the date, not the promised performance, not even the guarantee that the model ships in the form presented. Teams that scheduled a Q3 product feature assuming Gemini 3.5 Pro would be available in June handed a scheduling decision to a third party who never signed for it.

The real cost shows up at the moment of switching. In mature deployments, teams that isolated their model layer behind a stable interface can reroute part of their traffic to another vendor within days, with a quality delta they have already measured. Teams that hard-coded vendor specifics find that changing models is a multi-week project: a different tool-calling format, a system prompt structure to rewrite, incompatible cache behaviour, an evaluation suite to rebuild because it only ever existed for one model.

This asymmetry rarely tracks team size or budget. It tracks an architecture decision made early, often implicitly, when someone wired a vendor SDK straight into business logic instead of putting it behind an abstraction. The Gemini delay did not create that risk. It made it visible.

Grid of four criteria for measuring dependency on a single model vendor
Four criteria for assessing how dependent your architecture really is on a single model vendor.

Four criteria for measuring your dependency

The first is switching time. How long does it take your team to reroute 10% of production traffic to another vendor's model without functional degradation. If nobody knows, the drill has never been run, and an optimistic estimate is worth nothing until it has been tested under real conditions.

The second is evaluation coverage. Do your evals run against at least two vendors, with comparable and historised results. An evaluation harness that exists for one model does not measure the quality of your system. It measures that model's quality on your use case, which is a different thing and does not transfer.

The third is roadmap exposure. How many features committed to the business or the board depend on a model that is not yet generally available. The sensible rule is to commit publicly only to what rests on capabilities already accessible, and to treat announced models as potential accelerators rather than prerequisites.

The fourth is a switching threshold defined in advance. At what level of latency, cost, or quality degradation do you trigger a vendor change, and who owns that call. Without a written threshold, switching gets decided under pressure, at the worst possible moment, on the argument of whoever is most insistent in the room.

What to set in motion this week

Run a switching drill on a non-critical production service: reroute a fraction of traffic to an alternative vendor's model and time the gap between the decision and traffic actually being served. That number is your real dependency metric, not the architecture described in your documentation.

Review the commitments made to the business for the next two quarters and isolate those that assume a model that has not shipped. Reclassify them as assumptions rather than commitments, and tell stakeholders before the date becomes their problem.

Extend your evaluation suite to a second vendor, even partially, across the ten cases most representative of your usage. The goal is not to rank models but to have a comparison baseline on the day you need to decide quickly.

Write down the switching thresholds and the name of the person who triggers the decision. A one-page document is enough, provided it exists before the incident rather than after.

Conclusion

The Gemini 3.5 Pro delay will resolve, and Google will most likely ship a competitive model. What remains is the demonstration that no vendor, whatever its market capitalisation, guarantees an availability date. Teams that designed their architecture to make substitution cheap will treat this episode as market information. Teams that anchored a roadmap to a model that had not shipped will treat it as a crisis, and spend the quarter rebuilding what should have been abstracted from the start.

Sources: As of July 2026

Godwin AVODAGBE