Source: Google Developers Blog — https://developers.googleblog.com/all-the-news-from-the-google-io-2026-developer-keynote/
Google’s I/O 2026 developer keynote was less about another coding assistant and more about moving agents into the developer stack as first-class infrastructure.
The headline claim from Google is clear: it wants developers to build and run agents that can navigate complex workflows, not just answer prompts or autocomplete code. The announcements span Gemini 3.5 models, Antigravity 2.0, managed agents in the Gemini API, Android tooling, Chrome DevTools integrations, and early web standards work through WebMCP.
That is a large surface area. The useful reading is narrower: Google is trying to make agentic development less like a chat window and more like an orchestrated runtime with sandboxes, credentials controls, IDE/tool access, deployment paths, and task-specific skills.
The core shift: agents get infrastructure, not just prompts#
Google framed the keynote around the move from AI that “assists” to agents that can independently handle larger parts of a workflow. The practical anchor is Antigravity 2.0 and a new Antigravity CLI.
According to Google, Antigravity now supports specialized subagents for complex workflows. It also includes cross-platform terminal sandboxing, credential masking, and hardened Git policies. Those details matter more than the productivity claim. Once an agent can run commands, touch files, interact with repositories, and move across a project, the security model becomes the product.
The Antigravity CLI is meant to give developers another surface for these workflows. Google also announced an Antigravity SDK for teams that want programmatic control over the agent harness and want to host agents on their own infrastructure.
That split is important. Managed surfaces lower the setup cost. Self-hosted control matters for teams that cannot send sensitive build logic, credentials, or repository state into a fully managed black box. The source does not give enough detail to judge the boundary conditions yet, but the direction is visible: Google wants the same agent harness to exist in hosted, CLI, API, and self-managed forms.
Managed agents move into the Gemini API#
Google also announced Managed Agents in the Gemini API. The pitch is simple: a single API call can provision an agent with a remote sandbox, using the Antigravity agent harness without requiring developers to build the infrastructure themselves.
This is one of the more consequential announcements if it works as described. Many teams can prototype agent workflows with scripts and tool calls. Fewer want to maintain remote sandboxes, execution policies, state handling, and isolation rules. Managed Agents tries to turn that operational burden into an API feature.
The trade-off is the usual one. Managed execution can accelerate adoption, but it also concentrates trust. Developers will need to understand what runs where, what the agent can access, how sandboxes are isolated, how logs are retained, and how credentials are protected. Google’s post mentions credential masking and sandboxing in the Antigravity context, but it does not provide enough implementation detail to treat those controls as fully evaluated.
For now, the safe read is: this reduces friction for agent orchestration, but it does not remove the need for a trust model.
AI Studio becomes a fuller app-building surface#
Google AI Studio is also being pulled deeper into application development. Google said AI Studio now has native Kotlin support for building Android apps, Google Workspace integrations, one-click deployment to Cloud Run, and Firebase service support.
The goal is to let developers build and launch full-stack apps directly inside AI Studio, then export the complete project state to Google Antigravity if they want to continue development there.
That export path is worth noting. AI-assisted app builders often fail at the handoff point: the demo works, but the project becomes hard to maintain outside the generation environment. Google is signaling that the AI Studio-to-Antigravity path should preserve state rather than strand the developer in a toy workspace. The source does not prove how clean that handoff is in real projects, but it identifies the right failure mode.
Android gets agent-accessible tooling#
Android was one of the strongest practical themes in the keynote. Google announced a stable Android CLI that lets AI agents use Android Studio’s heavier capabilities. The examples include downloading the Android SDK and running apps on Android devices.
That matters because Android development is not just code generation. It involves SDK management, device execution, build systems, migration paths, UI frameworks, and platform-specific behavior. Giving agents access to those workflows through a stable CLI is more useful than asking a model to hallucinate shell commands from memory.
Google also open-sourced Android skills for LLMs. These are meant to guide models through complex workflows and APIs, including migrations to Jetpack Compose and Jetpack Navigation 3. The point is not that an LLM suddenly “knows Android.” It is that Google is packaging task knowledge in a form agents can use.
Google also highlighted Android Bench, its LLM leaderboard for Android development tasks, and said open-weight models such as Gemma 4 were added this week. A leaderboard does not guarantee real-world fit, but it gives teams a better comparison point than broad coding benchmarks that may not reflect Android-specific work.
The most aggressive Android claim was a previewed Android Studio feature that migrates app code into a native Kotlin Android app, regardless of whether the source is React Native, a web framework, or iOS. Google said the agent analyzes code and can turn migrations that would have taken weeks into hours.
That should be treated as a preview claim, not a planning assumption. Migration tools are most valuable when they preserve architecture, behavior, tests, accessibility, and edge cases — not merely when they produce compilable code. Still, if Google can make even partial migrations reliable, it could change how teams approach cross-platform technical debt.
Web development gets agent hooks and browser-level tools#
Google also used the keynote to position the web as an agent-executable environment.
WebMCP is the clearest example. Google described it as a proposed open web standard that lets developers expose structured tools — including JavaScript functions and HTML forms — so browser-based AI agents can execute complex tasks with more speed, reliability, and precision. An experimental WebMCP origin trial starts in Chrome 149, with Gemini in Chrome support coming soon.
The important word is “proposed.” This is not yet a settled standard. If it matures, it could give web apps a cleaner interface for agent interaction than brittle screen scraping or DOM guessing. If it remains Chrome-first or fragmented, developers may be slower to rely on it for core workflows.
Google also announced Modern Web Guidance in early preview. It gives coding agents expert-vetted skills for performance, accessibility, and security, with support for more than 100 use cases. Google says it integrates with Baseline targets and can be installed in Antigravity or through the CLI with npx modern-web-guidance install.
This is another sign that agent quality may depend less on generic model capability and more on curated operational knowledge. The model matters. The tool instructions, constraints, and validation loops may matter just as much.
Chrome DevTools for agents pushes in the same direction. Google said agents will be able to use DevTools capabilities to verify, debug, and optimize code in real time. The described use cases include automated quality audits, real-world user experience emulation, session handoff with auto-connect, and other workflows without manual oversight.
That could be useful. It also raises the bar for governance. An agent that can inspect, debug, and optimize through browser tooling is closer to a junior automation operator than a passive assistant. Teams will need logs, reproducibility, permissions, and failure handling, not just impressive demos.
HTML-in-Canvas targets richer web experiences#
Separate from the agent orchestration layer, Google also announced an HTML-in-Canvas API in origin trial. The idea is to let developers place real DOM elements directly into a canvas with WebGL and WebGPU, while keeping the experience searchable, accessible, and interactable.
This is aimed at immersive and 3D web experiences that still need browser-native features. If the API works as intended, it could reduce the usual trade-off between high-fidelity canvas rendering and the accessibility/search benefits of regular HTML.
Again, it is an origin trial. Developers should evaluate it as an early platform capability, not a stable foundation for production architecture without checking support and fallback requirements.
What developers should watch next#
The practical takeaway from I/O 2026 is not “AI will write everything.” It is that Google is assembling the execution layer around AI-assisted development: sandboxes, CLIs, managed agents, browser hooks, Android task skills, DevTools access, and deployment paths.
For teams, the next checks are concrete:
- Test agent workflows against real repositories, not demo apps.
- Review sandbox, credential, and Git policy controls before giving agents write access.
- Treat migration features as accelerators, not substitutes for review and testing.
- Watch WebMCP’s standardization path before building critical dependencies around it.
- Compare Android-focused model performance with Android Bench, but validate against your own tasks.
The most credible part of Google’s announcement is the focus on tooling around the model. Agents become useful when they can act through reliable interfaces and be constrained when they should not act. That is also where most of the risk moves.