¿Qué es el uso del ordenador y por qué es importante? El uso del ordenador es una idea sencilla con amplias implicaciones: en lugar de pedir a los modelos que respondan preguntas, les pedimos que utilicen software —naveguen por sitios web, rellenen formularios, recorran procesos y completen tareas de principio a fin de forma autónoma—.
Esto hace posible una gran variedad de tareas del mundo real que ahora están fragmentadas entre distintas interfaces, como reservas completas, procesos de compra en comercios electrónicos, planificación de viajes en varios pasos y flujos administrativos sin un equivalente claro mediante API. Estos problemas no son nuevos. Lo nuevo es que ahora resulta viable resolverlos con modelos de propósito general.
Sistemas recientes de Anthropic y OpenAI han mostrado agentes que no solo actúan, sino que razonan sobre el estado, se recuperan de errores y crean sobre la marcha soluciones específicas para cada tarea. Esto convierte el navegador en un entorno de ejecución general para agentes, pero plantea de inmediato una cuestión de diseño: ¿qué parte 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 este artículo, ese enfoque está llegando a sus límites.
Al crear agentes para navegadores, surge un instinto habitual: 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 resulte 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 trabajar mediante abstracciones que eliminan demasiada información del sistema subyacente. Comprimimos un entorno desordenado y dinámico en una interfaz de acciones fija y después pedimos al modelo que rinda bien pese a esa pérdida de información.
Esta solución de compromiso resulta cada vez menos atractiva.
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 han mejorado muchísimo y ya no necesitan barreras abstractas: necesitan todo el espacio de acciones para diseñar, ejecutar e iterar la tarea hasta alcanzar su objetivo.
Este artículo aborda ese cambio, desde una automatización del navegador cargada de abstracciones hasta el uso restringido del ordenador, y explica qué ocurre al diseñar los sistemas de esta manera.
El problema no es que las interfaces de acciones fijas sean conceptualmente erróneas. El problema es que la web no se adapta a ellas.
Las interfaces modernas se construyen con React, Vue y Angular, e incluyen actualizaciones asíncronas del estado, sistemas de eventos sintéticos y widgets de terceros integrados en iframes de distinto origen con sus propios ciclos de vida. Un envoltorio que indica «escribe en este campo» solo funciona si la página comparte nuestra definición de lo que significa escribir. Muchas no lo hacen. Asignar directamente un valor suele eludir por completo la detección de cambios del framework. El campo parece estar rellenado. La validación nunca se activa. El formulario sigue sin funcionar.
Esto se puede parchear. Se pueden añadir casos especiales para campos de React, emitir eventos blur después de focus y esperar a que la red esté inactiva antes de leer el estado. Cada parche es correcto en su contexto. 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 han encontrado.
El problema de fondo es que la capa de abstracción codifica supuestos sobre cómo deberían funcionar las interacciones, para después descubrir que la web parte de supuestos distintos.
Pensemos en un formulario de pago de Stripe o Adyen integrado en un iframe de distinto origen. El envoltorio no puede acceder directamente a él porque se encuentra en un origen distinto. La herramienta read_text no puede observar su estado interno. La herramienta type no puede acceder a sus campos. Un agente basado en envoltorios se topa aquí con un obstáculo insalvable. La abstracción se diseñó para el documento principal. La tarea real se encuentra donde la abstracción no puede verla.
Este mismo desajuste aparece en procesos menos evidentes. Un menú desplegable controlado por un framework puede no responder 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 pensemos en un proceso modal de varios pasos en el que las actualizaciones visibles del DOM se retrasan respecto a los cambios del estado interno. 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 acaba actuando demasiado pronto o leyendo un estado obsoleto porque trabaja con una visión incompleta del sistema.
En todos estos casos, la abstracción oculta las señales que el agente necesita realmente.
Un modelo que opere a un nivel inferior —inspeccionando el DOM activo, razonando sobre los límites de los marcos y sintetizando la secuencia de interacción para esa superficie concreta— puede desenvolverse en estas situaciones. No se trata de que el modelo sea intrínsecamente más inteligente. Se trata de que tiene acceso a la información que se había eliminado.
El cambio hacia el que hemos estado avanzando es fácil de describir: en lugar de pedir al modelo que elija entre acciones predefinidas, le ofrecemos una superficie 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 el sector, que empieza a favorecer herramientas primitivas de menor nivel. Estas aprovechan la capacidad innata del agente para corregirse durante la ejecución y generar código de alta calidad, en lugar de recurrir a herramientas específicas codificadas de antemano que son robustas, pero reducen la capacidad del modelo para adaptarse a distintos entornos.
Pensemos en el éxito de Claude Code como herramienta principal para muchos desarrolladores y en el giro general del sector hacia los agentes basados en terminales. La mayor ventaja de Claude Code no es el modelo en sí, sino el arnés de menor nivel. Proporcionar al modelo menos herramientas, pero más modulares y de menor nivel, es decir, el terminal, mejora el uso de herramientas, sobre todo porque el agente puede razonar y crear scripts personalizados para la tarea, en lugar de intentar utilizar herramientas generalizadas que saturan la ventana de contexto.
En la práctica, para automatizar el navegador, esto significa que el modelo puede inspeccionar directamente el estado activo de la página, recorrer marcos y crear código de interacción a medida para la interfaz actual, en lugar de asignarlo todo a un conjunto fijo de acciones predefinidas.
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 concreta. Puede crear secuencias de varios pasos, adaptarse a procesos poco habituales 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 entraña más riesgos, pero se ajusta mucho mejor a la verdadera naturaleza del problema.
Es importante señalar que eliminar la capa de abstracción no resta rigor al sistema. Traslada ese rigor a otro lugar.
El trabajo que antes se concentraba en el diseño de envoltorios y la gestión de casos extremos se traslada a tres ámbitos: el prompt, que se convierte en una forma de formación operativa; el entorno de ejecución, que impone límites como el ámbito de navegación, las acciones sensibles y el comportamiento de los reintentos; y la capa de evaluación, que no solo determina si la tarea ha tenido éxito, sino también si los pasos intermedios han sido correctos. Menos abstracciones frágiles. Sistemas circundantes más robustos.
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 pequeño conjunto de primitivas potentes y un entorno de ejecución restringido, en lugar de una variedad 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 que se parecen a aquellas para las que ya se han creado envoltorios. Un agente con un entorno de ejecución restringido generaliza a tareas que comparten una base de ejecución, aunque la interfaz visible sea distinta.
Por ejemplo, interactuar con un formulario de búsqueda, un proceso de reserva o una página de configuración puede parecer completamente distinto en la interfaz de usuario. Pero, en el fondo, comparten patrones: leer el estado, activar eventos, validar resultados y gestionar actualizaciones asíncronas. Un sistema que funciona a ese nivel transfiere sus capacidades entre tareas de forma más natural.
El componente reutilizable no es la lista de acciones, sino la capacidad del modelo para inspeccionar el estado, actuar con seguridad y verificar los resultados.
La conclusión más clara de este trabajo es que la fiabilidad no se consigue proporcionando al modelo más funciones auxiliares. A menudo se consigue ofreciéndole menos primitivas, pero más potentes, y restringiéndolas de la forma adecuada. Ayudar en exceso incorpora al código supuestos sobre cómo debe realizarse una tarea. Las restricciones definen unos límites operativos seguros y permiten al modelo descubrir mejores soluciones para cada situación.
Una superficie 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 pequeño conjunto de acciones predefinidas, en la práctica pasa a operar directamente sobre software real. Esto cambia de inmediato el perfil de riesgo.
Hay cuatro aspectos que deben tenerse en cuenta al diseñar el sistema:
Exposición de datos. Si el agente interactúa con interfaces reales, a menudo encontrará información confidencial. Esto exige un enfoque riguroso del enmascaramiento y el control de acceso. Los datos solo deben revelarse cuando sean necesarios para la ejecución, y los registros y las trazas deben gestionarse con cuidado para evitar que la observabilidad se convierta en la parte más sensible del sistema.
Ámbito de ejecución. Un agente potente no debe poder operar de manera arbitraria. En la práctica, esto implica limitar por dónde puede navegar, a qué dominios puede acceder y con qué sistemas puede interactuar. Estas restricciones deben aplicarse en el entorno de ejecución y no quedar como meras convenciones en los prompts.
Confianza en el entorno. Las interfaces modernas pueden incluir instrucciones, contenido o procesos engañosos o directamente hostiles. La inyección de prompts mediante el contenido de una página constituye una superficie de ataque real. El sistema necesita una jerarquía clara de instrucciones, comprobaciones de validación y condiciones de finalización para impedir que el agente siga indicaciones no deseadas.
Espectro de autonomía. No todas las acciones deben ser totalmente autónomas. En muchos entornos de producción es importante entender la autonomía como un espectro. El sistema puede tener un alto grado de agencia al explorar y ejecutar, pero seguir exigiendo aprobación para determinadas categorías de acciones.
El principio subyacente es sencillo: dotar al modelo de más poder 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 del navegador adecuadas que debemos exponer?
Empezamos a preguntarnos: ¿qué podemos hacer para proporcionar al modelo un espacio de acciones completo y cómo podemos crear políticas de ejecución que mantengan la seguridad?
Este cambio de enfoque modifica nuestras prioridades. Las taxonomías de acciones y la exhaustividad de los envoltorios pierden importancia. Las políticas de ejecución, la observabilidad y la evaluación de cada paso cobran más importancia. La capacidad del modelo y el diseño del sistema no se sustituyen mutuamente. A medida que mejoran los modelos, el trabajo del sistema cobra más importancia, no menos.
Los agentes de navegador que funcionan en demostraciones suelen tener éxito porque la tarea es limitada 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 hemos centrado en los agentes de navegador, esto apunta a una concepción más amplia del uso del ordenador como disciplina de sistemas.