Microsoft Research soltó Webwright esta semana — un framework de web agent que tira el DOM-clicking y la predicción de coordenadas sobre screenshot a favor de hacer que el agente escriba código Playwright dentro de un terminal. La apuesta arquitectónica: tratar el browser como una herramienta lanzable, no una sesión stateful. El agente recibe contexto, retorna código y razonamiento, ejecuta vía un Terminal Environment, e incorpora las observaciones (logs, screenshots, valores de retorno) de vuelta al contexto. Tres componentes, unas 1000 líneas total: Runner a ~150 LOC orquesta el loop, Model Endpoint a ~550 LOC maneja la interfaz LLM, Terminal Environment a ~300 LOC ejecuta todo. Single agent loop, sin orquestación multi-agente. Para los builders que han visto la browser-agent stack acumular wrappers DOM estilo Operator y pipelines de screenshots, este es el movimiento de minimalismo arquitectónico.

Benchmarks: Odysseys (browsing multi-sitio long-horizon, tareas promediando 272.3 palabras) — GPT-5.4 base 33.5%, Webwright sobre GPT-5.4 lo lleva a **60.1%** (79.4% mejora relativa). El SOTA previo en Odysseys era Opus 4.6 a 44.5%, establecido en abril 2026. Claude Opus 4.7 con Webwright completa tareas en menos pasos (media 21.9 vs 26.3) pero a $6.09 por tarea versus $2.37 de GPT-5.4 — el tradeoff costo/paso es real y explícito. Online-Mind2Web (300 tareas, 136 sitios): Webwright+GPT-5.4 alcanza 86.67% de accuracy. Qwen3.5-9B con scripts de herramientas pre-construidos: 66.2% en el split duro. Caveats de ingeniería que Microsoft documenta honestamente: los modelos declaran "done" prematuramente sin terminar, mitigado con self-reflection más fresh-folder validation más juicio explícito éxito/fallo; explosión de contexto en trayectorias largas, mitigado con compactación de historial cada 20 pasos.

Lectura ecosistema: este es el segundo release mayor de browser-agent en quince días tras la propia familia Fara1.5 de Microsoft (modelos 4B/9B/27B). Fara era el lado del modelo; Webwright es el harness. Los dos representan una postura coherente — mantener la superficie del modelo mínima y dejar que el código Playwright (la lib de automatización de browser de Microsoft, originalmente para testing) cargue el vocabulario de acción. Es una apuesta diferente al Operator de OpenAI (percepción DOM-tree, coordenadas de click) y al Antigravity 2.0 de Google (browser-como-runtime). Para los builders, la implicación es concreta: si has escrito harness custom de DOM-scraping o lidias con la predicción screenshot-a-coordenada, el path Playwright-code-as-action-language ahora tiene una baseline publicada que supera el SOTA previo por 15.6 puntos absolutos en Odysseys. Repo: github.com/microsoft/Webwright. Ship con un Claude Code skill — sin clave LLM separada más allá de una suscripción Claude, con paths de instalación project-scoped o user-scoped.

Lunes por la mañana: si shippas un producto web-agent, clona el repo y corre el split Odysseys contra tu harness actual — la comparación apples-to-apples es lo que te dice si tu DOM-walker hace trabajo real o si un generador de código Playwright en el mismo modelo base lo haría mejor. El presupuesto de 1000 LOC hace ese test barato de setup. Si prototipas web agents desde cero, la shape Webwright (Runner / Model Endpoint / Terminal Env) es una descomposición de partida razonable — suficientemente pequeña para leerse en una tarde, suficientemente estructurada para extenderse. El tradeoff costo/paso con Opus 4.7 también vale la pena modelar explícitamente en tu presupuesto: $2.37 vs $6.09 por tarea con Opus puede o no valer la reducción de 4.4 pasos según lo que tu agente realmente está pagado por hacer.