I/O 2026 turned agents into an API line item

Three days after the keynote, the headline from Google I/O 2026 is not a model. It is a billing line. Managed Agents in the Gemini API charges per run, not per token. That single pricing decision tells you more about where Google thinks application code is going than any of the demos did.

This post is the developer cut of the week. No XR glasses, no Spark, no Search rewrites. Just the things that landed in an SDK, a CLI, or a Chrome flag, and what each of them is actually for.

Agents got an endpoint

The single largest surface change is Managed Agents in the Gemini API. One call to the Interactions API provisions an ephemeral Linux sandbox with a bash shell, a writable filesystem, web access, and a model already wired into the loop. The agent reasons, plans, calls tools, and writes files. You get an environment ID back. Pass it to the next call and the session resumes with all state intact.

The model behind it is the new Antigravity agent built on Gemini 3.5 Flash, which Google claims outperforms 3.1 Pro across most benchmarks at roughly four times the speed. The agent harness, the sandbox, the planning loop - all of it is hosted. You pay for an outcome rather than a transcript.

This is the part worth dwelling on. Until now, building an agent on someone else's model meant building everything around the model yourself: a sandbox, a tool registry, a retry loop, a state store, an eviction policy for the file system, observability for tool calls. Half of every agent codebase was infrastructure. Managed Agents replaces all of it with a goal and a list of permitted tools.

By default the sandbox is sealed. From the docs:

By default, every agent performs actions in a sandbox environment with no access to external systems, networks, or credentials, and can only interact with files, packages, and data inside its own sandbox.

That is the right default. The agent can untar an archive, run a Python script, edit a config, and hand you back the diff. It cannot reach your database or your secrets unless you mount them in. If you have spent any time thinking about prompt-injected agents calling production APIs, you understand why this matters.

Two things to verify before you build on it. The preview is rolling out in the public Gemini API and on the Gemini Enterprise Agent Platform; quotas and SLAs are not the same in both. And pricing is described as pay-per-run, but the official price sheet for run-based billing was not posted at the time of writing. If your workload is high-frequency and short-lived, model both pay-per-token and pay-per-run before you commit.

Antigravity 2.0 is the IDE on top

If Managed Agents is the runtime, Antigravity 2.0 is the workbench. The 1.0 release last winter was a single agent in a desktop shell. 2.0 is four things: a desktop app, a CLI rewritten in Go, an SDK for embedding the harness in your own tools, and the Managed Agents API above.

The piece worth attention is dynamic subagents. You give the main agent a complex task; it decomposes the task and spawns parallel subagents - frontend, backend, tests, security - each in its own sandbox, each reporting back to the parent. The practical ceiling appears to be four or five concurrent subagents before coordination overhead eats the wins, but for tasks like "port this module and update its callers" the parallelism is real.

The CLI matters more than it sounds. A Go binary that runs the same harness as the desktop app, without the GUI, slots directly into CI. You can put an Antigravity invocation in a GitHub Actions job and get back a structured result. The desktop app is for steering; the CLI is for automation. Both share the same agent definitions, declared in AGENTS.md and SKILL.md files that live in your repo.

The SDK is the escape hatch. If you do not want Google's UI but do want the orchestrator and the subagent semantics, you can self-host the harness against your own infrastructure. That is a meaningful concession for teams who have security teams that will not green-light a hosted IDE but will green-light a library.

AI Studio stopped being a playground

Google AI Studio picked up four updates that, taken together, push it across the line from "try a prompt" to "ship a thing":

• Native Kotlin support to vibe code full Android apps from a prompt, with the generated project structured for Android Studio import.
• One-click deployment to Cloud Run for the server side of whatever you built.
• Direct Firebase wiring for auth, Firestore, and storage.
• Google Workspace API integration so an app built in AI Studio can read Gmail or write to Drive without a second OAuth dance.
• A new mobile app for iterating on prompts away from the desk, and a one-click export of project state to Antigravity when the prototype graduates.

The export to Antigravity is the connective tissue. AI Studio is for the first sketch; Antigravity is for the version your team has to maintain. Until I/O, that handoff involved copy-paste.

WebMCP: the web tries to speak agent

The most architecturally interesting announcement was on the browser side. WebMCP is a proposed open web standard that lets a site expose structured tools - JavaScript functions or annotated HTML forms - directly to an in-browser AI agent. The origin trial begins in Chrome 149. Gemini in Chrome will be the first agent that calls into it.

The shape is navigator.modelContext. A page registers a tool; the agent in the browser discovers it; the call is dispatched in the page's own context, with the user's credentials and CORS rules already applied. Two flavours:

• Imperative: define tools as JavaScript functions and register them with the model context.
• Declarative: annotate an HTML form with attributes that describe what it does, and the browser exposes it as a callable tool automatically.

The pseudocode in the spec gives the flavour - tools look like ordinary functions, parameterised by the things a model would need to fill in:

// Imperative shape (illustrative; spec is in active development)
navigator.modelContext.registerTool({
  name: "orderPrints",
  description: "Order physical prints of the current design.",
  parameters: {
    copies: { type: "number" },
    page_size: { type: "string", enum: ["a4", "letter"] },
    page_finish: { type: "string", enum: ["matte", "glossy"] },
  },
  handler: async ({ copies, page_size, page_finish }) => {
    return await checkout({ copies, page_size, page_finish });
  },
});

Compare that with the alternative we have today. To let an agent buy something on your site, you either run a headless browser that pretends to be a user and hope the DOM does not change, or you stand up an MCP server somewhere and reimplement your business logic against it. WebMCP collapses both: the site already has the logic and the auth; expose it as a tool and the agent uses the real thing.

The commitments matter. Booking, Shopify, Instacart, and Intuit are implementing before GA. That is the set of sites whose flows agents will actually want to run. If Shopify ships WebMCP on storefronts, every Shopify store gets agent-callable checkout for free.

Two limits to flag. WebMCP only works with an open tab or webview; there is no headless mode. And it lives in the W3C Web Machine Learning Community Group, which is not the Standards Track. The Anthropic side of MCP is server-side and stable; this is the parallel, browser-side proposal, with a smaller coalition behind it. Origin trials in Chrome have a track record of either becoming standards or quietly evaporating.

Chrome DevTools for Agents

Chrome DevTools for Agents 1.0 is the smaller announcement that will matter most in practice. It gives any agent direct, structured access to the things you have been pasting into chat windows for a year: console messages, network traffic, the accessibility tree, performance traces, Lighthouse audits. The integration is not Antigravity-specific; the team is shipping it for more than twenty coding agents, including the ones you already use.

The mental model is straightforward. Where MCP gave agents access to the filesystem and shell, DevTools for Agents gives them access to the running app. An agent that just edited your CSS can open the page, take a snapshot, observe the layout shift, and decide if the change actually worked. That loop existed before but required a human in the middle.

Android, briefly

Android Studio shipped the Android CLI stable, with the explicit goal of letting agents drive the heavy parts of Android development from outside the IDE - downloading the SDK, building, deploying to a device. The migration agent preview promises to convert React Native, web, or iOS apps to native Kotlin in hours. That is a strong claim that nobody has independently verified yet, so treat it as a thing to test, not a thing to assume.

More verifiable: the new Android Bench leaderboard now includes open-weight models like Gemma 4, which is a useful counterweight to benchmark posts where the only competitors are Google's own.

Where the pieces fit

Lined up, the announcements describe a single architecture rather than a grab bag of features:

Each piece is independently useful. Together they describe Google's bet: that the next unit of developer work is not a function call or a request, but an agent invocation, and the platforms that win will be the ones that make that invocation cheap, isolated, and debuggable.

What to actually do this week

If you are evaluating any of this, the cheap experiments are:

• Try Managed Agents from ai.studio against a task you would otherwise have built a custom agent harness for. Measure the runs that fail and the runs that succeed in three turns. The pricing model only makes sense if your average task ends in a small number of runs.
• Install the Antigravity CLI and put one read-only agent in a CI job - a documentation auditor, a dependency reviewer, a release-notes generator. Treat it as a structured CI step, not a chat partner.
• If you operate a transactional website, read the WebMCP proposal and decide whether you want to be in the origin trial. The cost of declaring a few high-value tools now is low; the cost of being the only major site in your category that agents cannot use is starting to be real.
• Wire Chrome DevTools for Agents into whatever coding agent you already use. This is the lowest-risk change with the highest payoff: your existing agent gets to see what the page actually does.

The pay-per-run pricing is the line worth watching. If it sticks, agent invocations become a budgeted resource the way database queries are - countable, capped, alerted on. The application stack quietly grows another tier, and the people who learn to design for it first will be the ones whose products feel like they belong in 2026.