¿Qué es el uso de computadoras y por qué es importante? El uso de computadoras es una idea sencilla con amplias implicaciones: en vez de pedir a los modelos que respondan preguntas, les pedimos que operen software de forma autónoma, navegando por sitios web, llenando formularios, recorriendo flujos de trabajo y completando tareas de principio a fin.
Esto permite realizar una amplia variedad de tareas del mundo real que hoy están fragmentadas entre distintas interfaces, como reservaciones completas, procesos de compra en comercio electrónico, planificación de viajes en varios pasos y flujos administrativos sin un equivalente claro mediante API. Estos problemas no son nuevos. Lo novedoso es que ahora resulta viable resolverlos con modelos de propósito general.
Sistemas recientes de Anthropic y OpenAI han demostrado que los agentes no solo pueden actuar, sino también razonar sobre el estado, recuperarse de errores y crear sobre la marcha soluciones específicas para cada tarea. Esto convierte al navegador en un entorno de ejecución general para agentes, pero plantea de inmediato una pregunta de diseño: ¿qué proporción de ese entorno debemos exponer al modelo?
Los primeros sistemas respondieron encapsulando el navegador en un conjunto fijo de acciones seguras y predefinidas. Como argumentaremos en esta publicación, ese enfoque está llegando a su límite.
Al crear agentes para navegadores, suele surgir un impulso conocido: no confiar demasiado en el modelo.
Por eso encapsulamos el navegador. Exponemos herramientas predefinidas como click, type, scroll, select y read_text. Simplificamos el modelo de objetos del documento (DOM). Reducimos el espacio de acciones. Intentamos que el comportamiento sea comprensible y controlable mediante abstracciones diseñadas por nosotros.
Es un punto de partida razonable. Pero también es, cada vez más, la arquitectura equivocada a largo plazo.
A medida que mejoran los modelos de vanguardia, la limitación ya no es solo que el modelo carezca de herramientas. El problema es que lo obligamos a operar mediante abstracciones que eliminan demasiados detalles del sistema subyacente. Comprimimos un entorno dinámico y complejo en una interfaz fija de acciones, y luego le pedimos al modelo que se desempeñe bien pese a esa pérdida de información.
Esta concesión resulta cada vez menos conveniente.
El cambio que hemos estado explorando es fácil de describir, pero tiene consecuencias importantes. En lugar de tratar al agente como un selector de acciones predefinidas, lo tratamos como un sintetizador de programas que opera dentro de un entorno de ejecución restringido.
Los modelos se volvieron muy buenos y ya no necesitan barreras de seguridad abstraídas: necesitan todo el espacio de acciones para diseñar, ejecutar e iterar la tarea hasta alcanzar su objetivo.
Esta publicación aborda ese cambio, desde la automatización de navegadores cargada de abstracciones hasta el uso restringido de computadoras, y explica qué cambia cuando los sistemas se diseñan de esta manera.
El problema no es que las interfaces de acciones fijas sean conceptualmente incorrectas. El problema es que la web no se adapta a ellas.
Las interfaces modernas se crean con React, Vue y Angular, e incluyen actualizaciones de estado asíncronas, sistemas de eventos sintéticos y widgets de terceros integrados que se ejecutan en iframes de origen cruzado con sus propios ciclos de vida. Un envoltorio que indica “escribe en este campo” solo funciona si la página coincide con su definición de escribir. Muchas no coinciden. Establecer un valor directamente suele eludir por completo la detección de cambios del framework. El campo parece estar lleno. La validación nunca se activa. El formulario sigue sin funcionar.
Esto se puede parchear. Se pueden agregar casos especiales para los campos de React, emitir eventos blur después de focus y esperar a que no haya actividad de red antes de leer el estado. Cada parche es correcto en su contexto específico. En conjunto, se acumulan hasta formar un sistema cada vez más difícil de mantener y más específico para los sitios que ya se conocen.
El problema de fondo es que se incorporan en la capa de abstracción supuestos sobre cómo deberían funcionar las interacciones, para luego descubrir que la web funciona bajo otros supuestos.
Consideremos un formulario de pago integrado mediante Stripe o Adyen dentro de un iframe de origen cruzado. El envoltorio no puede acceder directamente porque se encuentra en un origen diferente. La herramienta read_text no puede observar su estado interno. La herramienta type no puede interactuar con sus campos. Un agente basado en envoltorios llega aquí a un callejón sin salida. La abstracción se diseñó para el documento principal. La tarea real está en un lugar que la abstracción no puede ver.
Un desajuste similar aparece en flujos menos evidentes. Es posible que un menú desplegable controlado por un framework no responda en absoluto a los clics directos, porque el elemento visible no es el control real. Puede requerir una secuencia de eventos de teclado para activar la transición de estado subyacente. Desde fuera, parece que se puede hacer clic en la interfaz. La abstracción indica “haz clic”. No ocurre nada.
O consideremos un flujo modal de varios pasos en el que las actualizaciones visibles del DOM se retrasan respecto de los cambios de estado internos. La siguiente acción correcta depende de una transición de estado que todavía no se refleja en los elementos visibles para el envoltorio. Un agente basado en envoltorios termina actuando demasiado pronto o leyendo un estado obsoleto porque opera con una visión incompleta del sistema.
En cada caso, la abstracción oculta las señales que el agente realmente necesita.
Un modelo que opera en un nivel inferior —inspeccionando el DOM activo, razonando sobre los límites entre marcos y sintetizando la secuencia de interacción para esa interfaz específica— puede resolver estas situaciones. No se debe a que el modelo sea intrínsecamente más inteligente. Se debe a que tiene acceso a la información que antes se había eliminado.
El cambio que buscamos es fácil de describir: en vez de pedir al modelo que seleccione acciones predefinidas, le ofrecemos una interfaz de ejecución de menor nivel y la restringimos mediante políticas de ejecución, no mediante el diseño de abstracciones.
Esta decisión de diseño surge de un cambio más amplio en la industria, que comienza a favorecer herramientas primitivas de menor nivel: herramientas que aprovechan la capacidad innata del agente para corregirse durante la ejecución y producir código de alta calidad, en lugar de herramientas específicas y rígidas que son robustas, pero eliminan la capacidad del modelo para adaptarse a distintos entornos.
Consideremos el éxito de Claude Code como una opción principal en las herramientas de muchos desarrolladores y el giro general de la industria hacia los agentes basados en terminales. La mayor ventaja de Claude Code no es el modelo en sí, sino el arnés de ejecución de menor nivel. Dar al modelo menos herramientas, pero más modulares y de menor nivel, es decir, la terminal, mejora el rendimiento al invocar herramientas, principalmente porque el agente puede razonar y crear scripts personalizados para la tarea en cuestión, en vez de intentar usar herramientas generalizadas que saturan la ventana de contexto.
En la práctica, para automatizar navegadores, esto significa que el modelo puede inspeccionar directamente el estado activo de la página, recorrer marcos y crear código de interacción personalizado para la interfaz actual, en lugar de representar todo mediante un conjunto fijo de acciones prediseñadas.
El modelo se comporta menos como un selector y más como un autor de lógica de ejecución. Inspecciona el estado actual, razona sobre la interfaz y sintetiza la lógica de interacción para esa situación específica. Puede crear secuencias de varios pasos, adaptarse a flujos inusuales y validar los resultados antes de continuar. Cuando una acción falla, el modelo ve el error subyacente y se corrige por sí mismo. Esto es más potente y más riesgoso, pero se acerca mucho más a la verdadera naturaleza del problema.
Es importante señalar que eliminar la capa de abstracción no reduce el rigor del sistema. Solo traslada ese rigor.
El trabajo que antes se hacía en el diseño de envoltorios y la gestión de casos extremos se traslada a tres lugares: el prompt, que se convierte en una forma de capacitación operativa; el entorno de ejecución, que aplica límites como el alcance de navegación, las acciones sensibles y el comportamiento de los reintentos; y la capa de evaluación, que determina no solo si la tarea tuvo éxito, sino también si los pasos intermedios fueron correctos. Menos abstracciones frágiles. Sistemas circundantes más sólidos.
Una consecuencia de este cambio es que el código del producto suele simplificarse, aunque el sistema en su conjunto adquiera más capacidades. En lugar de codificar patrones de interacción como envoltorios reutilizables, el agente sintetiza el comportamiento durante la ejecución. Se mantiene un conjunto reducido de primitivas potentes y un entorno de ejecución restringido, en vez de una gama creciente de herramientas especializadas y lógica para casos extremos.
Esto también cambia la forma en que el sistema generaliza. Un agente basado en envoltorios generaliza bien a tareas similares a aquellas para las que ya se crearon envoltorios. Un agente con un entorno de ejecución restringido generaliza a tareas que comparten una misma base de ejecución, aunque la interfaz visible sea diferente.
Por ejemplo, interactuar con un formulario de búsqueda, un flujo de reservación o una página de configuración puede parecer completamente distinto en la interfaz de usuario. Pero, en esencia, comparten patrones: leer el estado, activar eventos, validar resultados y gestionar actualizaciones asíncronas. Un sistema que opera en ese nivel se adapta con mayor naturalidad a distintas tareas.
El componente reutilizable no es la lista de acciones, sino la capacidad del modelo para inspeccionar el estado, actuar de forma segura y verificar los resultados.
La lección más clara de este trabajo es que la confiabilidad no se logra proporcionando más funciones auxiliares al modelo. A menudo se logra dándole menos primitivas, pero más potentes, y restringiéndolas de la manera adecuada. La ayuda excesiva incorpora en el código supuestos rígidos sobre cómo debe realizarse una tarea. Las restricciones definen límites operativos seguros y permiten que el modelo descubra mejores soluciones locales.
Una interfaz de ejecución más potente también exige un modelo de seguridad más riguroso. Cuando el agente deja de estar limitado a un conjunto reducido de acciones predefinidas, en la práctica opera directamente sobre software real. Esto cambia de inmediato el perfil de riesgo.
El diseño debe abordar cuatro aspectos:
Exposición de datos. Si el agente interactúa con interfaces reales, a menudo encontrará información confidencial. Esto exige un enfoque riguroso para el enmascaramiento y el control de acceso. Los datos solo deben revelarse cuando sean necesarios para la ejecución, y los registros y rastros deben manejarse con cuidado para evitar que la observabilidad se convierta en la parte más sensible del sistema.
Alcance de la ejecución. Un agente potente no debe poder operar sin límites. En la práctica, esto implica restringir por dónde puede navegar, a qué dominios puede acceder y con qué sistemas tiene permitido interactuar. Estas restricciones deben aplicarse en el entorno de ejecución, no quedar como simples convenciones en los prompts.
Confianza en el entorno. Las interfaces modernas pueden incluir instrucciones, contenido o flujos engañosos o directamente maliciosos. La inyección de prompts mediante el contenido de una página es una superficie de ataque real. El sistema necesita una jerarquía clara de instrucciones, comprobaciones de validación y condiciones de finalización para evitar que el agente siga indicaciones no deseadas.
Espectro de autonomía. No todas las acciones deben ser completamente autónomas. En muchos entornos de producción, es importante considerar la autonomía como un espectro. El sistema puede tener un alto grado de autonomía al explorar y ejecutar, pero seguir requiriendo aprobación para ciertas categorías de acciones.
El principio subyacente es sencillo: dar más poder al modelo exige reforzar el sistema que lo rodea. La autonomía sin políticas no está lista para producción.
Dejamos de preguntarnos: ¿cuáles son las acciones adecuadas del navegador que debemos exponer?
Empezamos a preguntarnos: ¿cómo podemos ofrecer al modelo un espacio de acciones completo y crear a su alrededor políticas de ejecución que mantengan la seguridad?
Ese replanteamiento cambia las prioridades. Las taxonomías de acciones y la exhaustividad de los envoltorios importan menos. Las políticas de ejecución, la observabilidad y la evaluación de cada paso importan más. La capacidad del modelo y el diseño del sistema no se sustituyen entre sí. A medida que los modelos mejoran, el trabajo del sistema se vuelve más importante, no menos.
Los agentes para navegadores que funcionan en demostraciones suelen tener éxito porque la tarea es acotada y el entorno coopera. Los sistemas de producción requieren algo distinto: ejecución restringida, comportamiento instrumentado y una evaluación capaz de distinguir un resultado correcto de uno afortunado.
Menos diseño de envoltorios. Más ingeniería de sistemas.
Y aunque nos enfocamos en los agentes para navegadores, esto apunta a una forma más amplia de entender el uso de computadoras como una disciplina de sistemas.