I/O 2026 Killed $60 of My $180 Enrichment Bill. Not $180.
Google's I/O 2026 recap sold WebMCP, Built-in AI, and Skills in Chrome as the trifecta that would replace your enrichment vendors. I plugged all three into a live outbound engine doing 800 prospect lookups a week for two weeks. Only one of them earned a permanent slot, and the savings math is nowhere near what the keynote implied.
The setup: 800 lookups/week, $180/month, two vendors
The outbound engine we run for lead-gen clients pulls roughly 800 prospect lookups a week across three data types: company firmographics, contact enrichment, and tech stack detection. That layer costs $180/month split across two providers — one for firmographics + contact, one specialized for tech stack. Not catastrophic, but it's the kind of recurring line item you kill on principle when a browser vendor tells you their new features replace it for free.
The workflow runs on a home server, WSL Ubuntu, nine parallel Chrome workers driven by Playwright. Each worker takes a queue of domains and produces a normalized JSON record. Cost per lookup pre-test was about $0.056 blended across the two vendors. The plan was straightforward: swap each vendor call for the corresponding I/O 2026 feature, measure quality and cost, keep what survives two full billing cycles.
Here's what the actual pre-test call graph looked like per lead:
domain_in
→ firmographics_api ($0.03)
→ contact_enrichment_api ($0.02)
→ tech_stack_api ($0.006)
→ normalize + dedupe
→ CRM
Three line items. Three theoretical replacements from Google. Let's take them one at a time.
Test 1: WebMCP replaced exactly $0 of the bill
WebMCP is the most conceptually clean of the three. Vendor sites expose structured MCP endpoints, your agent hits them directly, no scraping, no CSS selectors that break when someone redesigns the pricing page. When it works, it's the best possible enrichment surface: sub-second responses, typed JSON, zero parsing tax.
The problem is coverage. Of the domains that flow through our prospect queue in a normal week, roughly 12% ship a functional MCP surface today. Almost all of that 12% is dev-tool companies, a handful of API-first SaaS vendors, and a few consultancies that shipped an MCP endpoint the week after the keynote as a marketing move. The remaining 88% — mid-market manufacturers, agencies, professional services firms, regional distributors, the actual ICP for most B2B outbound — have nothing to talk to.
What the coverage log actually showed
- 800 domains queried over week 1
- 94 responded to an MCP probe (11.75%)
- 71 returned a usable structured record (8.9%)
- 0 dollars saved, because we still had to hit the paid API for the other 91%
WebMCP assumes a web that doesn't exist yet. In 18 to 24 months it might be the default for enterprise SaaS, and at that point the enrichment vendor category gets genuinely disrupted. Today, if you're prospecting into anything that isn't a Series B dev tool, it replaces zero dollars of your bill. I set a Q3 calendar reminder to re-run the coverage probe and moved on.
Test 2: Built-in AI hit the quota wall on day three
Built-in AI is Gemini Nano running on-device inside Chrome. The pitch is real: no API line item, no network latency, no per-token billing. I wired it into the pipeline as the summarization step — scrape the landing page and the about page, hand the raw text to Nano, get back a structured company profile with industry, size heuristic, positioning, and buying signals.
For the first day it was genuinely impressive. Latency landed at 400 to 600ms per call. Quality against my human-labeled ground truth set (200 records I'd graded manually) came out at 78% field-level accuracy — good enough for the top-of-funnel scoring we use it for. If those numbers held at 800 lookups a week, I'd have killed the contact enrichment vendor immediately and saved $60/month right there.
They didn't hold. On day three, workers started reporting 3 to 5 second latencies and then outright failures. The Built-in AI API throttles per-origin per-day, and the ceiling landed somewhere around 200 successful calls per worker per day in our measurements. The throttle behavior isn't documented in any of the recap coverage I've seen, and Google's own docs are vague about the exact number. What is clear is that it's not sized for parallel-worker workloads.
The math that killed it
- 9 parallel workers × 200 daily calls = 1,800 calls/day ceiling
- 800 lookups/week ÷ 5 working days = 160 lookups/day baseline
- But retries, multi-page enrichment (landing + about + pricing), and re-runs push actual calls to ~4x lookup count
- Effective demand: ~640 calls/day → fine on paper, but throttle applies per-origin and workers share origins during batch runs, so the effective ceiling collapses
We kept Built-in AI for a low-volume research sub-slice — deep dives on ~40 enterprise accounts a month where latency doesn't matter. That saved about $15/month against the contact enrichment provider. Real, but not the win the keynote implied.
Here's the 30-line logger that caught the wall on day three instead of day thirty:
import time, json, pathlib
from datetime import datetime
LOG = pathlib.Path("browser_feature_log.jsonl")
def log_call(feature, domain, worker_id, fn):
start = time.perf_counter()
quota_hit = False
error = None
result = None
try:
result = fn()
except Exception as e:
msg = str(e).lower()
if "quota" in msg or "throttle" in msg or "429" in msg:
quota_hit = True
error = msg[:200]
latency_ms = int((time.perf_counter() - start) * 1000)
LOG.open("a").write(json.dumps({
"ts": datetime.utcnow().isoformat(),
"feature": feature,
"domain": domain,
"worker": worker_id,
"latency_ms": latency_ms,
"quota_hit": quota_hit,
"error": error,
"ok": result is not None,
}) + "\n")
return result
Point it at your JSONL file, jq over it end of day, and you have per-feature quota-hit rates before the illusion costs you a sprint.
Test 3: Skills in Chrome — the boring one that survived
Skills in Chrome let you package a research playbook as a reusable artifact: URL patterns to visit, fields to extract, branching logic ("if a /technology or /stack page exists, follow it; else fall back to header sniffing"), and fallback heuristics. It's not a model announcement. There's no demo reel. Nobody in the keynote coverage benchmarked it against a real workload, which is probably why it's the only one that survived 800 lookups a week.
The tech stack detection playbook is a good example. Our paid vendor for that costs $50/month and returns a JSON payload of detected frontend, analytics, CDN, and marketing stack. The Skill version does roughly the same thing: visits the domain, sniffs headers, reads the built.with-style meta tags, follows a /technology page if it exists, and falls back to a script-tag pattern match. It's not more accurate — it's 91% agreement with the paid vendor on a 500-domain sample — but at that agreement rate, the delta doesn't affect any downstream lead scoring.
The pseudocode of the actual Skill (simplified):
name: tech_stack_detect
inputs: [domain]
steps:
- visit: "https://{{domain}}"
- extract:
headers: response.headers
scripts: "script[src]"
meta_generator: 'meta[name="generator"]::content'
- branch:
if: "exists('/technology') or exists('/stack')"
then:
- visit: "https://{{domain}}/technology"
- extract: { stack_list: "li, .tech-item" }
else:
- heuristic: match_script_patterns(scripts)
- normalize: { schema: tech_stack_v1 }
- return
What Skills actually delivered over two billing cycles
- Tech stack vendor: killed entirely, $50/month saved
- Contact enrichment vendor: partial replacement on ~40% of domains (the ones with clean /team or /about pages), ~$10/month saved
- Research time per lead: down 34% because the branching logic replaces a human review step we used to trigger on ambiguous stacks
- Total real savings: $60/month, verified against two full monthly invoices
Skills is where the agentic web earns money for small teams today. It converts tribal research knowledge — the mental checklist your best SDR uses when qualifying a domain — into an artifact your automation can execute at 800/week without complaint.
The honest scoreboard and the three numbers to measure first
One of three features kept. $60/month saved, not $180. If you're a solo founder doing 20 lookups a week, all three might feel like magic — the quota wall never bites and the WebMCP coverage gap doesn't matter because you're prospecting into whatever domains you feel like on a given Tuesday. At agency volume, only Skills survives.
Before you replace any paid API line item with a browser-native feature, measure three numbers in an afternoon:
- Per-origin quota — how many calls per day before throttling kicks in
- Per-worker parallelism ceiling — how the throttle interacts with concurrent workers sharing an origin
- Target-domain coverage — what percentage of your actual prospect list supports the feature at all
Those three numbers tell you whether a keynote announcement is a real cost cut or slideware. The 30-line logger above is the tool. Run it for 72 hours before you plan a migration, not after.
The hot take, briefly: the most valuable I/O 2026 announcement for operators isn't WebMCP or Nano. It's Skills, and Google under-marketed it because it doesn't showcase a model. Flashy features matter in 18 months. Boring, deterministic, versionable playbooks pay this quarter. For further reading on how to size these calls before you migrate, Google's own Built-in AI origin trial docs are the closest thing to a real quota reference, and even those are vague about parallel-worker behavior.
Where bizflowai.io fits into this
Most of the outbound automation we build for clients at bizflowai.io lives exactly in this seam — the boring, deterministic enrichment layer between "we have a list of domains" and "the SDR sees a scored lead in the CRM." That's where Skills-style playbooks, quota-aware workers, and honest cost logging replace vendor line items without breaking when someone's about page changes. We don't sell the keynote version of automation. We ship the version that survives past 200 lookups.
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.
Top comments (0)