Google’s Antigravity Teamwork framework is built for long-running research and engineering jobs, with groups of AI agents proposing, challenging, verifying, and refining each other’s work over hours or days. Google reports seven notable open-problem results from its Long Proof work, while a Gemini 3.7 Flash team separately built a cycle-level out-of-order RISC-V CPU simulator that booted xv6 to a shell and matched hardware timing within 0.71% on average.

Google let the agents keep working — and the jobs got ambitious

Google has been testing Gemini models in teams of autonomous agents, and the latest results are far beyond the usual “build me an app” demo.

With Antigravity Teamwork, groups of agents can work for hours or days on the same objective. They propose approaches, challenge one another’s results, verify intermediate work, and keep iterating until they have something ready for human review.

Google says that setup has now produced seven notable results across open problems in mathematics and theoretical computer science. In a separate systems-engineering test, a Teamwork configuration powered by Gemini 3.7 Flash built a cycle-level out-of-order RISC-V CPU simulator from scratch, booted xv6 to a working shell, and ran more than 100 standard RISC-V benchmarks.

That combination is what makes this update worth watching. Teamwork is being used on proofs, processor simulation, and real open-source performance work — three very different jobs, all built around the same idea: give several agents a shared objective and enough structure to keep improving the result.

Teamwork is more structured than “put several agents on it”

Google first introduced Teamwork as a multi-agent orchestration framework inside Antigravity. The current version is available through the `/teamwork-preview` command, and it does not use one fixed team for every problem.

Instead, Teamwork works with patterns. A pattern defines the roles the agents should play, how their work should move between them, and what has to be checked before the job can advance. Antigravity chooses a pattern based on the task and can change the number of agents while the run is underway.

The current set includes Iterative Coding, Distributed Coding, Long Proof, Self-Verification, and Document Review. A software project that splits cleanly into parallel work can use a different structure from a mathematical proof that needs repeated strategy search and verification.

That separation is important. The useful part is not simply having more model instances running at once. It is giving them a workflow that says who proposes, who checks, who combines, and when another round is worth running.

The seven research results come with an important model detail

The Long Proof pattern is where Google reports the seven notable open-problem results. It generates several candidate strategies, pairs them with agents that try to break or verify them, and then combines the strongest surviving ideas into a more complete approach.

The results span coreset construction for ℓp subspace approximation, sparse convex optimization, maximal inner-product embeddings, Hadamard quantization, the Erdős unit-distance problem, prefix-matrix factorizations, and Knuth’s Cycles Conjecture. Five resulting papers are available on arXiv.

There is one detail worth getting exactly right: Google says the seven results were obtained using Gemini 3.1 Pro. Three of them — problems 1, 3, and 4 in Google’s list — were also reproduced with Gemini 3.7 Flash. So this is not a claim that Flash alone produced all seven results.

For Knuth’s Cycles Conjecture, Google reports first proofs for two simpler constructions of the even-integer case, with proofs running beyond 40 and 70 pages. The shorter proof was formally verified in Lean. For the broader set, Google says human experts reviewed and confirmed the results, with Lean providing the formal verification path for the Knuth work.

Then Gemini 3.7 Flash built a CPU simulator

The hardware result is easier to picture.

Using Gemini 3.7 Flash, Teamwork built a highly accurate cycle-level simulator for an out-of-order RISC-V processor. It was not just executing RISC-V instructions functionally. The goal was to model the timing behavior of a modern out-of-order design closely enough to compare cycle counts against hardware ground truth.

The agents worked through two phases. First came functional correctness: building execution logic for pieces such as reorder buffers, caches, and the out-of-order pipeline, then getting the simulator to maintain correct architectural state and boot xv6. The second phase focused on timing, aligning the simulator’s behavior against strict reference measurements.

Google says the finished simulator booted xv6 all the way to a shell and successfully simulated more than 100 standard RISC-V benchmarks. On unseen test workloads, it reached an average cycle-alignment error of 0.71% against BOOM hardware execution ground truth.

That is a much richer engineering target than generating source code that compiles. The team had to build the simulator, run microbenchmarks, inspect traces, compare timing, and keep refining the microarchitecture until the behavior lined up with the reference.

The same framework also shipped real open-source optimizations

Google also pointed Teamwork at existing open-source software.

For Eigen, the widely used C++ linear-algebra library, the agents worked through microbenchmarks and identified an opportunity around matrix-vector operations where the matrix has a single row or column. The resulting implementation added a dedicated fast path using direct data access, SIMD operations, and four-way accumulator unrolling. Google says the change went through the normal open-source review process and landed upstream with assistance from Gemini 3.6 Flash.

A second project focused on ParlayHash, a high-performance concurrent hash table. Teamwork contributed to the design of “Swiss Parlay,” which brought ideas from Swiss Table into the library.

Google reports 2× throughput on initial inserts with 64 threads, 1.5× overall throughput with a single thread, and memory use per element that was 25% lower than the comparison sequential table while staying close to its performance. The improvement also landed upstream.

These examples give Teamwork a different kind of credibility from a closed benchmark. The work ended up inside existing projects after external maintainers reviewed it through their normal process.

The interesting part is the loop, not the agent count

Multi-agent systems are easy to describe as “several AIs working together,” but Teamwork’s design is more specific than that.

For Long Proof, candidate strategies compete before the system commits deeply to one route. Subproblems can be split into a dependency graph and solved in parallel where possible. Verification is built into the process, and later rounds can reuse useful results and observations from earlier work.

The coding patterns use a different rhythm. Distributed Coding can fan a decomposable engineering job across parallel workers and bring in critic review. Iterative Coding keeps a tighter agent-test-refine loop for work that needs repeated local improvement.

The result is a framework that changes shape around the problem. Mathematics, processor simulation, and library optimization do not need the same team structure, even if all three benefit from longer-running collaboration.

This is already moving into the Antigravity developer workflow

Teamwork is not only a Google research harness. The updated framework is being rolled into Antigravity through `/teamwork-preview` on paid plans, with Google saying more of the improvements will arrive over the next few weeks.

Gemini 3.7 Flash is a natural fit for that environment because Google is positioning it specifically around coding and agents. The model launched in August as Google’s latest Flash workhorse for software engineering, knowledge work, web development, and multi-step agent workflows.

That gives the research results a direct connection to a product developers can actually experiment with. The exact high-parallelism configurations behind some of Google’s research runs are not simply the default consumer setup, but the orchestration ideas are becoming part of the same Antigravity environment.

The broader direction is clear: the unit of work is getting larger. Instead of asking one model for one answer, developers can hand a structured team a problem and let the system keep working through planning, implementation, testing, critique, and verification.

The Upgrade Feeling

The strongest part of this story is not a single benchmark number.

It is the range of work produced by the same orchestration idea. One Teamwork pattern can spend hours exploring a proof. Another can build and calibrate a CPU simulator. Another can optimize production-grade C++ and send the result through an upstream review.

That makes agent orchestration feel less like a demo layer and more like an engineering primitive. The model still matters, but the structure around the model is starting to matter just as much: roles, verification, parallelism, shared state, and the ability to keep working long enough for a difficult problem to unfold.

For developers following the agent space, that is the signal here. The next jump may come from better models — but also from giving those models better ways to work together.

Google Gemini 3.8 Flash is a production-ready AI model built for long-horizon software engineering, autonomous agents and complex workflows, with a 1M-token context window and a broad set of built-in tools.

The Short Version

Google has launched Gemini 3.8 Flash, a new production-ready model built for long-horizon software engineering, autonomous agents and complex multi-step workflows. Google describes it as its most intelligent Flash model yet. It combines a 1 million-token context window with built-in tools for code execution, file search, function calling, Search grounding, Google Maps grounding, structured outputs and computer use in preview.

Flash Is Becoming an Agentic Workhorse

Gemini 3.8 Flash pushes Google’s Flash line deeper into agentic work. The model is designed for tasks that continue across many steps rather than ending after one prompt and one answer. That makes it a natural fit for coding agents, research workflows, application assistants and systems that repeatedly plan, call tools, inspect results and continue working.

Built for Long-Horizon Software Engineering

Google positions long-horizon software engineering as one of the core strengths of Gemini 3.8 Flash. The model is designed to stay engaged across larger coding jobs that involve several files, multiple tool calls and a sequence of related decisions. For developers, this points toward AI that can participate in a broader slice of the software workflow instead of focusing only on isolated code snippets.

Autonomous Agents Are a First-Class Use Case

Gemini 3.8 Flash is also engineered for autonomous agents. These systems can break a goal into steps, select tools, inspect their own progress and continue until a larger task is complete. Google is clearly treating agent orchestration as a central part of the model’s identity, which makes 3.8 Flash especially relevant for the next generation of AI-powered applications.

A 1 Million-Token Context Window

The model supports an input context window of 1,048,576 tokens. That gives developers a large working space for source code, documentation, long conversations, reports, project files and other context-heavy material. A large context window becomes particularly useful when an agent needs to keep many connected pieces of information available throughout a multi-step workflow.

Up to 65,536 Output Tokens

Gemini 3.8 Flash supports up to 65,536 output tokens. That creates room for substantial generated work such as detailed technical reports, large code changes, structured plans and long-form analysis. Combined with the 1 million-token input window, the model is set up for workflows where both the source material and the resulting output can be large.

Multimodal Inputs Are Built In

Google lists text, images, video, audio and PDFs as supported input types for Gemini 3.8 Flash. That means one agent can reason across several kinds of information without every workflow being reduced to plain text first. For applications that combine documents, screenshots, media and written instructions, this gives the model a much richer view of the task.

Code Execution Can Be Part of the Workflow

Gemini 3.8 Flash supports code execution as a built-in capability. This gives an application a way to move from reasoning about a technical task to running computations or validating generated logic inside the workflow. In agentic systems, that connection between thinking and execution can make the model more useful for data tasks, technical analysis and software development.

Computer Use Is Available in Preview

Google also lists computer use as a preview capability for Gemini 3.8 Flash. Computer use allows an AI system to interact with graphical software and interfaces as part of a larger task. Combined with planning and tool use, it points toward applications that can move through real digital workflows rather than operating only inside a chat box.

Function Calling Supports Connected Applications

Function calling is supported, giving developers a direct way to connect Gemini 3.8 Flash with application logic and external tools. An agent can decide when a function is needed, request the appropriate action and use the returned information as part of the next step. This is one of the core building blocks behind practical AI assistants that can work with live systems.

File Search Helps Agents Work Across Project Material

File search is another built-in capability. For agents working with project documents, technical references or large collections of material, file search can provide a direct retrieval layer inside the model workflow. That helps turn a large document set into active working context instead of something a user has to manually copy into prompts.

Search Grounding Connects the Model to Fresh Information

Gemini 3.8 Flash supports grounding with Google Search. For applications that need current public information, this gives the model a path to bring fresh web context into its reasoning process. Grounded search is especially useful for research agents, information assistants and applications that need to combine model reasoning with up-to-date external material.

Google Maps Grounding Opens Another Data Layer

The model also supports grounding with Google Maps. That creates interesting opportunities for applications involving places, travel, business discovery and geographic context. When combined with agentic planning, Maps grounding can become one more specialized information source that an AI system can call as it works through a real-world task.

Structured Outputs Help Applications Stay Organized

Structured outputs are supported in Gemini 3.8 Flash. This allows developers to request predictable machine-readable response formats for application workflows. Agents often need to pass results from one step to another, so structured outputs can make it easier to turn model responses into data that software can reliably process.

Thinking Levels Can Be Tuned

Google provides low, medium and high thinking levels for Gemini 3.8 Flash. This gives developers a way to shape how much reasoning effort the model applies to different classes of tasks. A lightweight interaction and a complex multi-step engineering job can therefore use different reasoning settings while staying on the same model.

URL Context Expands What an Agent Can Work With

URL context is supported as well. This gives applications another convenient way to bring external material into a task without manually reformatting everything into a prompt. For research, documentation and web-based workflows, direct URL context can help an agent move more smoothly between source material and generated work.

Caching Supports Repeated Workflows

Gemini 3.8 Flash supports caching, which is useful when an application repeatedly works with the same large body of context. Long-running agents often revisit project instructions, codebases or reference material across several steps. Caching gives developers another tool for building persistent workflows around substantial shared context.

Gemini 3.8 Flash Is Generally Available

Google lists Gemini 3.8 Flash as generally available and ready for production use. The stable model ID is gemini-3.8-flash. That production status matters for developers because Google is positioning the model for real applications, agent systems and enterprise workflows now.

Google AI Studio Is One Starting Point

Developers can start working with Gemini 3.8 Flash through Google AI Studio and the Gemini API. AI Studio gives builders a direct environment for testing prompts and model behavior, while the API provides the path into custom applications. This makes the new Flash model immediately accessible to both rapid experimentation and production development.

Gemini Enterprise Adds a Business Deployment Path

Google is also making Gemini 3.8 Flash available through Gemini Enterprise. That gives organizations a deployment path for agentic and multi-step workflows using Google’s enterprise AI platform. The same model can therefore sit behind individual developer experiments and larger managed applications.

Antigravity Uses Gemini 3.8 Flash by Default

Google’s documentation says the Antigravity agent and Antigravity SDK use Gemini 3.8 Flash by default. That is a strong signal about where Google sees the model fitting: at the center of agent workflows that need planning, tool orchestration and sustained work across multiple steps.

The Gemini App Is Part of the Rollout

For consumers, Google says Gemini 3.8 Flash is available to Google AI Pro and Ultra subscribers in the Gemini app. This gives the model a consumer-facing route alongside the developer and enterprise paths, bringing its new reasoning and agentic capabilities into Google’s broader AI ecosystem.

AI Mode in Google Search Also Gets 3.8 Flash

Google is also bringing Gemini 3.8 Flash to AI Mode in Google Search for Google AI Pro and Ultra subscribers. That puts the model’s reasoning capabilities directly inside one of Google’s most widely used information products and shows how the Flash line is becoming part of more than standalone AI tools.

Gemini in Sheets Is Included

Gemini 3.8 Flash is also available in Gemini in Google Sheets for eligible subscribers. Spreadsheet work is a natural place for reasoning, structured data and multi-step assistance to come together. The inclusion of Sheets shows how Google is extending the model into everyday productivity workflows as well.

Google Demonstrated an Entire 3D Game From One Prompt

One of Google’s launch demonstrations shows Gemini 3.8 Flash building a functional 3D game from a simple prompt using a looping instruction inside Google Antigravity. The demo combines puzzles, environmental storytelling and generated textures, providing a vivid example of the model working through a creative software task rather than producing only a short piece of code.

A DOS-Style Google Maps Demo Shows Its Range

Google also demonstrated Gemini 3.8 Flash creating a playable DOS-style version of Google Maps from a single prompt in Antigravity. The result includes locations, directions and Street View. It is a playful showcase, but it also demonstrates the model’s ability to combine interface work, application logic and connected information inside one generated experience.

Hardware Anatomy Turns Device Teardowns Into Interactive 3D

Another Google demo, Hardware Anatomy, uses Gemini 3.8 Flash in Google AI Studio to generate interactive Three.js visualizations of hardware devices. The experience breaks a device into layers that can be explored with a deconstruction slider. It is a strong example of the model combining technical understanding with visual software generation.

Introductory API Pricing Starts at $0.75 Per Million Input Tokens

Google lists introductory Gemini 3.8 Flash pricing at $0.75 per million input tokens and $3.75 per million output tokens through December 31, 2026. That pricing gives developers a clear entry point for experimenting with long-context, tool-using and agentic applications on the new model.

Why This Launch Matters

Gemini 3.8 Flash brings several trends together in one model: large context, multimodal input, built-in tools, configurable reasoning, computer use and a strong focus on autonomous agents. The important shift is that Flash is becoming a workhorse for applications that can keep going, use tools and complete larger digital tasks.

The Upgrade Feeling

The most interesting thing about Gemini 3.8 Flash is how much of the modern AI workflow now fits inside one fast model tier. A developer can give it a large project context, connect functions and search, let it execute code, bring in files, ground its work with live information and build an agent around the same model. That feels less like a simple model update and more like a new foundation for software that can actually work through a task.

Google Assistant Starts Disappearing From Android This Week — Gemini Is Taking Over the Assistant Layer

For years, “Hey Google” meant Google Assistant.

This week, that relationship starts changing for good.

Google says it will begin removing access to Google Assistant on affected mobile devices on September 3, 2026. The rollout may take several weeks to reach everyone, but once access is removed, users will no longer be able to use or switch back to Google Assistant on those phones and tablets. Gemini becomes the voice-assistant experience on Android instead.

The obvious story is that one assistant is replacing another.

The more important story is that Android is changing what an assistant is expected to be.

Google Assistant was designed around requests that often ended in an action: set a timer, call someone, play music, navigate somewhere, control a device.

Gemini keeps those familiar entry points, but Google is building the newer assistant layer around conversation, context, connected apps and increasingly multi-step work.

The button can stay the same.

The system behind it is changing.

September 3 Is the Start, Not One Global Kill Switch

The date needs one important clarification.

Google is not saying every Android device on Earth will lose Google Assistant at the same second on September 3.

Its August 6 community announcement says it will begin removing access on September 3 and expects the process to take a few weeks to reach everyone.

A separate Gemini Apps Community update says that on September 4 most users will no longer be able to use or switch back to Google Assistant on their phone or tablet.

Those two statements describe a phased transition rather than one universal cutoff.

That distinction matters because users may see different behavior for a while. One phone may already be on Gemini while another eligible device has not yet received the same transition.

The direction, however, is no longer ambiguous.

On mobile Android, Google Assistant is being discontinued and Gemini is becoming the default assistant experience.

This Is More Than an App Replacement

It would be easy to read the change as a simple app swap:

Google Assistant → Gemini.

But the assistant on Android is deeper than one icon in the app drawer.

Google’s current Gemini help documentation says that once Gemini is the primary assistant, users can still reach it through familiar methods such as “Hey Google,” long-pressing the power button or using the same touch gestures previously used for Google Assistant.

That continuity is important.

The invocation layer can remain familiar while the assistant behind it gains a different interaction model.

The user still holds a button or says a wake phrase.

What happens after that trigger is the part being rebuilt.

This also changes how users should read the Gemini app itself. On some devices, Gemini is not merely an app that happens to be installed. Once selected as the primary assistant, it becomes the system-level destination for assistant triggers. That distinction explains why the September change can affect behavior outside the Gemini app icon itself.

The Button Can Stay the Same While the Assistant Changes

A device interface is often easiest to understand by separating the trigger from the system that receives it.

The power button is a trigger.

“Hey Google” is a trigger.

A swipe gesture is a trigger.

For years, those triggers routed the user into Google Assistant.

Now Google is routing them into Gemini on eligible Android devices.

This is why the transition can feel small on the surface even though the underlying product is changing substantially.

A familiar gesture does not guarantee the same kind of interaction.

The old assistant could interpret many direct commands and hand them to specific device or service actions.

Gemini is designed to keep more context inside a conversation and combine that context with information from apps and the device.

The entry point stays stable.

The assistant layer becomes more conversational.

Google Assistant Was Built Around Actions

Google Assistant helped make voice control practical on Android.

Its common jobs were concrete and easy to express:

“Set a timer for 20 minutes.”

“Call Alex.”

“Play this playlist.”

“Navigate home.”

“Turn off the living-room light.”

Those interactions usually have a clear intent and a clear endpoint.

The system recognizes the request, identifies an action and executes it through the appropriate service.

That model is still useful, and Gemini continues to support assistant-style actions on eligible devices.

The change is that Google is now placing those actions inside a broader conversational system rather than treating each request as an isolated command.

Gemini Starts From Conversation and Context

A generative assistant can begin with a less structured request.

Instead of asking only for one action, the user can describe a goal with several conditions.

Google used an Android Auto example when it first detailed Gemini’s expansion across Android devices: a driver could ask for a charging station on the way to the post office that is also near a park.

That request contains several pieces of intent at once.

The destination matters.

The charging stop matters.

The nearby park matters.

The system has to preserve the relationship between those constraints rather than treat each phrase as an unrelated command.

This is the interaction pattern Google is pushing across Android: speak naturally, keep the context and let the assistant work out which app or service needs to handle the result.

Follow-up questions are part of that model too. A user can refine a request without restating every condition from the beginning. That makes context retention part of the interface rather than an optional extra. The assistant is expected to understand not only the latest sentence, but how that sentence relates to what came before.

Gemini Is Becoming the Assistant Layer Across Android

Google’s longer-term Android direction makes the mobile cutoff easier to understand.

In May 2026, Google introduced Gemini Intelligence as a more proactive intelligence layer for newer Android devices. The company described features that can automate multi-step work across apps and expand over time from phones to watches, cars, glasses and laptops.

That is not the same thing as saying every Gemini Intelligence feature becomes available to every Android user when Google Assistant is removed.

Availability still depends on device, market, account and feature rollout.

But the product direction is clear.

Google is no longer treating Gemini as one chatbot sitting beside Android.

It is positioning Gemini as part of the operating experience itself — the system users reach when they ask the device for help.

The official Android video embedded after this section was published in May 2026. It is not a September 3 shutdown announcement. It shows the broader Gemini Intelligence direction Google is bringing into Android while the mobile Assistant transition reaches its final stage.

The Assistant Is Moving From Answers Toward Tasks

Conversation becomes more useful when it can lead somewhere.

Google’s 2026 Android announcements increasingly connect Gemini with actions that cross app boundaries.

Gemini Intelligence, for example, is being developed to automate multi-step tasks across supported apps on selected devices.

That changes the role of the assistant.

An answer-only system can explain what to do.

An action system can carry out one defined command.

An agentic system can potentially take a higher-level goal, break it into steps and coordinate those steps across tools.

Google is still rolling these capabilities out in waves, so the current mobile Assistant transition should not be presented as if every Android phone instantly becomes a full autonomous agent.

The useful point is narrower:

The assistant Google is choosing as Android’s default is being built for a much broader job than voice commands alone.

The practical boundary will still matter. Some requests will remain informational, some will trigger a familiar device action, and some newer capabilities will depend on supported apps or newer hardware. The transition is therefore best understood as an expansion of the assistant role, not the replacement of every existing workflow with autonomous automation.

Your Phone Is the Anchor for More Than the Phone

The September transition follows the phone into several devices paired with it.

Google says that when Gemini becomes the assistant on a mobile device, it also becomes the assistant on paired devices that lose access to Google Assistant.

The list includes Wear OS watches, compatible headphones and earbuds, and vehicles using Android Auto projected from the phone.

That makes the phone the anchor for a wider assistant experience.

The user may trigger Gemini from a watch while running, from earbuds while walking or from Android Auto while driving.

Those are different screens and different physical contexts.

But the assistant layer is increasingly the same one.

That cross-device model also explains why Google describes paired accessories in the same migration notice as the phone itself. The user may think of a watch, earbuds and car display as separate products, but the assistant relationship can be inherited from the mobile device they are attached to. Changing the assistant on the phone can therefore change the experience around the phone too.

Wear OS Becomes Part of the Same Assistant Experience

Google began describing this cross-device direction well before the September cutoff.

When it announced Gemini for Wear OS, Google emphasized natural language rather than carefully phrased voice commands.

One example was asking the watch to remember a locker number. Another was asking about a restaurant mentioned in an email without taking out the phone.

The value of that model is not that a watch becomes a tiny chatbot.

It is that the watch becomes another surface for the same assistant context.

A request starts where the user happens to be.

The assistant can then connect that request to information or services that live elsewhere in the ecosystem.

The Pixel Watch image in this article is illustrative and predates the 2026 transition; it shows the type of paired Wear OS device included in Google’s current mobile-assistant migration rules.

Android Auto Follows the Phone — With One Important Boundary

Android Auto is also part of the mobile transition when it is projected from the user’s phone.

Google says vehicles running projected Android Auto will move with the phone from Google Assistant to Gemini.

That fits the broader direction Google announced for driving: more natural conversation, connected messaging help and requests that combine several conditions in one sentence.

But there is an important exception.

Cars with Google built-in are not on the same September 3 cutoff.

Google explicitly says Google Assistant will continue to function in those vehicles beyond September 3, 2026.

That means “Android in the car” is not one identical assistant stack.

Projected Android Auto follows the paired phone.

Google built-in has its own transition path.

Nest and Google Home Are Not Part of This Mobile Cutover

The same caution applies inside the home.

Google Assistant is not disappearing from every Google device this week.

Google says the mobile changes do not affect Google Nest and Google Home smart speakers, smart displays or other standalone Assistant-enabled speakers and displays.

Those products remain on a separate path.

This matters because the phrase “Google Assistant is shutting down” is too broad for the current announcement.

The more accurate description is:

Google is discontinuing Google Assistant on mobile devices and paired accessories covered by this transition, while other Assistant surfaces continue operating.

The mobile layer moves first.

The Same ‘Hey Google’ Phrase Is Becoming a Routing Layer

One of the most interesting parts of the transition is that Google does not need to replace the wake phrase.

Users can continue saying “Hey Google.”

What changes is the destination behind it.

For years, the phrase meant “open Google Assistant.”

On eligible Android devices, it increasingly means “open Google’s current assistant layer,” which is now Gemini.

That creates continuity for users while giving Google room to replace the system underneath.

The interface people have learned stays recognizable.

The intelligence handling the request changes over time.

That is a useful way to think about the September transition: not as the disappearance of voice assistance, but as the rerouting of a familiar interface into a different AI system.

Not Every Gemini Capability Arrives Everywhere at Once

A platform transition this large comes with several overlapping timelines.

Google Assistant access is being removed from affected mobile devices.

Gemini is becoming the default assistant.

Gemini Intelligence features are rolling out in waves on selected newer hardware.

Wear OS, Android Auto, TVs, XR devices and other surfaces have their own feature schedules.

Those statements can all be true at the same time.

They should not be collapsed into one claim that every Gemini feature becomes universally available on September 3.

Google’s own documentation repeatedly notes that availability varies by device, account, region, language and feature.

So the September date marks a change in the assistant layer.

It does not mark the completion of every Gemini rollout across Android.

This is especially important during the first weeks of September. Two people can both be using Android and still see different assistant behavior because their devices, accounts or rollout stages differ. A phased platform migration is not evidence that one of those devices is configured incorrectly; it can simply mean the transition has reached them at different times.

What This Change Does — and Does Not — Mean

The current Google documentation supports a specific set of conclusions.

Google begins removing access to Google Assistant on affected mobile devices on September 3, 2026.

The process may take several weeks to reach everyone.

Most users are expected to lose the option to use or switch back to Google Assistant around September 4.

Gemini becomes the primary assistant on eligible Android devices and can be reached through familiar methods including “Hey Google” and existing touch shortcuts.

The transition also applies to paired Wear OS devices, compatible headphones and earbuds, and projected Android Auto.

It does not mean Google Assistant disappears from every Google product this week.

Nest and Google Home speakers and displays remain outside this mobile cutover.

Cars with Google built-in also continue using Google Assistant beyond September 3.

And it does not mean every Gemini or Gemini Intelligence capability is available on every Android phone immediately.

The Bigger Shift Is From Device Control to Goal Handling

Google Assistant helped establish a simple expectation: ask the device to do something and it should understand the command.

Gemini is being built around a broader expectation.

The user can explain what they are trying to accomplish, continue the conversation, add constraints and let the assistant connect that intent to apps and services.

The mobile transition beginning this week therefore matters beyond the name on the screen.

It marks the point where Android’s default assistant layer is being defined by generative AI rather than by the earlier voice-assistant architecture alone.

The old interaction does not vanish completely. Users will still ask for timers, directions, calls and other direct actions.

What changes is the ceiling above those actions.

The assistant is no longer being designed only to understand a command.

It is being designed to understand the goal around it.