Vercel presenta agent-browser, un acceso ligero al navegador para agentes de IA sin MCP

Vercel ha lanzado agent-browser, una herramienta que da a los agentes de IA acceso al navegador sin las pesadas capas de MCP. La idea es simple: mostrar al modelo no todo el DOM de la página, sino una lista corta de elementos interactivos con los que puede trabajar de inmediato.

Por qué MCP se atasca

Playwright y Puppeteer no van a desaparecer: son herramientas sólidas para pruebas e2e, CI/CD y scraping predecible. Los problemas empiezan cuando se intenta dar el control del navegador a un LLM a través de MCP.

Para saber dónde hacer clic, el modelo necesita ver la página. Normalmente se envía al contexto HTML sin procesar o un árbol de accesibilidad. En las SPA modernas, esto se traduce enseguida en miles de tokens de más en cada paso y consume la memoria del agente antes de que llegue a su objetivo.

Según los datos a los que se refiere el autor del análisis, un solo clic y una captura de una página compleja pueden costar entre 15 y 200 mil tokens por paso. Eso no solo es caro, también es inestable: el modelo gasta su contexto en leer el árbol de la página, se lía con los selectores CSS y falla más a menudo con los botones correctos. Para escenarios deterministas este enfoque aún es tolerable, pero para un agente autónomo que debe orientarse rápido en la web es demasiado pesado.

Qué ha hecho Vercel

La tarea de Vercel era práctica: si un agente escribe una interfaz, debe poder abrir una página, comprobar un componente y recorrer acciones básicas en el navegador. Para ello, el equipo simplificó agent-browser y eliminó la anterior dependencia de un demonio de Node.

La versión actual es una CLI ligera en Rust que trabaja directamente con el Chrome DevTools Protocol. Como resultado, la herramienta es más fácil de ejecutar en local, más cómoda de meter en contenedores y no obliga a arrastrar infraestructura adicional de Node.

• un único binario en Rust
• comunicación directa con CDP, sin capas intermedias
• cero dependencias para Docker y entornos locales
• referencias cortas en lugar del DOM completo

La idea clave es el snapshot de elementos interactivos. En lugar de un árbol gigantesco, el agente recibe una lista compacta como button "Sign In" [ref=e1] o textbox "Email" [ref=e2], y luego trabaja con comandos cortos: abrir la página, hacer clic en @e1, rellenar el campo @e2. Este formato ocupa cientos de tokens, no decenas de miles. Para el LLM supone una carga notablemente menor y, a la vez, reduce la probabilidad de que una acción falle por un selector frágil.

Una nueva interfaz para agentes

La diferencia se ve bien en un escenario sencillo: abrir un sitio y pulsar el primer artículo. En el esquema clásico de MCP, el agente recibe primero un enorme árbol de accesibilidad, busca en él el titular correcto e intenta construir un selector CSS exacto. Cualquier cambio de maquetación, un modal de cookies o un contenedor adicional vuelven frágil ese clic.

En agent-browser el camino es más corto: open, luego snapshot, luego click sobre una ref corta. El modelo no se apoya en conjeturas sobre la estructura del DOM, sino en un mapa ya preparado de elementos interactivos.

«No uséis MCP para el navegador: ahorrad ventanas de contexto y dinero de API».

Curiosamente, Microsoft ya impulsa una idea parecida con @playwright/cli. Allí el agente también trabaja con comandos cortos y el estado del navegador se guarda fuera del contexto del modelo. Es un cambio importante para toda la categoría de herramientas agénticas: el mercado se aleja de volcar las entrañas del navegador directamente en el LLM y pasa a un esquema en el que una herramienta local mantiene el estado y entrega al modelo solo la capa mínima de control. La diferencia entre las soluciones está ahora más bien en el ecosistema: Playwright sigue siendo más pesado y el enfoque en Rust de Vercel, más minimalista.

Qué significa

La automatización del navegador para agentes de IA empieza a dividirse en dos clases. Playwright y Puppeteer clásicos siguen siendo la base para pruebas complejas y scraping, pero para la programación con agentes y la validación rápida de interfaces crece la demanda de envoltorios CLI ligeros.

La conclusión principal es sencilla: a un LLM le conviene recibir no el navegador entero, sino una capa compacta de comandos y referencias a elementos. Es más barato, más estable y más práctico en el trabajo real.