I/O 2026 vs 12 Legacy Portals: 2 Updates Died On Field 1

By Lazar Milicevic · Published July 10, 2026 · 10 min read

Your small business client logs into a tax portal, three bank export pages, four supplier portals, and a handful of marketplace dashboards every single week. Google I/O 2026 shipped three platform updates meant to automate exactly that. Two of them died before the first form field.

I ran all three updates — WebMCP, Skills in Chrome, and Built-in AI (Gemini Nano) — against twelve real vendor and government portals that a small invoicing business hits daily. Not Google's demo React checkout. The ugly stuff: iframes, rotating session tokens, captchas in modal popups, and login pages that still load jQuery. Here's the actual scoreboard, what failed, and which update is worth building on.

The Test Grid: 12 Portals A Real Business Actually Uses

Every I/O demo this year used a clean, modern React e-commerce checkout with semantic DOM elements and predictable class names. That is not what a small business encounters in the wild. To build a fair test, I assembled a grid of twelve portals that a real invoicing client interacts with every week:

• 1 government tax portal — conditional fields that render based on entity type, captcha modal, iframe-wrapped submission form
• 4 vendor supplier portals — two built on ASP.NET WebForms with __VIEWSTATE hidden inputs, one on a legacy Angular 1.x setup, one semi-modern React app
• 3 bank statement export pages — session tokens in the URL that rotate per click, download buttons that trigger server-side PDF generation, CSRF tokens embedded in meta tags
• 4 marketplace seller dashboards — two modern React/Next.js SPAs, one legacy jQuery dashboard, one hybrid that loads product data via iframe

This is the reality for most small business automation. If your agent can't handle a __VIEWSTATE payload or an iframe that opens a captcha modal, it can't handle the majority of B2B and government workflows that still run the economy. According to the U.S. Small Business Administration, there are over 33 million small businesses in the US alone, and the vast majority interact with legacy government and supplier portals weekly.

WebMCP: 2/12 Portals — Dead On Arrival For Legacy Sites

WebMCP is Google's Model Context Protocol for the web: websites expose MCP endpoints, and AI agents call them directly to retrieve structured data or trigger actions — no scraping, no DOM interaction. It's a clean, elegant spec. The problem is that it requires the website itself to implement the MCP server. Out of twelve real-world portals, exactly two had any kind of modern API surface, and neither exposed an MCP endpoint.

WebMCP scored 2 out of 12 because adoption requires every legacy portal on earth to voluntarily build and expose MCP infrastructure. That's not happening this decade. The two portals where WebMCP showed any signal were modern marketplace dashboards that already had REST APIs — and even there, they don't expose MCP endpoints yet. WebMCP is theoretically the cleanest path for websites that will be built in 2028 and beyond. For the sites your clients are logging into today, it's commercially irrelevant.

# What WebMCP assumes exists on the target site:
target_site:
  mcp_endpoint: "https://portal.example.com/.well-known/mcp"
  capabilities: ["read_invoice", "submit_return", "export_statement"]
  auth: "oauth2"

# What actually exists on a legacy supplier portal:
target_site:
  login_form: "POST /login.aspx"
  viewstate: "<input type='hidden' name='__VIEWSTATE' value='/wEPDwUKL...==' />"
  session_cookie: "ASP.NET_SessionId"
  captcha: "iframe src='/captcha/challenge.aspx'"

If you're building automation for clients who live entirely on modern SaaS platforms with developer APIs, WebMCP is worth tracking. If your clients touch anything government-adjacent or built before 2020, skip it entirely.

Skills in Chrome: 5/12 Portals — Fast When It Works, Dangerous When It Doesn't

Skills in Chrome gives the browser itself a set of agent capabilities: drive the DOM, fill form fields, click buttons, and read page content. It's a step up from Playwright or Puppeteer because the skills run natively in the browser context, not through a DevTools protocol shim. It scored 5 out of 12 in the test grid.

Where it worked: The two modern React marketplace dashboards. Skills could find form elements, fill them, click submit, and read the resulting confirmation. When it works, it's genuinely fast — form fills completed in under 2 seconds per field, with no network round-trips to an external API.

Where it failed, and why it's worse than a hard error:

• iframes — Skills couldn't consistently target elements inside cross-origin iframes. The captcha modals on the tax portal and two supplier portals open inside iframes. Skills would report the form as filled, but the captcha was never completed.
• Rotating session tokens — Two bank portals put a CSRF token in the URL that changes on every navigation. Skills would capture the token, fill the form, submit, and get a 403 because the token had already rotated.
• Silent failures — This is the real problem. When Skills fails mid-form, it doesn't throw an error. The agent reports success, marks the job as done, and moves on. Your client thinks the tax filing went through. It didn't.

# The silent failure pattern that makes Skills dangerous:
async def fill_portal_form(page, data):
    await page.skills.fill("#company_name", data["company_name"])
    await page.skills.fill("#tax_id", data["tax_id"])
    await page.skills.click("#submit_button")

    # Skills reports True even if the iframe captcha was never solved.
    # The agent logs this as success. The filing never landed.
    return True  # ← This is a lie.

The lesson: if you use Skills in Chrome, wrap every action in a verification step. Don't trust the return value. Re-read the page after submission and check for a confirmation message or a success DOM node. Skills is a real tool for modern SaaS dashboards — it's actively harmful on legacy portals with iframes and session tokens.

Failure Modes By Portal Type

Built-in AI (Gemini Nano): 12/12 — Won By Refusing To Play The Browser Game

Built-in AI runs Gemini Nano locally inside Chrome, on-device. No API calls, no rate limits, no network dependency. It scored 12 out of 12 because it does something fundamentally different from the other two updates: it never touches the DOM. It doesn't click buttons, fill forms, or drive the browser at all.

The architecture that worked on every portal was dead simple: pair Gemini Nano with a boring headless scrape. The scraper grabs the raw text from the page — it doesn't need to interact with it, just read it. Then feed that text to Nano and ask for structured JSON output.

# The pattern that worked on all 12 portals:
import json
from playwright.sync_api import sync_playwright

def extract_portal_data(url, session_cookies):
    with sync_playwright() as p:
        browser = p.chromium.launch(headless=True)
        context = browser.new_context()
        
        # Load session cookies for authenticated portals
        context.add_cookies(session_cookies)
        page = context.new_page()
        page.goto(url, wait_until="networkidle")
        
        # Just grab the text. Don't click. Don't fill. Don't drive.
        raw_text = page.inner_text("body")
        browser.close()
        
        return raw_text  # Hand this to Gemini Nano

# Nano processes locally, returns structured JSON:
# {
#   "company_name": "Acme Industries LLC",
#   "tax_id": "47-1234567",
#   "vat_bracket": "standard",
#   "address": "1200 Industrial Pkwy, Suite 200, ...",
#   "portal_status": "filing_due_2026-07-15"
# }

Nano doesn't care if the page uses iframes, session tokens, or ASP.NET WebForms from 2015. It's reading text, not interacting with a DOM tree. Text is text. A supplier portal rendered in jQuery and a modern Next.js dashboard both produce human-readable text on screen, and that's all Nano needs.

Real numbers from the onboarding flow I rebuilt:

• Before: 4 minutes 10 seconds per new-client onboarding (manual data entry from portal screenshots)
• After: 1 minute 5 seconds (scrape + Nano extraction + review)
• API cost: $0 (Nano runs on the user's machine)
• Rate limits: None (it's local)
• Works offline: Yes — tested on a train with no WiFi

The 3-minute-5-second saving per client compounds fast. If you onboard 20 clients per week, that's over an hour saved weekly on a single workflow, with zero marginal cost.

The Architecture Decision: Match The Tool To The Site's Era

The agentic web only works on websites built for the agentic web. Here's the decision framework based on the test results:

If your users live on modern SaaS dashboards (React, Vue, Next.js apps with clean DOMs and stable selectors): Skills in Chrome is a real tool. Ship it. Add verification steps after every action, and don't trust silent success returns. Budget 2-3 days for the verification layer.

If your users live on government portals, bank exports, or supplier sites that predate responsive design: WebMCP and Skills will burn your weekend. Use the scrape-plus-Nano pattern instead. A headless scraper reads the page text, Nano extracts structured data locally, and you write the results to your system. No DOM interaction, no click simulation, no iframe hell.

If you're tracking WebMCP for future planning: watch adoption metrics, not keynote demos. The spec is elegant. Adoption requires a critical mass of legacy sites to voluntarily build MCP endpoints. Set a calendar reminder for mid-2027 to check whether any government or major B2B portal has shipped MCP support. Until then, it's a protocol without a footprint.

# Decision logic for a real automation pipeline:
def choose_extraction_method(portal):
    if portal.has_modern_api or portal.exposes_mcp:
        return "webmcp"  # The clean path — rare in practice
    elif portal.is_modern_spa and not portal.has_iframes:
        return "skills_in_chrome"  # Fast, but needs verification
    elif portal.has_captcha or portal.uses_viewstate or portal.has_iframes:
        return "scrape_plus_nano"  # The boring, reliable path
    else:
        return "scrape_plus_nano"  # Default to what works

What This Looks Like In Production

I run this exact scrape-plus-Nano pattern in production for a small business invoicing tool. The flow handles new-client onboarding across multiple portal types: tax authority lookups, supplier registration pages, and bank statement parsing. The scraper is a standard Playwright script running on a home server — nothing exotic. Nano runs in Chrome on the same machine. The whole pipeline completes in about 65 seconds per client, compared to over 4 minutes of manual data entry.

The silent failure problem from Skills in Chrome is the thing I'd warn most builders about. It's easy to demo a tool filling a form on a clean React app. It's hard to debug an agent that silently fails on a captcha iframe and reports success. If you're building anything that touches a government filing or a financial submission, silent failures can create legal exposure. A tax return that "submitted successfully" but didn't actually land is a regulatory problem, not a bug report.

The most honest assessment I can give: Google shipped three updates, and the one they buried deep in the keynote — Built-in AI with Gemini Nano — is the one that actually rewrote my onboarding flow. WebMCP is technically elegant but commercially irrelevant for the next few years. Skills in Chrome is a solid tool for a narrow set of modern sites. Nano wins by refusing to play the browser automation game at all.

What This Means For Small Business Automation

The tools that actually solve small business automation problems aren't the ones with the best keynote demos. They're the ones that handle the messy reality of legacy portals, inconsistent DOM structures, and authentication flows that were designed before mobile devices existed. Gemini Nano's approach — read text locally, return structured data, never touch the DOM — sidesteps every single failure mode that killed WebMCP and Skills in the test grid.

For solopreneurs and small teams evaluating AI automation in 2026: test on your ugliest portal, not on a demo site. If the tool can't handle the worst page your business interacts with daily, the demo doesn't matter.

Where bizflowai.io Fits In

At bizflowai.io, we already run this scrape-plus-local-model pattern for clients who need automated data extraction from supplier portals, tax filing sites, and bank export pages. The pipeline handles the boring part — authenticated scraping, text extraction, structured JSON output — so small teams can onboard clients and process documents without manual data entry. The same architecture that scored 12/12 in the test grid above is what powers the extraction layer in production today.

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.