Google folds computer use into Gemini 3.5 Flash as a built-in tool

From a separate model to a built-in tool

The structural change here is small to describe and large in practice. Computer use was previously available only as a standalone Gemini 2.5 computer use model. In this release it becomes a built-in tool inside Gemini 3.5 Flash, sitting alongside the function calling and grounding tools (Search, Maps) that Flash already exposes.

That matters because it changes how you compose an agent. Instead of routing UI-driving steps to one model and reasoning steps to another, a developer can ask a single Flash instance to see, reason and act — Google's words — across browser, mobile and desktop environments within one tool-calling loop. The seams between 'understand the task' and 'click the button' disappear from the integration surface.

The two demos are frontend work, not chatbots

Google illustrates the capability with two concrete tasks, and both are frontend engineering chores. In the first, 3.5 Flash analyses the Gemini app and returns a categorized list of features. In the second, it audits its own documentation for accessibility issues.

Read those as templates. Feature inventory against a live UI is regression-mapping and coverage work. Accessibility auditing is a task frontend teams routinely defer because it requires patiently walking a rendered interface. Both are exactly the kind of repetitive, screen-reading labor that an agent driving a real browser can attempt, and both are explicitly what Google is pointing developers toward with its 'continuous software testing' framing.

The distinction worth holding onto: this is an agent operating on the rendered surface of an application, not on its source. That makes it useful precisely where you don't control or can't easily instrument the frontend — third-party apps, embedded widgets, cross-platform flows.

Prompt injection is treated as an operating condition, not an edge case

Any agent that reads a live UI can read text an attacker planted in that UI. Google acknowledges this directly and ships more than a disclaimer. There is targeted adversarial training baked into the model, plus two optional enterprise safeguard systems: one that requires explicit user confirmation before sensitive or irreversible actions, and one that automatically stops a task when an indirect prompt injection is detected.

Taking a “defense-in-depth” approach, we encourage developers to combine these features with secure sandboxing, human-in-the-loop verification and strict access controls.Montana Labs

The honest signal in that sentence is that model-level training is not offered as sufficient. The safeguards are optional and layered, which means the responsibility for a safe deployment still lands on the team building the agent. If you point Flash at a page an adversary can edit, the sandboxing and access-control work is yours to do.

What a native computer-use tool changes for teams shipping UI automation

The practical implication is that UI automation stops being a specialized model choice and becomes a capability toggle inside the model you were likely already using for tool calling. Access is via the Gemini API and the Gemini Enterprise Agent Platform, with a demo environment hosted by Browserbase for teams that want to try it before wiring up their own sandbox.

For frontend and QA groups, the near-term test is narrow and answerable: does an agent driving the rendered app produce a feature inventory or accessibility report you'd trust enough to act on? Google has put both tasks forward as showcases, which makes them the fair benchmark. The infrastructure question — sandboxing, confirmation gates, injection stops — is now the part that determines whether this is a demo or a deployment.