3,400 Cyrillic Leads Vs I/O 2026: Nano Faked 31% Of Names

By Lazar Milicevic · Published July 19, 2026 · 7 min read

Google's I/O 2026 recap made WebMCP, Gemini Nano, and Skills in Chrome sound equally production-ready. If your customer list has any non-ASCII names in it — Serbian, Greek, Arabic, Hebrew, Thai — that framing will burn you. I ran all three through a live lead-scoring pipeline on my WSL Ubuntu box: 3,400 real leads, 52% Cyrillic. Here's which one survived contact with real data, and which one silently corrupted almost a third of its output.

The test rig, exactly as it ran

The workload is a nightly lead-scoring job on a home server. It pulls contacts from a CRM, normalizes names and company domains, scores intent from public signals, and hands the top slice to a sales agent that drafts outbound emails. Batch size: 3,400 rows. Of those, 1,768 (52%) have primary fields in Cyrillic — first name, last name, company, sometimes the domain label. The rest are Latin-script English/Western names.

Same prompt across all three APIs. Same temperature (0.2). Same structured output schema. Same retry policy (2 retries on schema-validation failure, exponential backoff). The only variable was which of Google's I/O 2026 announcements was doing the reasoning step. Nothing else was rewritten between runs.

The schema looked like this:

{
  "lead_id": "string",
  "normalized_first_name": "string",
  "normalized_last_name": "string",
  "company_canonical": "string",
  "company_domain": "string",
  "intent_score": "number (0-100)",
  "reason_codes": ["string"]
}

Two things matter here. First, normalized_first_name and normalized_last_name are what actually get merged into the outbound email template. If those are wrong, a real person gets a real email addressed to someone who doesn't exist. Second, company_domain is what the sales agent uses to route the send. If that gets swapped, the email lands at the wrong company entirely.

Ground truth for accuracy came from the CRM itself — the original fields, validated against a manually-cleaned baseline of 500 rows I'd already worked through last quarter.

Gemini Nano: fast, free, and dangerous on non-ASCII

Nano on-device in Chrome is the seductive pitch of I/O 2026: sub-second latency, zero API cost, zero network hop. On the English half of the batch it delivered exactly that — 1.1 seconds per lead, clean structured output, $0 in API spend across 1,632 rows. For an English-first SaaS scoring US or UK leads, this is a genuinely useful primitive.

Then it hit the Cyrillic half.

• 31% hallucination rate on names (548 of 1,768 rows). Not off-by-a-diacritic. Invented Latin transliterations that never existed in the source.
• ~100 rows where the company_domain was swapped to match the fabricated English company name the model had already hallucinated.
• Mis-gendered pronouns in downstream email drafts, because the fake transliteration was gender-ambiguous in English.

The root cause is the tokenizer, not the model's reasoning. Cyrillic gets shredded into byte-pair fragments the on-device model treats as low-signal noise, then the decoder fills the gap with the nearest English-shaped completion. A row that came in as Милош Петровић, Комерц д.о.о. came out as Michael Peterson, Commerce LLC. It looks like a valid lead. It's a fiction.

If your sales agent auto-sends off that output, you're forwarding an email to michael@commerce-llc.com — a domain the model invented — while the actual prospect at komerc.rs never hears from you. Worse, you don't notice until a client replies asking who Michael is.

This isn't a Nano-specific defect so much as a general property of small on-device models with English-heavy tokenizer training. It applies equally to any script that doesn't share the ASCII code points: Greek, Arabic, Hebrew, Thai, Devanagari, CJK. If your data has any of it, Nano is a liability until the tokenizer gets rebalanced.

WebMCP: the sleeper of I/O 2026

WebMCP is the announcement nobody covered correctly. It lets a webpage expose tool calls that an agent invokes directly — the raw strings pass through as strings, not as tokens the model has to reconstruct. Round-trip time: 4.2 seconds per lead (network hop included). Name corruption on the Cyrillic half: zero. Not "low." Zero across 1,768 rows.

The reason is architectural. The LLM never sees the Cyrillic string as tokens it has to interpret. It sees a tool signature like normalizeContact(lead_id) and invokes it. The tool — running in your own JavaScript context, on your own server, with your own normalization logic — handles the string as opaque bytes and returns clean structured output. The model reasons about the result (an intent score, a routing decision), not about the raw characters.

Here's the shape of the pattern:

// Exposed via WebMCP to the agent
window.mcp.registerTool({
  name: "normalizeContact",
  description: "Normalize a CRM contact row. Returns canonical name and domain.",
  parameters: { lead_id: "string" },
  handler: async ({ lead_id }) => {
    const row = await crm.fetch(lead_id);
    // Native JS string ops — no tokenizer involved
    return {
      first_name: row.first_name.normalize("NFC").trim(),
      last_name: row.last_name.normalize("NFC").trim(),
      company: row.company,
      domain: extractDomain(row.email)
    };
  }
});

The agent's job shrinks to: call the tool, take the clean output, produce an intent score. That's the split that works on messy real-world data — LLM for reasoning, deterministic code for string handling. Once you internalize this, most of the "hallucination" problems on non-English pipelines evaporate, because you stop asking the model to do the one thing it's worst at.

Cost profile for the WebMCP run across the full 3,400-row batch: $4.10 in API calls (only the reasoning step hits the paid API), against ~$0.60 for the Nano run. Six-and-a-half times more expensive, and worth every cent when 31% of the cheaper run is fiction.

Skills in Chrome: great feature, wrong job for batch

Skills in Chrome is designed for human-in-the-loop work inside a live browser session. It is not built for headless batch. You can't push a 3,400-row job through it without keeping a tab open per task, and the session model assumes a human is watching. Trying to force it into a nightly cron is fighting the API.

Where Skills genuinely shined was the QA step after the batch finished. I flagged 104 rows from the WebMCP run where the intent score was borderline (45–55 out of 100), opened them in Chrome, and used a Skill that could see the CRM row and the enriched output side-by-side. The Skill surfaced the two views, let me approve or reject in one click, and wrote the decision back to the CRM. Cleared 104 rows in about 22 minutes.

That's the right job for Skills:

• Interactive review where a human is already in the loop.
• Tasks that need to see live DOM (CRM row rendered in-browser).
• Anything where the value is UX, not throughput.

Treat it as a UX feature dressed up as an API story and you'll deploy it correctly. Treat it as an agent orchestration layer and you'll fight it forever.

The real takeaway: test on your data, not the demo dataset

Before you adopt any of the three I/O announcements into a production workflow, run a 100-row sample of your actual customer data through it. Not synthetic data. Not the vendor's demo dataset. Your real names, your real domains, your real edge cases. Measure hallucination rate on the fields that matter — names, emails, company identifiers — against a known-good baseline you've manually validated.

Here's the rank order I'd give a founder shipping this quarter:

Google's I/O 2026 recap documented all three as roughly equal production stories. They're not. WebMCP is the one that lets you ship this quarter on non-English data. Nano is a headline. Skills is a UX layer.

The failure mode of skipping this test is specific and expensive: a client forwards you an outbound email addressed to a person who doesn't exist, at a company that doesn't exist, at a domain your agent invented. You find out because the reply-all chain includes the CEO. That's the day you wish you'd run a hundred-row sanity check.

Why bizflowai.io helps with this

Every non-English SMB pipeline we ship at bizflowai.io uses the LLM-for-reasoning, tool-call-for-strings split by default. The lead normalization, domain resolution, and identity matching all run as deterministic tool calls — MCP-style servers when the client's stack supports it, plain function calls when it doesn't — and the model only sees the clean output. That's why our nightly lead pipelines don't blow up on Cyrillic, Greek, or Arabic customer data: the model was never asked to tokenize it in the first place.

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.