Chrome's 3 New AI APIs: 6 Hours, 4 Days, Or 3 Weeks

By Lazar Milicevic · Published September 25, 2026 · 8 min read

Google's I/O recap listed Chrome's new AI surfaces in this order: WebMCP, Built-in AI, Skills. I wired all three into a real client project — a browser-side invoice preview for a small invoicing SaaS — and the ship-date order is the exact opposite. If you're a small team staring at these three wondering which one deserves a sprint this quarter, this post will save you three weeks.

The three APIs, in one paragraph each

Chrome now exposes three distinct AI surfaces, and they solve very different problems. WebMCP is a browser-side bridge that lets an AI agent running in the tab call your APIs through the Model Context Protocol — the browser becomes an authenticated caller. Built-in AI ships Gemini Nano inside Chrome, so a page can run local inference with no server round-trip and no per-token bill. Skills in Chrome are packaged, versioned instruction bundles the browser can hand to any AI surface — closer to "npm module for prompts + validators" than to a model.

Google presented them WebMCP → Built-in AI → Skills, ordered by capability ceiling. For a small team, capability ceiling is the wrong axis. The right axis is integration cost divided by auth risk. On that axis the list flips.

Quick reference

• Skills: hours to ship, no auth changes, works today.
• Built-in AI: days to ship, gated behind a feature flag, cold-load problem.
• WebMCP: weeks of auth rework, spec still moving, not a Q4 item.

Skills in Chrome: 6 hours, zero backend changes

Skills is the one to ship in the next 90 days. It's a package of instructions plus a small validator that the browser hands to whatever AI surface the user has active. No server changes, no auth changes, no new tokens to rotate. For the invoice preview tool we packaged the validation and formatting logic — line-item totals, tax math, currency formatting — as a Skill and dropped it into the preview page. Clone to shipped: six hours, including the code review.

A minimal Skill for something like an invoice check looks like this:

{
  "name": "invoice-preview-check",
  "version": "1.2.0",
  "description": "Validate an invoice draft before send",
  "inputs": {
    "invoice": { "type": "object", "required": true }
  },
  "instructions": "Validate line items sum to subtotal. Verify tax rate matches customer region. Flag missing PO number for B2B invoices over $500.",
  "validators": ["./validators/totals.js", "./validators/tax.js"]
}

The reason this ships so fast: Skills doesn't touch your API surface at all. It's a client-side artifact. The browser loads it, hands it to the model the user is talking to, and the model behaves consistently across ChatGPT, Gemini, Claude, or whatever agent is embedded. You version it like any other frontend asset.

Good candidates for a Skill right now:

• Recurring form fillers (W-9, ACH authorization, shipping address blocks)
• Document preview validators (invoice, quote, contract redlines)
• Repeatable checks — the "does this PDF actually parse?" step
• Any browser-side task you do more than 6 times a year

Bad candidates: anything that needs a database write, anything that needs a secret, anything that must be authoritative rather than assistive. Skills is an assistant layer, not a system of record.

Built-in AI (Gemini Nano): 4 days, then the 180 MB problem

Built-in AI is clean to integrate and painful to roll out. The API itself is small — you check availability, request a session, prompt it, stream the response.

if ('ai' in window && 'languageModel' in window.ai) {
  const caps = await window.ai.languageModel.capabilities();
  if (caps.available === 'readily') {
    const session = await window.ai.languageModel.create();
    const summary = await session.prompt(
      `Summarize this invoice in one sentence: ${invoiceText}`
    );
  }
}

The integration itself took a day. Testing, error handling, and telemetry took the other three. Then staging hit the real problem: first-load requires a ~180 MB model download. On our test cohort, about 22% of users on slower connections bounced before the download finished. The model is shared across sites once it's on the device, but if you're the first site to trigger it for that user, you eat the wait.

That single fact reshapes the rollout:

• Behind a feature flag from day one — never on the critical path.
• Server-side fallback that does the same job through your existing LLM provider (OpenAI, Anthropic, whatever). Feature parity matters; the user shouldn't notice which path ran.
• Progressive availability check: only enable the local path when capabilities().available === 'readily', never on 'after-download' for a first-time visitor.

The upside once the model is warm is real. Zero per-request cost, zero latency to the network, and it works offline. For a document-heavy SaaS with returning users, that math compounds. But it's a six-month bet, not a this-quarter bet. Ship it behind a flag, measure warm-cache hit rate, and only promote it to the default path once your P50 user has the model already resident.

One thing the docs don't emphasize enough: Gemini Nano is small. Do not expect GPT-4-class reasoning. It's good at classification, extraction, short summaries, and structured rewrites. It is not good at multi-step reasoning or long-context synthesis. Scope your prompts accordingly or you'll ship a feature that measurably underperforms your server fallback.

WebMCP: 3 weeks minimum, and the spec is still moving

WebMCP is the one Google led with, and on paper it is the most exciting of the three. It lets an in-browser agent call your APIs through a Model Context Protocol bridge — the agent living in the tab can now be a first-class caller of your service.

In practice, it breaks a load-bearing assumption of most SaaS auth models: only your server talks to your API. Suddenly the browser is an authenticated actor invoking privileged endpoints. Every one of these has to be rethought:

• Token scopes: your existing session cookie almost certainly grants too much. You need scoped, short-lived tokens that limit which endpoints the browser-side agent can hit.
• Rate limits: an agent can generate 50x the request volume of a human clicking. Your per-user rate limits were sized for humans.
• Audit logs: "user X did Y" is no longer sufficient. You need "user X's agent, acting on prompt Z, did Y." That's a schema change and a UI change.
• Consent: the user needs to see and approve which tools the agent is allowed to call. That's a whole new settings surface.
• CSRF / origin: MCP over a browser transport blurs the same-origin story. You need to think carefully about what a malicious page could ask a legitimate agent to do.

For the invoice tool, just the auth rework was scoped at roughly three weeks — and that estimate assumed the spec stayed still, which it hasn't. As of this writing, WebMCP is closer to a roadmap direction than a stable API contract. Building on it now means re-integrating on every spec revision.

The rule I now use with clients: if a browser-side AI feature requires me to rewrite my auth model, it does not belong in this quarter's plan. Read the spec, prototype in a branch, and stay out of production until the shape settles.

The ship-date ranking, side by side

Small teams should rank AI features by integration cost divided by auth risk, not by capability ceiling. Every time I've followed the hype order instead of the ship-date order, I've eaten two weeks I didn't have. Skills first, Built-in AI second behind a flag, WebMCP watched from a safe distance until the spec settles — that isn't a conservative take, it's the only order that keeps you shipping while competitors are refactoring their auth layer.

A practical Q4 plan for a small SaaS

If you have one engineer and want to actually capture some of this without derailing the roadmap:

1. Week 1: Pick one repeatable browser-side task. Package it as a Skill. Ship it. This is a low-risk win and gives you a versioned artifact you can iterate.
2. Week 2-3: Add a Built-in AI path behind a feature flag for a non-critical enhancement (summarize this doc, extract these fields). Keep the server fallback as the default. Measure warm-cache rate.
3. Week 4: Read the current WebMCP spec, sketch what your scoped-token model would look like, file it as an RFC in your own repo. Do not build it yet.

The result at end of quarter: one shipped feature, one flagged experiment with real telemetry, one design doc ready for when the spec stabilizes. That's a defensible allocation of a single engineer's time. It also compounds — the Skill you shipped becomes the instruction bundle a future WebMCP agent will call.

Where bizflowai.io fits in

We build these browser-side automations for small SaaS teams every week — VAT checks, invoice validators, document preview flows, form fillers. The pattern is always the same: identify the 6-hour Skill-shaped win first, wire in Built-in AI behind a flag where it earns its keep, and leave the auth-heavy pieces alone until the spec stops moving. If you're staring at an I/O recap wondering where to actually start, that's the work bizflowai.io does.

Want more like this?

I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.

Subscribe to bizflowai.io on YouTube — never miss a new tutorial.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.

Visit bizflowai.io for our services, case studies, and AI consulting.