Los arneses más ligeros y los agentes que ejecutan código son más adecuados para tareas abiertas, donde una orquestación demasiado rígida puede limitar el rendimiento del modelo.
Por ello, la ejecución de código y el aislamiento en entornos de pruebas son ahora aspectos arquitectónicos esenciales de los sistemas de agentes.
En nuestras pruebas, el SDK de Agents reduce hasta 6 veces la complejidad y la cantidad de código necesarias para crear agentes que ejecutan código.
Durante mucho tiempo, los sistemas de agentes progresaron gracias a mejoras en la orquestación: mejores prompts, interfaces de herramientas, gestión del contexto y flujos de control más estrictos. Sin embargo, a medida que los agentes de programación se vuelven más capaces, ese equilibrio empieza a cambiar.
En muchos flujos de trabajo abiertos, el cuello de botella ya no es el propio bucle del agente, sino la capa de ejecución: el entorno aislado donde el modelo escribe código, ejecuta comandos, examina los resultados e itera. A medida que se traslada más razonamiento sobre las tareas a ese entorno, la orquestación circundante debe simplificarse para que el modelo pueda desplegar toda su capacidad.
Ese cambio es precisamente lo que permite la nueva versión del SDK de Agents. Durante nuestras pruebas de acceso anticipado, comprobamos que, en lugar de añadir otra capa de lógica al framework, hace que la capa de ejecución sea más modular y componible para que el resto del sistema pueda seguir siendo ligero.
En la ingeniería de arneses se ha puesto de moda reducir el arnés a su forma mínima eficaz. A grandes rasgos, el arnés es el software que rodea al modelo: la capa que gestiona el contexto, las herramientas, el flujo de control y los bucles de retroalimentación para que el modelo trabaje de forma fiable.
En los últimos años, muchas mejoras en el rendimiento de los agentes procedían de reforzar esa capa. Mejores herramientas, memoria y recuperación, una descomposición más explícita y una orquestación más estricta solían aumentar la fiabilidad y la capacidad de los sistemas. En ese paradigma, progresar significaba, en gran medida, incorporar más lógica de las tareas al software que rodeaba al modelo.
Ese patrón está perdiendo fuerza, al menos para un tipo de tareas abiertas. Cada vez más proyectos y artículos indican que el rendimiento no siempre mejora cuando el arnés se vuelve más prescriptivo. En la programación asistida, las tareas de larga duración, el uso del navegador y las tareas con contextos extensos, se repite el mismo patrón: cuando el modelo alcanza suficiente inteligencia, imponer demasiada estructura a las tareas desde el software circundante puede convertirse en una limitación en lugar de una ventaja.
Por tanto, la función del arnés está cambiando. En vez de intentar anticipar la tarea mediante una orquestación rígida, el arnés sirve cada vez más para ofrecer una superficie de ejecución limpia: un entorno aislado donde el modelo puede examinar el estado, ejecutar código, recuperarse de errores y adaptar su enfoque sin dejar de estar sujeto a las interfaces y salvaguardas del sistema. Este cambio se parece al que Andrej Karpathy describió en Ingeniero de software 3.0: parte de la lógica que antes residía en el software asciende hasta el «prompt».
La conclusión no es que los sistemas de agentes deban eliminar toda estructura. Muchas tareas siguen beneficiándose de flujos de trabajo explícitos, heurísticas y barreras de protección deterministas, sobre todo si son acotadas, de gran volumen o tienen un criterio de éxito claro. Como sostuvimos en nuestro artículo anterior sobre heurísticas para diseñar sistemas de agentes, una orquestación sólida sigue siendo importante cuando un flujo lógico fiable es posible y deseable.
En las tareas abiertas, el enfoque está cambiando. El reto ya no consiste tanto en diseñar capas de orquestación cada vez más elaboradas como en crear entornos de ejecución sencillos, observables y lo bastante modulares para que el modelo trabaje en ellos con eficacia.
Cuando un agente puede leer archivos, escribir código, ejecutar comandos del shell e iniciar tareas de larga duración, el reto de ingeniería cambia. La dificultad ya no reside solo en optimizar el prompt o enrutar las herramientas. El hecho de operar ahora sobre un sistema real hace que estos agentes sean mucho más potentes, pero también más delicados, pues amplía la superficie de seguridad y protección. Por ejemplo, un agente capaz de ejecutar código puede realizar acciones perjudiciales si su entorno no está bien aislado (véase Sandbox Bench, del AISI).
Por tanto, el aislamiento en entornos de pruebas se está convirtiendo en un aspecto crítico de los frameworks de agentes. En sistemas anteriores, la ejecución solía tratarse como un complemento: una herramienta añadida al arnés. Pero ese enfoque empieza a fallar cuando la ejecución mantiene un estado, dura mucho tiempo o se realiza de forma remota. Gestionar el propio entorno aislado —su ciclo de vida, estado, interfaces e integración con el bucle del agente— pronto se convierte en un problema independiente de diseño de sistemas. Esa es una de las razones por las que cada vez más proveedores ofrecen entornos gestionados para ejecutar código, como la API de contenedores y la herramienta de shell de OpenAI, Modal, Cloudflare, Daytona y E2B, entre otros.
Esta separación es importante porque ejecutar código exige un aislamiento más sólido y un control más estricto del entorno de ejecución que el resto del arnés. En la práctica, una implementación deficiente de agentes que ejecutan código puede generar tres riesgos críticos para el negocio: un gasto informático descontrolado, acciones destructivas en sistemas internos y la exposición de información confidencial. Con una contenerización y un aislamiento adecuados, además de salvaguardas durante la ejecución, estos riesgos pueden limitarse a un nivel aceptable para implementaciones reales.
Una forma de entenderlo es imaginar que se proporciona al agente un espacio de trabajo propio y sellado, en vez de las llaves de toda la oficina. Puede seguir realizando tareas útiles dentro de ese espacio, pero solo dentro de unos límites claramente definidos. Es posible limitar los recursos informáticos que utiliza, restringir los sistemas y archivos a los que accede y controlar la información disponible desde el principio.
Esto no elimina por completo el riesgo, pero transforma el problema de «un agente suelto en la infraestructura» en «un agente que opera dentro de un entorno controlado». Si esta capa va a convertirse en un componente habitual de los sistemas de agentes, debe contar con soporte de primer nivel en el propio framework. Así, el entorno aislado se convierte en una capa de ejecución modular con elementos portátiles que los desarrolladores pueden adoptar rápidamente, intercambiar entre proveedores y escalar sin tener que rehacer constantemente la lógica del agente.
Cuando un agente ejecuta código, también es necesario orquestar el propio entorno aislado. Pasar de una prueba de concepto local a la ejecución remota, a varios backends o a sesiones de larga duración aumenta exponencialmente la carga operativa. Hace falta una forma coherente de crear entornos, detenerlos, pausarlos y reanudarlos, generar instantáneas de su estado, volver a conectarse más adelante y gestionar todo ello con distintos proveedores.
Nada de esto resulta especialmente atractivo desde el punto de vista conceptual, pero en la práctica es importante. Esta es precisamente la clase de infraestructura que se vuelve problemática cuando cada equipo reconstruye desde cero una canalización de agentes, sobre todo si no está integrada en el framework de agentes…
Aquí es donde cobra importancia un mejor soporte del framework. Obtuvimos acceso anticipado al nuevo SDK de Agents de OpenAI y lo utilizamos para crear nuestros propios agentes en entornos aislados. Lo más destacado fue el cambio de prioridades arquitectónicas: el SDK trata la ejecución como una capa de primer nivel, no como una herramienta periférica. En la práctica, esto permite iniciar un agente en un entorno aislado, crear una instantánea del entorno o reanudar la ejecución con menos código —unas 6 veces menos en algunas pruebas— y después cambiar de backend sin reescribir la lógica circundante del agente.
Esta separación de responsabilidades más clara permite que el arnés se centre en el razonamiento, el contexto y el flujo de trabajo. La capa de ejecución puede centrarse en el aislamiento, la portabilidad y el estado durante la ejecución. Esta abstracción facilita la creación de agentes de programación más capaces y fáciles de evolucionar, que pueden alternar entre la ejecución local y remota, admitir tareas de mayor duración y cambiar de backend de ejecución sin obligar a rediseñar todo el sistema.
A medida que más lógica de las tareas pasa del arnés al modelo, parte de la complejidad del sistema se traslada con ella a la capa de ejecución. La ejecución de código y el aislamiento en entornos de pruebas son ahora aspectos arquitectónicos esenciales de los sistemas de agentes, sobre todo para tareas abiertas o que requieren mucha programación. Diseñar el entorno donde el agente pueda actuar de forma segura, fiable y prolongada es ahora tan importante como diseñar la canalización de agentes.
Por eso son importantes las abstracciones de alto nivel para la ejecución en entornos aislados. El nuevo SDK de Agents de OpenAI avanza en esa dirección al tratar la ejecución como una capa modular del sistema: portátil entre backends, capaz de mantener el estado durante tareas prolongadas y lo bastante sencilla para usarla sin reconstruir la misma infraestructura en cada nueva configuración.
La conclusión general es que la próxima generación de frameworks de agentes probablemente se definirá menos por cuánta lógica de orquestación añadan y más por cómo estructuren los entornos de ejecución de los que dependen cada vez más los agentes.