En el I/O 2026, Google lanzó dos cosas que la mayoría de la cobertura archivó bajo “noticias varias de Chrome”. Leídas por separado, son un skills file y una API de navegador experimental. Leídas juntas, son la misma apuesta hecha dos veces — y la apuesta es sobre quién decide cómo los agentes de IA interactúan con la web.
La primera pieza, Modern Web Guidance, le enseña a los coding agents a escribir código web moderno. La segunda, WebMCP, le enseña a los sitios web a exponerse a los agentes que actúan en nombre del usuario. Un lado del handshake, después el otro. Google movió ambas piezas en el mismo keynote, y ese timing es la historia.
Qué es Modern Web Guidance, en concreto
Modern Web Guidance es un paquete Apache-2.0 — el repo GoogleChrome/modern-web-guidance — que empaqueta 128 features de la plataforma web en más de 100 use cases validados por expertos. Se instala en el agente que ya usás: Claude Code, Gemini CLI, GitHub Copilot CLI, Goose, Google Antigravity, JetBrains WebStorm, o cualquier herramienta que soporte skills vía el flujo genérico npx skills.
El problema que ataca es uno que probablemente viste pasar en tiempo real: le pedís a un agente que arme un modal y agarra un div, un stack de z-index y trescientas líneas de JavaScript — cuando <dialog>, la Popover API y CSS Anchor Positioning ya están en la plataforma desde hace rato. Los agentes recurren por defecto a los patrones que dominaban su training data, lo que significa que escriben la web de hace tres años. Parisa Tabriz, VP de Chrome, lo planteó exactamente así: agentes generando window.open y polyfills de jQuery en pleno 2026.
Cada use case no es un artículo. Es una receta estructurada — cuándo usar un feature, cuándo no, el código canónico y el modo de falla — conectada a Baseline, la clasificación de Google de cada feature web como Limited, Newly o Widely available. Declarás un target de Baseline en tu CLAUDE.md o AGENTS.md, y la guía elige automáticamente features que tu target soporta, agregando fallbacks donde no. ¿No declaraste target? Cae por defecto en Widely available.
Sobre la instalación: el camino recomendado es npx modern-web-guidance@latest install, que mantiene las skills actualizadas. Para Claude Code en particular es un flujo de plugin-marketplace — agregás GoogleChrome/modern-web-guidance como marketplace, instalás el plugin, recargás. Por debajo es una sola skill liviana (~234 tokens) que le indica al agente cómo llamar a la CLI para traer la guía correcta on demand, así que no te tira los 100 use cases en el context window de entrada.
El número con el que Google encabeza es una mejora de 37 puntos porcentuales en adherencia a best practices para un agente genérico equipado con la guía. Conviene mantenerlo en proporción: es el benchmark interno del propio Google, y Chrome mismo lo matiza como un promedio de resultados tempranos que varía según el modelo, el prompt y el proyecto. El mecanismo detrás es más interesante que el número — evals end-to-end diarios corren una tarea de control (sin guía) contra la misma tarea con guía, y las guías se revisan para maximizar la diferencia. Documentación que se autocorrige, más o menos.
WebMCP: la otra mitad
WebMCP, ahora en un origin trial de Chrome 149, corre el handshake en la dirección opuesta. En vez de enseñarle al agente sobre la web, deja que un sitio web declare sus propias capacidades como tools que el agente puede llamar.
Hoy un agente operando un sitio hace actuation — simula clicks y keystrokes, infiriendo para qué sirve cada botón y cada campo. Cada paso queda abierto a malinterpretación. WebMCP reemplaza la adivinanza con declaración: un sitio expone una tool checkout o una tool filter_results, con JSON Schemas que definen inputs y outputs, y el agente la llama directo. Hay dos APIs — una Imperativa (definís tools en JavaScript) y una Declarativa (anotás formularios HTML estándar). Angular ya tiene soporte experimental.
Las restricciones son reales y vale la pena conocerlas antes de que alguien se entusiasme. Las tools corren en JavaScript, así que se requiere una pestaña de navegador visible — no hay llamadas de agente en headless. Las APIs están gated por origin isolation y una permissions policy tools que cae por defecto en self, así que los iframes cross-origin quedan afuera salvo que se permitan explícitamente. Y la discoverability está sin resolver: un cliente tiene que visitar tu sitio para enterarse de que tiene tools, para empezar.
Dónde encaja — y dónde no
Para un equipo que envía productos web, Modern Web Guidance es la mitad de menor riesgo y mayor valor inmediato. Es agnóstico al agente, es gratis, y se mete en un workflow que ya corrés. Si tu equipo se apoya en Claude Code o Copilot para trabajo de front-end, el efecto realista son menos reviews gastados diciéndole al agente que deje de recurrir a una librería cuando existe un primitive nativo. La integración con Baseline es la parte que vale la pena gobernar de forma deliberada — declarar un target a nivel proyecto convierte “best practice moderna” de una discusión en code review en una restricción configurada.
WebMCP es el juego largo y no debería estar en un roadmap de corto plazo como otra cosa que no sea un piloto. Es un origin trial, la historia de discoverability está incompleta, y el requisito de pestaña de navegador descarta muchos escenarios de agentes en backend. Los equipos que deberían estar mirándolo ahora son aquellos cuyo producto es el destino al que se envía a un agente — booking, flujos de soporte, formularios estructurados — porque ahí declarar tools le gana a esperar que el agente lea tu DOM correctamente.
La lectura estratégica está por encima de ambos. Google está posicionando a Baseline como el control plane de lo que significa código web “correcto”, y a Chrome DevRel como el cuerpo que mantiene las recetas — a través de Claude Code, Gemini CLI, Copilot y cualquier otro agente, todos a la vez. Ese es un tipo de poder de plataforma más silencioso que enviar un agente competidor: no necesitás ser dueño del agente si sos dueño de la definición de la respuesta correcta contra la que se lo evalúa.