Los arneses de ejecución más ligeros y los agentes que ejecutan código son más adecuados para tareas abiertas, donde una coordinació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 centrales de los sistemas de agentes.
En nuestras pruebas, el SDK de agentes reduce hasta seis veces la complejidad y el código necesarios para crear agentes que ejecutan código.
Durante mucho tiempo, los avances en los sistemas de agentes provinieron de mejorar la coordinación: mejores prompts, interfaces de herramientas, gestión del contexto y un flujo de control más estricto. Sin embargo, a medida que los agentes de programación adquieren más capacidades, ese equilibrio comienza a cambiar.
En muchos flujos de trabajo abiertos, el cuello de botella ya no es el ciclo del agente, sino la capa de ejecución: el entorno aislado donde el modelo escribe código, ejecuta comandos, examina resultados e itera. A medida que el razonamiento de cada tarea se traslada a ese entorno, la coordinació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 agentes. En nuestras pruebas durante el acceso anticipado, descubrimos que, en lugar de agregar otra capa de lógica del framework, hace que la capa de ejecución sea más modular y combinable para que el resto del sistema pueda mantenerse ligero.
En la ingeniería de arneses de ejecución, se ha vuelto popular reducir el arnés de ejecución a su forma eficaz mínima. En términos generales, el arnés de ejecución es el software que rodea al modelo: la capa que gestiona el contexto, las herramientas, el flujo de control y los ciclos de retroalimentación para que el modelo trabaje de forma confiable.
En los últimos años, muchas mejoras en el rendimiento de los agentes provinieron del fortalecimiento de esa capa. Mejores herramientas, memoria y recuperación de información, una descomposición más explícita y una coordinación más estricta solían aumentar la confiabilidad y las capacidades de los sistemas. En ese paradigma, avanzar 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 cierta clase de tareas abiertas. Cada vez más proyectos y artículos sugieren que el rendimiento no siempre mejora cuando el arnés de ejecución se vuelve más prescriptivo. En la programación asistida, las tareas de larga duración, el uso del navegador, y las tareas de contexto extenso, el mismo patrón aparece una y otra vez: cuando el modelo alcanza suficiente inteligencia, imponer demasiada estructura de la tarea en el software circundante puede convertirse en una limitación, en vez de una ventaja.
Por lo tanto, la función del arnés de ejecución está cambiando. En lugar de intentar anticipar la tarea mediante una coordinación rígida, el arnés de ejecución sirve cada vez más para proporcionar una plataforma de ejecución clara: un entorno aislado donde el modelo puede examinar el estado, ejecutar código, recuperarse de errores y adaptar su propio enfoque, sin salirse de las interfaces y medidas de protección del sistema. Esto se aproxima al cambio que Andrej Karpathy describió en Ingeniero de software 3.0: parte de la lógica que antes residía en el software asciende al “prompt”.
La conclusión no es que los sistemas de agentes deban eliminar toda estructura. Muchas tareas aún se benefician de flujos de trabajo explícitos, heurísticas y medidas de protección deterministas, en especial si son acotadas, de gran volumen o tienen un criterio de éxito claro. Como planteamos en nuestra publicación anterior sobre Heurísticas para diseñar sistemas de agentes, una coordinación sólida sigue siendo importante cuando un flujo lógico confiable es posible y conveniente.
En las tareas abiertas, el enfoque está cambiando. El desafío ya no consiste tanto en diseñar capas de coordinación cada vez más elaboradas, sino en crear entornos de ejecución lo bastante simples, observables y modulares para que el modelo trabaje eficazmente en ellos.
Cuando un agente puede leer archivos, escribir código, ejecutar comandos de shell e iniciar tareas de larga duración, el desafío de ingeniería cambia. Lo difícil ya no es solo optimizar el prompt o dirigir las herramientas. Al operar ahora sobre un sistema real, estos agentes se vuelven mucho más potentes, pero también más delicados, pues amplían 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 (consulta Sandbox Bench, de AISI).
Por ello, 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 considerarse un complemento: una herramienta añadida al arnés de ejecución. Sin embargo, ese enfoque comienza a fallar cuando la ejecución mantiene un estado, es de larga duración o se realiza de forma remota. Gestionar el propio entorno aislado —su ciclo de vida, estado, interfaces e integración con el ciclo del agente— se convierte rápidamente en un problema independiente de diseño de sistemas. Esta es una de las razones por las que cada vez más proveedores ofrecen entornos administrados para ejecutar código, como la API de contenedores y la herramienta de shell de OpenAI, Modal, Cloudflare, Daytona y E2B, entre otros.
Este límite es importante porque la ejecución de código requiere mayor aislamiento y un control más estricto del entorno de ejecución que el resto del arnés de ejecución. En la práctica, los agentes que ejecutan código y están mal implementados pueden generar tres riesgos críticos para el negocio: gasto informático descontrolado, acciones destructivas en sistemas internos y exposición de información confidencial. Con una contenerización y un aislamiento adecuados, además de medidas de protección durante la ejecución, estos riesgos pueden limitarse a un nivel aceptable para implementaciones reales.
Una forma de entenderlo es imaginar que se le proporciona al agente su propio Espacio de trabajo sellado, en vez de las llaves de toda la oficina. Aun así, puede realizar trabajo útil en ese espacio, pero solo dentro de límites claramente definidos. Puedes limitar cuántos recursos informáticos utiliza, restringir los sistemas y archivos a los que puede acceder y controlar qué información tiene disponible desde el principio.
Eso no elimina el riesgo por completo, pero transforma el problema de “un agente suelto en tu infraestructura” en “un agente que opera dentro de un entorno controlado”. Si esta capa se convertirá en una parte estándar de los sistemas de agentes, debe contar con soporte nativo en el propio framework. Así, el entorno aislado se convierte en una capa de ejecución modular con componentes básicos portátiles que los desarrolladores pueden adoptar rápidamente, intercambiar entre proveedores y escalar sin tener que modificar constantemente la lógica del agente.
Cuando un agente ejecuta código, el propio entorno aislado también necesita coordinación. Pasar de una prueba de concepto local a la ejecución remota, varios backends o sesiones de larga duración aumenta exponencialmente la carga operativa. Necesitas una forma uniforme de crear entornos, detenerlos, pausarlos y reanudarlos, capturar su estado, volver a conectarte después y gestionar todo esto entre distintos proveedores.
Nada de esto resulta especialmente atractivo en términos conceptuales, pero sí importa en la práctica. Este es precisamente el tipo 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 resulta importante contar con un mejor soporte del framework. Obtuvimos acceso anticipado al nuevo SDK de agentes de OpenAI y lo usamos para crear nuestros propios agentes en entornos aislados. Lo más destacado fue el cambio de énfasis arquitectónico: el SDK trata la ejecución como una capa central, no como una herramienta periférica. En la práctica, esto permite iniciar un agente en un entorno aislado, capturar el estado de ese entorno o reanudar la ejecución con menos código —cerca de seis veces menos en algunas de nuestras pruebas— y luego cambiar de backend sin reescribir la lógica circundante del agente.
Esta separación más clara de responsabilidades permite que el arnés de ejecución se concentre en el razonamiento, el contexto y el flujo de trabajo. La capa de ejecución puede concentrarse en el aislamiento, la portabilidad y el estado durante la ejecución. Esta abstracción facilita la creación de agentes de programación con mayores capacidades y más fáciles de evolucionar. 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 de ejecución al modelo, parte de la complejidad del sistema también se traslada, hacia la capa de ejecución. La ejecución de código y el aislamiento en entornos de pruebas son ahora aspectos arquitectónicos centrales de los sistemas de agentes, en especial para tareas abiertas o con un uso intensivo de código. Ahora es tan importante diseñar la canalización de agentes como el entorno en el que el agente puede actuar de forma segura, confiable y sostenida.
Por eso son importantes las abstracciones de alto nivel para la ejecución en entornos aislados. El nuevo SDK de agentes de OpenAI avanza en esa dirección al tratar la ejecución como una capa modular del sistema: portátil entre backends, con un estado persistente durante tareas largas y lo bastante sencilla de usar como para no tener que reconstruir la misma infraestructura en cada configuración nueva.
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 coordinación agregue y más por la eficacia con la que estructure los entornos de ejecución de los que los agentes dependen cada vez más.