Ejecución en navegador para agentes de IA: Playwright, MCP y un ejecutor seguro

Los agentes de producción ya dominan las máquinas. Pueden acceder a APIs, conectarse a servidores MCP, ejecutar código, consultar la web, abrir archivos e impartir comandos de shell. Sin embargo, una proporción sorprendente de los softwares reales solo expone algunas de sus operaciones clave a través de una interfaz de usuario basada en navegador, y ese es el vacío que la ejecución en navegador está diseñada para llenar.

Los productos de agentes más recientes mantienen un navegador o una computadora en la nube a disposición del agente. Es tentador descartar esto como otra demostración de una IA que hace clic en botones. Una interpretación más útil es desde el punto de vista arquitectónico: el navegador no es un nuevo tipo de agente, sino un nuevo entorno de ejecución.

La diferencia es importante. Si un sistema ya ofrece servidores MCP, habilidades, ejecución de código, llamadas a herramientas programáticas, entornos de pruebas aislados, búsqueda y conectores directos al backend, un navegador no debería reemplazar ninguno de esos elementos. En lugar de eso, amplía el alcance del sistema hacia áreas que no pueden abarcar de manera fiable: aplicaciones con estado, basadas en JavaScript y con autenticación, diseñadas para ser utilizadas por personas.

La búsqueda sirve para encontrar información. Las APIs y los MCP se comunican con los sistemas. El código transforma los datos y coordina las acciones. Un navegador, por su parte, gestiona la interfaz creada para las personas.

La interfaz que se olvida

Las arquitecturas de agentes suelen comenzar con capacidades estructuradas. Cuando un servicio proporciona una API REST bien organizada, un SDK o un servidor MCP, eso es casi siempre la mejor interfaz para un agente: un contrato explícito, entradas y salidas tipadas, errores más fáciles de manejar y unos límites de seguridad más claros.

A continuación viene la ejecución de código. En lugar de que el modelo llame a veinte herramientas una por una, se le permite escribir un pequeño programa que las invoque, agregue los resultados localmente, filtre los datos y devuelva una respuesta compacta. Esto es adecuado para grandes catálogos de herramientas, llamadas repetidas y flujos de trabajo con grandes volúmenes de datos. Una sandbox añade otra capa con Python, shell, archivos y, quizás, herramientas de Kubernetes o GitHub dentro de un entorno controlado. Para entonces el agente ya puede hacer muchas cosas, pero sigue suponiendo que todo lo útil está expuesto a través de interfaces legibles por máquinas.

No es así. Hay muchas herramientas que existen únicamente detrás de pantallas: paneles de administración internos, portales de proveedores antiguos, tableros de informes, sistemas de socios, bolsas de trabajo, productos de análisis, páginas de configuración de SaaS, o aplicaciones que obtienen datos reales solo una vez que se aplican varios filtros. Los datos pueden ser públicos, mientras que el estado útil es generado por JavaScript. Una persona considera la tarea trivial, pero no existe documentación alguna para la API. Ocasionalmente existe una API interna, pero es privada, inestable o intencionalmente no se brinda soporte para ella.

Ese es el verdadero caso de uso: no permitir que la IA navegue por Internet de forma abstracta, sino utilizar el navegador como interfaz de respaldo cuando la propia aplicación forma parte de la tarea.

Por qué MCP aún no lo abarca

Cada vez que surge el tema de la ejecución en el navegador, también aparece esta pregunta, y merece una respuesta directa. MCP nunca exige que el sistema destino cuente con una API; lo único que especifica es cómo un agente se comunica con una capacidad. Supongamos que la aplicación destino solo ofrece una interfaz de usuario para las personas. En ese caso, el código detrás de una herramienta MCP puede manejar directamente un navegador. El límite no es MCP, sino la falta de una interfaz estable y estructurada en el sistema destino.

El destino podría no exponer nada estructurado. Lo que haya detrás de MCP puede ser un navegador, un entorno aislado, un motor de flujos de trabajo o algo completamente distinto. Los problemas surgen cuando la aplicación no cuenta con una API pública, un SDK, integración con base de datos ni una vía programática viable para realizar la operación necesaria. MCP aún puede publicar una herramienta llamada browser_execute, pero algo detrás de ella debe operar el sistema, y eso se logra mediante la ejecución en el navegador. No son rivales: MCP puede ser el protocolo que expone la capacidad del navegador, y el navegador es la forma en que la aplicación orientada al usuario interactúa cuando no existe nada mejor.

La autenticación puede estar vinculada al navegador. MCP cuenta con su propio modelo de autorización, que incluye flujos OAuth, pero solo abarca la comunicación entre el cliente MCP y el servidor MCP. Deja intactas las reglas de inicio de sesión del sistema en el que la herramienta debe operar finalmente. Muchos portales internos, aplicaciones de proveedores y productos SaaS antiguos permiten el acceso únicamente a través de un flujo interactivo en el navegador con SSO, MFA, cookies de sesión u otro estado creado al realizar el inicio de sesión manual, sin que existan credenciales de servicio ni tokens delegados. Una herramienta MCP aún puede exponer esta funcionalidad, siempre que exista un perfil de navegador autenticado detrás de ella. El usuario inicia sesión a través del navegador, el estado de la sesión se mantiene bajo acceso controlado, y posteriormente realiza acciones bajo esa identidad. El límite lo marca el modelo de autenticación de la aplicación destino, no el de MCP.

Algunas tareas son flujos de trabajo de interfaz de usuario y no llamadas individuales. Considere el caso de “seleccionar Retail, Europa y los últimos 90 días, y luego calcular el promedio de conversión por país”. Esto podría requerir una serie de filtros, un paso de renderizado y la extracción del estado resultante, sin que haya un punto de extremo que devuelva la respuesta directamente. El navegador puede operar la interfaz y leer lo que genera la aplicación.

Las APIs estructuradas, ya sea llamadas directamente o a través de MCP, siguen siendo la primera opción siempre que estén disponibles. Son más económicas, más deterministas y más fáciles de proteger. El navegador se encarga de la parte que solo existe detrás de la interfaz orientada al usuario.

La búsqueda no es navegar

En muchos stacks de agentes, la búsqueda en la web, la obtención de datos mediante HTTP, la automatización del navegador y el uso de la computadora se agrupan como una única habilidad vaga denominada “web”, aunque se trata de herramientas diferentes.

Si se pregunta qué cambió en la última especificación MCP, probablemente basta con una búsqueda en la web. Con la URL de un artículo público ordinario, la recuperación directa puede ser suficiente. Si se pide trabajar con Salesforce, hay que utilizar su API o MCP. Si se necesita calcular estadísticas a partir de JSON, se debe usar código.

Imagínese ahora otra solicitud: abrir un panel de control público, elegir Ucrania, establecer el año en 2026, seleccionar la opción Enterprise, recorrer cada categoría y calcular el promedio de cada métrica. Un motor de búsqueda no puede realizar esa interacción, y una solicitud HTTP simple podría devolver solo la estructura vacía de la página. Los datos relevantes aparecen después de que el navegador ejecute JavaScript, envíe solicitudes del lado del cliente, actualice el estado de la aplicación y muestre el resultado.

O bien, una plataforma de empleos: elige Ingeniería en IA, trabajo remoto y Alemania, y luego cuenta cuántas vacantes mencionan RAG en la descripción. Eso no es realmente una consulta de búsqueda; se trata de un flujo de trabajo de interfaz de usuario seguido de extracción y cálculo. Aquí es donde un navegador real le proporciona al agente algo nuevo: una superficie de ejecución web con estado.

El navegador es un entorno de ejecución

Un navegador gestionado como Amazon Bedrock AgentCore Browser es una infraestructura: una sesión de navegador remoto aislada que puede controlarse de forma programática. El LLM no se comunica con él de forma mágica; tú defines el contrato entre el agente y el entorno.

AgentCore Browser expone las sesiones a través de un punto de extremo de automatización WebSocket, y bibliotecas como Playwright pueden conectarse al Chromium remoto mediante el Protocolo de Herramientas de Desarrollo de Chrome. AWS añade acciones del navegador a nivel de sistema operativo para interacciones que CDP no puede manejar adecuadamente. El navegador es un entorno de ejecución remoto y no una capa de inteligencia. Visto de esa manera, la integración se simplifica: el agente necesita una capacidad programable, y el entorno de ejecución del navegador es donde se ejecuta.

Deje que el agente escriba el código del navegador

Un navegador puede comunicarse con un agente de varias maneras. Una opción es utilizar una herramienta de alto nivel como browser_task(task="encontrar la factura más reciente"), que incluye un agente específico del navegador que lee la tarea, explora el sitio, elige qué hacer y envía un informe. Esto puede ser útil en sitios desconocidos donde es necesario descubrir el flujo de trabajo, pero es un punto de partida deficiente.

Si el modelo principal es un programador competente, un diseño más limpio consiste en que genere el programa del navegador y lo transfiera a un Ejecutor de Navegador. Una firma tan sencilla como browser_execute(code, profile_id, allowed_domains) es suficiente:

browser_execute(
    code=generated_playwright_code,
    profile_id="vendor-portal-user-42",
    allowed_domains=["portal.example.com"]
)

Al recibir la llamada, el ejecutor verifica la solicitud, luego crea (o reutiliza) una sesión aislada y conecta Playwright al navegador remoto. Ejecuta el programa y devuelve datos estructurados. El agente principal realiza sus cálculos una sola vez. Un segundo LLM que interpreta nuevamente la misma intención solo tiene sentido cuando la tarea realmente requiere exploración. Para un panel de control, catálogo o portal predecibles, esto es mejor que un agente de navegador anidado en cuanto al precio y a la facilidad de observación.

Por qué el modo de código es adecuado

Esto es especialmente importante donde ya se utiliza la llamada a herramientas programáticas. El patrón ineficiente es fácil de detectar: el modelo llama a click, obtiene un resultado, llama a screenshot, vuelve a razonar, llama a type y obtiene otro resultado. Lo que un script sencillo podría gestionar en milisegundos se convierte en decenas de llamadas al modelo.

La mejor forma de combinar patrones es mediante la agregación de herramientas: permita que el modelo escriba un programa que realice múltiples operaciones del navegador dentro del entorno de ejecución y devuelva un único resultado compacto.

page = await browser.page()
await page.goto("https://jobs.example.com")
await page.get_by_label("Category").select_option("AI Engineering")
await page.get_by_label("Location").select_option("Germany")
await page.get_by_label("Remote").check()
await page.get_by_role("button", name="Apply").click()
jobs = await page.locator(".job-card").all_inner_texts()

rag_jobs = [job for job in jobs if "RAG" in job.upper()]
return {
    "total_jobs": len(jobs),
    "jobs_mentioning_rag": len(rag_jobs)
}

El modelo escribe un programa, el ejecutor realiza docenas o cientos de operaciones deterministas en el DOM, y el agente recibe un pequeño objeto JSON en lugar de una larga secuencia de clics y capturas de pantalla.

Puede ir más allá. Un entorno de ejecución de código consciente de las capacidades puede proporcionar al programa generado un conjunto de interfaces controladas: clientes MCP, HTTP estándar, archivos, control del navegador y cálculos locales. Un único programa podría obtener cuentas de Salesforce a través de MCP, abrir un portal heredado, leer una métrica para cada cuenta, agruparlas y devolver una respuesta única.

customers = await mcp.salesforce.search_accounts(segment="enterprise")

results = []
for customer in customers:
    await browser.goto(f"https://legacy.example.com/customer/{customer.id}")
    metric = await browser.locator("#health-score").inner_text()
    results.append({
        "customer": customer.name,
        "health_score": metric,
    })
return summarize(results)

Eso no es una IA haciendo clic al azar. Es una orquestación programática que combina interfaces de máquina e interfaces humanas.

Un flujo de trabajo

Tomemos una solicitud que parece sencilla: acceder a un panel de análisis público, seleccionar “Retail”, elegir “Europa”, limitarse a los últimos 90 días y comparar cómo difieren la tasa de conversión y la retención entre los países.

El agente no debería pasar directamente a un navegador. Un enrutador de capacidades pregunta primero si existe una ruta más económica y estructurada. Si la búsqueda puede responder, se utiliza. Si la página ofrece una API estable, se llama a ella. Si la obtención directa por HTTP contiene los datos, no se inicia Chromium.

Si los valores solo aparecen después de una interacción del lado del cliente, el router elige la ejecución en el navegador. El agente principal genera un programa de Playwright, el ejecutor lo ejecuta en la sesión gestionada, espera a que la página deje de cambiar, lee los números renderizados y los devuelve como datos estructurados. A continuación, el modo de código realiza la comparación y el agente escribe la respuesta. El usuario no necesita saber que se abrió un navegador. En muchos productos, esto debería ser una capacidad de backend invisible, similar a una consulta a una base de datos o un entorno de pruebas de código.

Automatización primero, uso del ordenador segundo

La automatización de navegadores y el uso de computadoras a veces se consideran lo mismo, pero pertenecen a diferentes niveles de la estructura. Playwright y CDP se ocupan de la estructura del navegador: páginas, selectores, elementos DOM, formularios, solicitudes de red, descargas y estado. Como resultado, funcionan más rápido y consumen menos recursos, además son más fáciles de probar y de delimitar.

El uso de la computadora es visual. El modelo observa la pantalla y ejecuta acciones con el ratón o el teclado. Se vuelve necesario cuando el DOM no puede gestionar la interfaz de manera fiable: aplicaciones de tipo canvas, diálogos nativos, menús de contexto y flujos de arrastrar y soltar complejos. AWS aplica el mismo enfoque en AgentCore Browser, donde la automatización mediante WebSocket se basa en CDP, y la API InvokeBrowser brinda control a nivel del sistema operativo para aquello que CDP no puede hacer. Por lo tanto, utilice primero la automatización estructurada y recurra al control visual solo cuando sea necesario. Cuanto más abajo se encuentra el agente en la capa de implementación, mayor es su flexibilidad, pero también aumentan los costos, la complejidad y los riesgos de cada acción.

Después de recurrir al uso de la computadora, el ejecutor debe llevar a cabo un bucle de verificación cerrado, y no una cadena de acciones sin dirección. Un clic que se realiza sin errores no demuestra nada sobre la operación. Es posible que la página siga cargándose, que un modal haya absorbido la acción o que otro elemento haya capturado el clic. Después de cada paso consecuente, el sistema en tiempo de ejecución debe analizar el nuevo estado y confirmar que ocurrió el cambio esperado antes de continuar. También debe detectar acciones repetidas que no logran nada. Si el mismo paso se repite sin producir cambio, intentarlo de nuevo es incorrecto; la solución es replanificar o volver a una estrategia más estructurada.

Este bucle se basa en tres medidas de control: limitar la cantidad de capturas de pantalla que se conservan, identificar acciones repetidas que no generan cambios y aplicar niveles de permiso paso a paso.

La autenticación convierte esto en una tarea real

Los paneles de control públicos son adecuados para pruebas de concepto, pero el valor empresarial se manifiesta con aplicaciones autenticadas. Playwright ya cuenta con una sólida comprensión de los contextos del navegador y del estado de autenticación reutilizable, y AgentCore Browser añade perfiles gestionados que conservan las cookies y el almacenamiento local entre sesiones. El usuario inicia sesión una vez, el perfil se guarda y una sesión posterior restaura ese estado. Esto es útil para portales internos, sistemas de clientes, SaaS heredados y aplicaciones de proveedores donde, de lo contrario, la integración con una API requeriría ingeniería inversa personalizada o resultaría imposible.

También cambia la forma en que se modela la identidad. Un perfil de navegador es, en efecto, una identidad de ejecución con credenciales y no un objeto genérico de conveniencia. El perfil que puede acceder a un portal financiero no debería estar disponible automáticamente para cada agente o flujo de trabajo. En entornos de producción, vincule los perfiles al inquilino, al usuario, al propósito y al alcance de la política, y otorgue al agente permisos para un perfil específico en lugar de acceso general a todas las sesiones que posea el usuario.

La seguridad es más importante que la demostración

La ejecución a través del navegador es poderosa porque actúa mediante la misma interfaz que utiliza un ser humano, lo que también significa que puede cometer errores con los privilegios de una persona.

El primer límite es el ejecutor. El código del navegador generado debe ejecutarse de forma aislada, con restricciones explícitas de dominio, tiempos de espera, límites de recursos y acceso controlado a los perfiles. El modelo no debe obtener variables de entorno del host, credenciales arbitrarias ni rutas de red generales solo porque puede ejecutar Playwright.

El segundo límite es la política de acciones. Extraer métricas de una página es una acción diferente a publicar contenido, enviar mensajes, editar permisos de cuenta, borrar datos o aprobar un pago. Clasifique esos efectos secundarios fuera del modelo y controle su ejecución en la capa de ejecución.

El tercero es la inyección de comandos. Una vez que un agente lee páginas arbitrarias, todo lo que se muestra se convierte en entrada no confiable. El texto dentro de un panel de control, un correo electrónico, un banner o un documento puede parecer un comando del agente. El ejecutor nunca debe considerar el contenido en pantalla como autorización del usuario. La guía de uso de computadoras de OpenAI dice lo mismo: trate el contenido de terceros como no confiable y solicite confirmación justo antes de realizar acciones riesgosas como publicar, enviar, eliminar, cambiar permisos o transferir dinero. Eso es una cuestión de política de ejecución, no solo de ingeniería de comandos. El navegador puede observar de forma general, pero solo debe modificar el mundo a través de una política explícita.

Seguidamente viene la observabilidad. Un ejecutor en producción debe registrar la tarea solicitada, el perfil utilizado, los dominios a los que se accedió, el programa ejecutado, los archivos descargados, los efectos secundarios externos intentados y los casos en que se necesitó aprobación humana. AgentCore Browser puede ser monitoreado en tiempo real, y los navegadores personalizados permiten grabar y reproducir una sesión, lo que proporciona una base sólida para la auditoría.

Cómo se relaciona con MCP, skills y sandboxes

Nada aquí reemplaza a otra cosa. MCP y las APIs siguen siendo las opciones preferidas para las operaciones empresariales estructuradas. El conjunto de habilidades incluye procedimientos repetibles, contexto y conocimiento operativo. El modo de código sigue siendo la opción más eficiente para llamadas repetidas, agregación y transformación. Las sandboxes siguen siendo el entorno controlado para archivos, shells, Python, pruebas y cálculos intensivos. La ejecución en navegador cubre un caso aparte: operar una interfaz orientada al usuario cuando no existe un equivalente orientado a máquinas lo suficientemente fiable.

Mantén una estrategia de enrutamiento conservadora. ¿Puede una API hacer el trabajo? Úsala. ¿Puede una recuperación directa hacerlo? No abras un navegador. ¿Es necesario operar el propio sitio para obtener el resultado? Entonces la ejecución en navegador es la opción adecuada. ¿No puede la automatización estructurada completar la interacción? El uso de una computadora es el último recurso.

MCP como contrato

En la práctica, las ramas rara vez permanecen separadas. La ejecución de código, la ejecución en el navegador e incluso el descubrimiento de herramientas suelen realizarse a través de un servidor MCP. MCP no es solo la rama de la API; es el contrato mediante el cual un agente obtiene cualquier capacidad, ya sea una llamada REST, un script en entorno aislado o un Chromium remoto como base.

El empaquetado funciona bien con un servidor MCP dedicado que expone un puñado de herramientas, como execute_code, browser_execute y find_tool, en lugar de una herramienta por cada acción subyacente. La cantidad de herramientas se mantiene en tres o cuatro y no en treinta. Un modelo no necesita herramientas separadas para hacer clic, tomar capturas de pantalla o seleccionar opciones, al igual que no necesita herramientas independientes para reiniciar, escalar o revertir, cuando una sola operación con un plan es suficiente.

La portabilidad es otra razón. Un servidor puede operar detrás de un agente personalizado o conectarse igualmente a Claude, ChatGPT o cualquier cliente compatible con MCP, de modo que se pueden probar las mismas capacidades a través de una interfaz familiar sin necesidad de una segunda integración.

Mantener el ejecutor separado

Desde el punto de vista del agente, el navegador puede parecer parte del modo de código, ya que un script generado puede utilizar browser.goto() y browser.locator() junto con clientes MCP, archivos y APIs de cómputo dentro de un único entorno de ejecución lógico. En la implementación, el Ejecutor de Navegadores sigue siendo más adecuado como componente separado. Los navegadores tienen su propio ciclo de vida y riesgos: sesiones, cookies, almacenamiento local, archivos descargados, reglas de red, perfiles de inicio de sesión, estado de la página, grabaciones y efectos secundarios fuera de su sistema. Una caja de arena de código se ocupa de la CPU, la memoria, los archivos, los paquetes y los procesos. Separarlos permite que cada entorno de ejecución aplique el modelo de seguridad que mejor se adapte a él. El modo de código puede ofrecer un cliente de navegador restringido, mientras que el ejecutor gestiona la sesión remota, de modo que el modelo de programación permanece unificado y la infraestructura se mantiene dividida.

Comenzar a ser aburrido

Omite el agente de navegador autónomo universal al inicio. La primera versión útil está diseñada intencionadamente de forma sencilla: una sesión remota aislada de Chromium, un pequeño contrato browser_execute, Playwright para la automatización, una lista blanca estricta de dominios y resultados estructurados. Pruébalo en un panel público con mucho contenido JavaScript o en una aplicación de ejemplo donde puedas demostrar que el navegador supera a las búsquedas y a la recuperación de datos mediante HTTP.

Una vez que eso funcione, conéctelo al patrón programático ya utilizado para el modo de código, de modo que el agente principal genere un programa de navegador y no tenga que llamar repetidamente a herramientas de clic de bajo nivel. Luego agregue perfiles autenticados para aplicaciones internas controladas, así como políticas de acción y controles de aprobación antes de que cualquier flujo de trabajo pueda generar efectos secundarios externos. Use la visualización del uso del ordenador únicamente para interfaces que Playwright no puede manejar de manera fiable, y considere un bucle especializado entre el navegador y el agente que observe, razonee, intente nuevamente y explore solo cuando una tarea sea demasiado ambigua para que el agente principal genere un programa estable. Ese orden mantiene la arquitectura comprensible y lleva el comportamiento más costoso y menos determinista al margen, en lugar de hacerlo el estándar.

El cambio más significativo

Lo interesante no es que un LLM pueda hacer clic en un botón. La automatización de navegadores existe desde hace años. Lo nuevo es que un agente puede decidir cuándo el navegador es la plataforma adecuada, escribir el programa que lo controla, combinar el resultado con llamadas MCP y la ejecución de código para continuar, sin que un desarrollador tenga que crear una integración personalizada para cada aplicación orientada al usuario.

Las interfaces de máquina siguen siendo mejores: más fiables, más seguras y más fáciles de gestionar. Pero el mundo está lleno de sistemas que no ofrecen la operación necesaria a través de una forma sencilla, y los flujos de trabajo solían terminar con la necesidad de que una persona abriera el sitio para completar la tarea. La ejecución en el navegador desplaza ese límite. Convierte la interfaz humana en otra plataforma programable, que debe utilizarse con cuidado, aislarse de forma estricta y preferirse únicamente cuando las interfaces estructuradas resultan insuficientes.

La próxima generación de plataformas de agentes debe entenderse no como colecciones más grandes de herramientas o ejércitos de bots de navegador, sino como sistemas con varios entornos de ejecución y un enrutador que sabe cuál de ellos debe manejar cada parte de una tarea. El objetivo no es hacer que los agentes hagan más clics, sino permitirles acceder a aquellas partes del software que las APIs aún no exponen.