Qué es Stagehand: el SDK de agentes de navegador que quitó su función de agente

Stagehand es una librería de código abierto (MIT) de la empresa Browserbase que sirve para que un programa, normalmente un agente de IA, controle un navegador Chrome usando instrucciones en lenguaje natural en lugar de selectores CSS. Su versión 4, publicada el 10 de agosto de 2026, es una reescritura completa: deja de depender de Playwright y mueve su motor dentro del propio navegador, como extensión de Chrome. Y hace algo que casi nadie ha contado: elimina el método agent(), la primitiva que permitía lanzar un agente autónomo.

Sí, el SDK que se anuncia como "the SDK for browser agents" es el mismo que ha borrado su función de agente. No es una contradicción de marketing: es una decisión de ingeniería defendible, y explicarla bien es la mitad de este artículo.

Aviso de desambiguación. Si has llegado buscando otra cosa: stagehand en inglés significa tramoyista o técnico de escenario. También hay un personaje en el videojuego Don't Starve Together, un software de Pioneer DJ y una app de música en directo con ese nombre. Este artículo va del SDK de programación.

Cómo hemos verificado esto. Datos comprobados el 13 de agosto de 2026 contra fuente primaria: el repositorio de GitHub, los paquetes publicados en npm y PyPI (incluido el contenido del tarball), la guía oficial de migración, el blog de ingeniería de Browserbase, la API de Hacker News y las páginas de precios de cada producto citado. No hemos ejecutado Stagehand en producción: cuando describimos comportamiento, describimos lo que dicen el código y la documentación. Los precios cambian: compruébalos antes de contratar.

¿Qué problema resuelve Stagehand?

Automatizar un navegador siempre ha funcionado igual: le dices al programa exactamente qué elemento tocar. page.click("#submit-button"). Funciona perfecto hasta que alguien cambia el id, y entonces se rompe.

Para un test automatizado eso está bien: si la página cambió, quieres enterarte. Para un agente de IA es un desastre, porque el agente no conoce el HTML de antemano y no puede predecir los selectores.

Stagehand propone lo contrario: decirle qué quieres conseguir en lenguaje natural, y que él averigüe el elemento. Tres primitivas:

La idea de fondo es que puedes mezclar: usar código determinista donde la página es estable y barata de recorrer, y lenguaje natural solo donde hace falta. Eso es lo sensato, y es su mejor argumento.

¿Qué es exactamente la versión 4?

Aquí está el cambio de verdad, y no es ninguna de las tres cosas que anuncia el tuit de lanzamiento.

En la v3, Stagehand era una capa sobre Playwright. Su package.json declaraba playwright-core como dependencia, más puppeteer-core, patchright-core y dieciseis dependencias opcionales de proveedores de IA.

En la v4, Playwright ha desaparecido. El paquete tiene cinco dependencias y ninguna es Playwright ni un proveedor de modelos. El paquete pasa de 1.174 ficheros y 10,1 MB a 16 ficheros y 3,37 MB.

¿Dónde se fue el motor? Dentro del navegador. Stagehand v4 instala una extensión de Chrome (Manifest V3) llamada Stagehand Runtime que vive como service worker. El SDK y la extensión hablan por JSON-RPC dentro de la conexión CDP que ya estaba abierta, sin abrir un segundo puerto.

Y esa es la explicación honesta del ahorro de tokens. En la v3, para saber qué hay en la página, había que serializar el árbol de accesibilidad, mandarlo por la red y podarlo fuera. En la v4 la poda se ejecuta dentro de la extensión, contra el árbol vivo. Al no arriesgarse a trabajar sobre una copia obsoleta, pueden podar mucho más agresivamente. Menos árbol enviado al modelo, menos tokens.

Es un argumento técnico real y se puede explicar en una clase. Es mucho mejor que el eslogan.

La API sigue pareciendo Playwright

goto, click, locator, screenshot… la ergonomía se mantiene, pero por debajo habla CDP directo. Un efecto secundario simpático: Bun funciona sin avisos, precisamente porque ya no hay Playwright debajo.

¿Por qué han eliminado agent()?

La guía oficial de migración de v3 a v4 lo dice sin rodeos: agent() desaparece y nada en la v4 lo sustituye uno a uno. El orquestador que venía incluido se va y el control de flujo vuelve al programador.

El motivo que da Browserbase es simple: cada paso de aquel agente era una llamada de inferencia. Caro, lento y difícil de depurar.

Lo que recomiendan en su lugar son dos patrones:

Modo código. Que un asistente de programación escriba un script de Stagehand, y tú ejecutas ese script. La inteligencia se gasta una vez, al escribir; la ejecución es determinista y repetible.

Llamada a herramientas. Exponer al modelo toda la superficie de la API como herramientas discretas, en lugar de tres herramientas amplias.

Hay un aviso en su documentación que merece leerse dos veces, y vale para cualquier automatización con agentes:

Escala los reintentos sobre observe(), nunca sobre act(): un act() fallido puede haber pulsado, enviado o pagado antes de que el error aflorase.

Nuestra lectura: eliminar agent() es probablemente correcto y va en la dirección que está tomando todo el sector: usar el modelo para escribir la automatización, no para ejecutar cada paso. Pero anunciar como "el SDK para agentes" la versión que quita la primitiva de agente es, cuando menos, un titular desafortunado.

Los números del anuncio, contrastados

Aquí hay que ser preciso, porque la cifra que circula no es la que publica su propio equipo de ingeniería.

Lo que dice la web: v4 es "2x más rápido que Playwright" y un "80% más eficiente en tokens".

Lo que dice su blog de ingeniería, el mismo día: 1,59x en un único rastreo de 50 acciones sobre Wikipedia: 14.221,7 ms frente a 22.650,3 ms. Y añade un descargo explícito: hay que tratarlo como una sola ejecución, no como un benchmark.

Tres matices más, todos de la propia fuente:

• La medición usa comandos por lotes, una función que ese mismo post califica de experimental.
• Ninguna de las 50 acciones invoca a un modelo de IA. Es una comparación de fontanería de red, no de capacidad agéntica.
• El propio texto reconoce que la ventaja se reduce si el navegador corre en tu portátil en lugar de en la nube.

No existe ninguna medición independiente. Si ves el "2x" repetido por ahí, viene de la portada del fabricante, no de su laboratorio.

El "self-healing" no es nuevo, y ahora viene apagado

El tuit lo presenta como una de las tres novedades. Contrastado en el código:

• Ya existía en la v3, y allí venía activado por defecto.
• En la v4 es una opción booleana selfHeal que viene desactivada por defecto en el servicio de acciones.
• No es reparación mágica de selectores: es un único reintento que vuelve a capturar el árbol de accesibilidad y re-infiere la acción con el modelo.
• Se desactiva a propósito al reproducir acciones cacheadas y dentro de lotes.

Y hay un dato incómodo que publica la propia empresa: un pull request suyo, fechado trece días antes del lanzamiento, reconoce que la v4 se desarrolló sin esa función y publica sus números internos: 93,89% de acierto en v3 frente a 78,83% en v4 en su evaluación de acciones.

Combínalo con su propio aviso sobre no reintentar act(), y la conclusión práctica es: si vienes de la v3, mide antes de migrar.

Dónde gana de verdad (y esto sí es nuevo)

Quitado el ruido, quedan dos ventajas sólidas que casi nadie ha contado.

1. Iframes fuera de proceso, iframes anidados y Shadow DOM cerrado. page.locator() cruza fronteras de iframe con notación de saltos:

page.locator('iframe#checkout >> button.submit')

Encadenables tantos como anide la página, y resuelve XPath profundo del tipo /html/body/iframe[2]//div. Y cubre shadow roots en modo cerrado, que es donde Playwright no entra.

Si has peleado alguna vez con un checkout metido en un iframe de terceros, sabes exactamente cuánto vale esto.

Limitación poco publicitada, en su propia documentación: la resolución de raíces cerradas depende de APIs privilegiadas que no existen en about:blank ni en URLs data:. Hay que navegar antes a una URL http/https.

2. Paridad real entre TypeScript, Python y Go. Al ser los tres clientes finos sobre la misma extensión, no hay que reimplementar la lógica por lenguaje. Stagehand es hoy la única capa agéntica seria con Go. Browser Use es solo Python; Skyvern es Python con SDK de TypeScript.

Con un pero de distribución: TypeScript y Python publicaron la 4.0.0 el 10 de agosto con dos minutos de diferencia, pero el módulo de Go no tiene ninguna versión listada en el proxy oficial a 13 de agosto. Solo aparece una pseudoversión de commit. El comando de instalación de su propia documentación todavía no funciona.

Una tabla que hay que corregir

La comparativa de la web de Stagehand marca a Playwright con un "no" en soporte de Shadow DOM e iframes. Eso no es cierto.

La documentación de Playwright afirma que todos sus locators funcionan con elementos en Shadow DOM, ofrece frameLocator, y Microsoft mantiene una batería de pruebas dedicada a iframes fuera de proceso.

La diferencia real (que la propia Browserbase describe con más precisión en otra página suya) se reduce a dos casos: las raíces de Shadow DOM en modo cerrado y el XPath que las atraviesa. Es una ventaja técnica auténtica y estrecha. No hacía falta exagerarla.

¿Cuánto cuesta?

El SDK es MIT y gratis, verificado en el fichero LICENSE del repositorio, en npm y en PyPI. Corre en local contra tu propio Chrome.

Lo que cuesta dinero son dos capas que el titular no menciona:

Y hay dos funciones que solo existen si el navegador es de Browserbase: el enrutado automático de modelos (Model Gateway) y la caché en servidor que abarata las llamadas repetidas. En local no tienen efecto.

Aviso de seguridad, de su propia documentación: las variables de act() no se comparten con el proveedor del modelo (se le pasa solo el nombre y la sustitución es local), pero con la caché en servidor activada los valores reales viajan al servicio de caché. Apaga la caché en las llamadas que lleven credenciales.

Modelos: cinco proveedores de primera clase llamables por nombre (OpenAI, Anthropic, Google, Groq, Cerebras), siempre con prefijo proveedor/modelo. Cualquier otro entra por un callback propio que corre en tu proceso con tus credenciales. Ojo: el SDK valida el nombre del modelo contra una lista de IDs conocidos antes de enviar nada, así que un modelo recién salido exige actualizar el SDK.

Requisitos: Chrome o Chromium instalado (solo motores Chromium, ni Firefox ni WebKit), Node ≥ 22.18.0 (paquete ESM puro, sin require), Python ≥ 3.11, Go 1.26.0.

¿Dónde encaja Stagehand entre todo lo demás?

Esta es la confusión más común, y el propio tuit la alimenta. Stagehand no es un agente ni un navegador: es la capa que un agente usa para tocar el navegador. Compite con Playwright, no con los agentes autónomos.

Hoy conviven cuatro capas que la prensa mezcla constantemente:

Y un quinto eje transversal: la infraestructura de navegador (Browserbase, Cloudflare Browser Run), que es dónde corre el Chrome.

La comparativa

⚠️ Ojo con Skyvern: AGPL-3.0 es copyleft fuerte. Si lo integras en un servicio, revísalo con quien lleve el tema legal.

Y aquí está su problema de distribución. Para el caso de uso "quiero que mi agente navegue", Microsoft y Google ya regalan la solución por defecto: Playwright MCP y Chrome DevTools MCP suman 85.000 estrellas entre los dos, son gratis, no tienen proveedor detrás y ya vienen instalados en Cursor, Claude Code y Copilot. Stagehand tiene que ganarse cada instalación.

¿Le importó a alguien el lanzamiento?

Conviene separar dos cosas que el tuit mezcla.

El lanzamiento de la v4 no movió la aguja. Su Show HN, publicado por un mantenedor del proyecto, sumaba 2 puntos y ningún comentario tres días después (comprobado en la API de Hacker News el 13 de agosto). Para calibrar: el primer Show HN de Stagehand, en enero de 2025, hizo 326 puntos, y Kitesurf de Cloudflare, lanzado tres días antes, hizo 220. Tampoco hay página de release en GitHub para la v4, ni cobertura en medios técnicos que hayamos podido localizar.

El proyecto, en cambio, sí tiene adopción real. 23.926 estrellas en GitHub y 1.249.587 descargas semanales en npm, con una cifra triplicada en once meses.

Dos avisos para leer bien ese millón largo: las descargas de npm incluyen integración continua, mirrors y reinstalaciones, así que son un techo y no un número de desarrolladores. Y Playwright registró 80,1 millones esa misma semana: 64 veces más.

Un detalle del propio tuit que dice bastante: 249.699 visualizaciones con solo 406 likes es un ratio del 0,16%, muy por debajo de lo normal en herramientas para desarrolladores. Pero 378 marcadores frente a 406 likes es el patrón clásico de "me lo guardo para probarlo", no de "esto me entusiasma". Interés técnico frío, no entusiasmo.

¿Cuándo usarlo y cuándo no?

Si estás aprendiendo a programar

Tres cosas que este lanzamiento enseña mejor que muchos tutoriales.

La primera: leer la guía de migración dice más que leer el anuncio. Todo lo importante de este artículo salió de comparar el package.json de la v3 con el de la v4 y de leer el documento de migración. Ni un contacto, ni acceso anticipado. Esa es una habilidad que se entrena y que te distingue del resto.

La segunda: determinista donde puedas, inteligente donde haga falta. La mejor idea de Stagehand no es la IA: es que puedes mezclar. Un click() normal cuesta milisegundos y cero tokens; un act() cuesta una llamada al modelo. Saber cuándo usar cada uno es criterio de ingeniería, y es lo que van a pagarte.

Y la tercera: los benchmarks de fabricante se leen con lupa. Aquí la web dice 2x y el blog de ingeniería del mismo equipo dice 1,59x, en una sola tirada, sin IA de por medio y con un descargo escrito. No hace falta desconfiar de nadie: basta con abrir la fuente.

Si quieres estar en la capa que diseña estos sistemas (arquitectura de agentes, orquestación, evaluación), es lo que trabaja el programa de Ingeniería de IA para desarrolladores de 4Geeks Academy. Y si estás decidiendo qué herramienta adoptar, mantenemos actualizada la comparativa de agentes de código.