API de Agentes Gestionados de OpenAI: Entornos aislados alojados vs. ejecución autoalojada

La infraestructura previa al agente

Cualquiera que haya creado un agente autónomo sabe cuánto del trabajo no tiene nada que ver con la función real del agente. Antes de llegar a la lógica interesante, un equipo debe escribir el bucle de ejecución, almacenar el estado de la conversación, elegir qué herramienta se ejecutará a continuación, recuperarse de fallos, comprimir el contexto a medida que crecen las sesiones y proporcionar un lugar seguro para ejecutar código y acceder a archivos. Solo entonces es cuando llega el turno de la tarea real.

El servicio de agentes gestionados de OpenAI, ahora en beta pública, está diseñado para aliviar gran parte de esa carga. Los desarrolladores no necesitan añadir otro punto de conexión de modelo a un marco de orquestación; en su lugar, reciben un entorno de ejecución gestionado para los agentes. Cuatro elementos describen todo el proceso: la tarea, el modelo, las herramientas y el entorno donde se realiza el trabajo. La plataforma se encarga entonces de una gran parte de la infraestructura necesaria para ejecutarlo.

El motor subyacente merece atención. OpenAI está convirtiendo el entorno de su propio agente de programación, Codex, en infraestructura para desarrolladores externos. Es mucho más que una capa superficial sobre una API de chat o de completamiento: contiene la orquestación que hace que un agente realice pasos repetidos, decide cuáles herramientas usar, gestiona una sesión en expansión y ejecuta las tareas, además de poder coordinar agentes adicionales para abordar partes de un problema simultáneamente.

Como resultado, la línea de partida se desplaza. Los equipos ya no necesitan dedicar la fase inicial de un proyecto a reconstruir la maquinaria que hace que un agente funcione, y pueden comenzar mucho más cerca de la aplicación real. Lo que permite a un agente ejecutarse, actuar, recuperarse y coordinarse se convierte en una capacidad gestionada.

Qué abarca el entorno gestionado

La apuesta detrás de este lanzamiento es que la mayoría de los requisitos para agentes fiables son comunes, no específicos de un producto. Sea cual sea el problema empresarial, un agente necesita un registro de lo que ha ocurrido en la sesión, una forma de asociar el siguiente paso con la herramienta adecuada, un método para acortar conversaciones que han superado el límite del marco de contexto, y una forma de dividir tareas grandes en partes independientes. Se trata en gran medida de problemas ya resueltos, y cada empresa que los vuelve a resolver con su propio código desperdicia tiempo que debería destinarse al producto.

Al centralizar esa lógica en un framework gestionado, se brinda a los desarrolladores una base sobre la cual construir en lugar de tener que crearla ellos mismos. El framework se encarga del ciclo del modelo: el contexto se envía al modelo, se obtiene una decisión, esta se ejecuta y el resultado vuelve como nuevo input. Mantiene el estado de la sesión para que las tareas largas no pierdan los avances anteriores. Compresiona el contexto por sí mismo a medida que la sesión se acerca a la capacidad del modelo. Además, elige qué definiciones de herramientas son relevantes en cada momento, evitando que el modelo reciba opciones irrelevantes.

Elegir dónde trabaja el agente

Una vez definidas la tarea, el modelo y las herramientas, queda una decisión por tomar: ¿dónde tiene lugar la ejecución? El servicio ofrece aquí una verdadera elección, y los compromisos entre estos dos caminos son más importantes que casi cualquier otro aspecto en la configuración.

Espacio de trabajo alojado

En el primer enfoque, OpenAI crea un entorno de trabajo completo basado en Linux para cada sesión y lo ejecuta. Python, Node.js y herramientas comunes de línea de comandos vienen preinstaladas, lo que permite al agente ejecutar código, trabajar con archivos y generar resultados sin que el desarrollador tenga que lidiar nunca con una máquina virtual, una imagen de contenedor ni un pipeline de despliegue. Los resultados de las tareas completadas pueden convertirse en artefactos inmutables, útiles para equipos que desean un registro permanente e inalterable de exactamente lo que produjo una ejecución determinada.

Dado que OpenAI se encarga del aprovisionamiento y del ciclo de vida del entorno de pruebas, desde su creación hasta su desmantelamiento, esta opción es adecuada para despliegues rápidos. Un equipo que desea tener un agente listo cuanto antes, sin pasar días esperando aprobaciones de infraestructura interna ni escribiendo scripts de despliegue, obtiene grandes ventajas al utilizar los recursos de cómputo de OpenAI. También es adecuada para cargas de trabajo elásticas, donde el número de ejecuciones del agente puede aumentar de forma impredecible, y el equipo prefiere no encargarse de la lógica de escalado. Para seleccionarla, basta con un pequeño bloque de configuración que indique el tipo de hosting y un directorio para los archivos de funcionalidades.

"environment": {
  "type": "openai_hosted",
  "capability_directories": ["/workspace/capabilities/skills"]
}

Ejecución autohospedada

La segunda opción deja la ejecución en la infraestructura que posee el desarrollador, ya sea un contenedor, una máquina virtual o un entorno aislado remoto de un proveedor externo. Dentro de ese entorno se encuentra un componente llamado servidor de ejecución, el cual se conecta a OpenAI a través de un WebSocket. Las órdenes llegan desde el sistema gestionado por ese enlace, y el servidor de ejecución realiza operaciones en la shell e interacciones mediante el Protocolo de Contexto de Modelo local en la máquina del desarrollador antes de enviar los resultados de vuelta.

Un detalle de seguridad destaca: la conexión utiliza una clave restringida creada específicamente para ello, por lo que la clave API a nivel de aplicación, de alcance más amplio, nunca necesita encontrarse dentro del entorno de ejecución. Si ese entorno fuera comprometido, un atacante solo encontraría credenciales con un alcance más limitado que la clave de la aplicación completa.

El autoalojamiento permite a un equipo tener mucho más control sobre qué recursos de cómputo se utilizan, cómo se accede a las redes privadas y dónde se almacenan los datos. Las organizaciones reguladas y los equipos cuyos agentes deben acceder a sistemas internos inaccesibles desde Internet público suelen necesitarlo. Sin embargo, ese control conlleva tareas adicionales: el equipo se encarga del aislamiento y las actualizaciones de seguridad del entorno, del escalado bajo carga, del monitoreo y de la limpieza al finalizar las sesiones. Tener la orquestación gestionada en otro lugar deja todo esto sin afectar.

Qué permanece con OpenAI en cualquier caso

Es tentador suponer que la ejecución autohospedada significa que el agente funciona íntegramente dentro de las instalaciones de una empresa, desconectado de OpenAI después de la primera llamada al modelo. Eso estaría mal. Incluso en entornos autohospedados, OpenAI sigue gestionando el mecanismo de coordinación y la orquestación del modelo que determina qué hace el agente en cada paso. Solo la capa de ejecución se traslada, es decir, los comandos reales, el manejo de archivos y los cálculos. El bucle de razonamiento, la gestión de sesiones y la lógica de coordinación permanecen en el lado de OpenAI, independientemente del entorno que elija el equipo.

Sesiones largas y catálogos de herramientas extensos

Cualquier agente más complejo que uno sencillo se enfrenta rápidamente a dos problemas. Uno es que las sesiones superan el límite del marco de contexto del modelo. El otro es que los catálogos de herramientas son tan grandes que enviar cada definición con cada solicitud consume tokens y ralentiza al modelo. El mecanismo gestionado aborda ambos problemas.

En sesiones prolongadas, comprime automáticamente el contexto anterior a medida que la conversación se acerca a su límite, conservando lo que el agente aún necesita y descartando lo que ya es irrelevante. De este modo, un flujo de trabajo puede abarcar mucho más allá de una sola ventana de contexto sin necesidad de resúmenes manuales ni lógica de truncamiento.

En trabajos que requieren muchos herramientas, una función llamada búsqueda de herramientas muestra únicamente las definiciones aplicables al paso actual, lo que reduce el uso de tokens y los costos, además de ayudar a mantener intacto el caché del modelo. Una vez cargadas las herramientas adecuadas, una capacidad complementaria permite realizar llamadas a herramientas de forma programática. El agente puede ejecutar varias llamadas en paralelo, enlazar operaciones relacionadas y filtrar o combinar resultados en código, de modo que solo la parte útil llegue al contexto del modelo. Con grandes volúmenes de datos, esto representa una gran ventaja, ya que el agente no necesita analizar cada resultado bruto en busca de los pocos datos relevantes.

La configuración enumera las herramientas en el bloque del agente, incluyendo una entrada para el servidor MCP.

"agent": {
  "tools": [
    {
      "type": "mcp",
      "server_label": "internal_docs",
      "transport": {
        "type": "http",
        "server_url": "https://docs.example.com/mcp"
      }
    }
  ]
}

Varios agentes en una tarea

Tal vez la capacidad más audaz sea el soporte nativo para que múltiples agentes trabajen en una tarea de forma paralela. En lugar de hacer que un único agente aborde un problema complejo paso a paso, un desarrollador puede activar el soporte multiagente y permitir que el sistema divida la tarea en partes independientes. Cada parte va a un subagente con su propio contexto separado.

Cada subagente se concentra en una tarea específica y no tiene que manejar toda la tarea al mismo tiempo, mientras que un agente principal coordinador supervisa el proceso y combina los resultados en una respuesta final. Para investigaciones, análisis a gran escala o codificación que se divide en flujos independientes, esta estructura puede acortar significativamente el tiempo de finalización, y nadie necesita diseñar ni crear una capa de orquestación para agentes concurrentes.

Para habilitarlo se necesita una marca en la configuración del agente, junto con la elección del modelo.

"agent": {
  "model": "gpt-6-astra",
  "multi_agent": {
    "enabled": true,
    "max_concurrent_subagents": 3
  }
}

Qué ruta corresponde a qué equipo

Las dos rutas de ejecución coinciden perfectamente con dos conjuntos de prioridades. Los equipos que ponen la velocidad por delante y prefieren no preocuparse por los recursos de cómputo se benefician de los entornos aislados gestionados. Quienes estén validando una nueva idea de agente o quieran lanzar sin negociar presupuestos de infraestructura probablemente adoptarán la opción alojada más rápidamente y dedicarán menos tiempo de ingeniería para ello.

El autoalojamiento tiene más sentido cuando los requisitos superan lo que puede satisfacer un entorno aislado compartido y de uso general. Ejemplos incluyen redes privadas a las que debe acceder el agente, imágenes de máquina personalizadas con herramientas propietarias, cómputo especializado como configuraciones específicas de GPU y límites de datos regulados que impiden que la información salga de una jurisdicción o red. En esos casos, la responsabilidad operativa adicional es simplemente el costo de hacer las cosas correctamente.

Quién debería esperar

No todos los equipos necesitan apresurarse a adoptar esta opción. Si un ciclo basado en SDK ya existente funciona de manera fiable, gestiona las reintentos de forma adecuada y genera poca carga para quienes lo mantienen, es probable que haya pocas razones para migrar. Sustituir un sistema que funciona bien solo porque existe una alternativa gestionada tiende a añadir riesgos sin ofrecer beneficios equivalentes.

La situación cambia cuando el estado de la sesión, la gestión de reintentos y la lógica de recuperación ante fallos se convierten en una carga constante. Transferir esas tareas a un servicio gestionado que ya se ocupa de ellas y que mejora con cada nueva versión del modelo libera una cantidad considerable de capacidad para trabajar en aquello que realmente diferencia a un producto.

Una regla práctica: cede todo aquello que no necesitas controlar y mantén el control sobre lo que es esencial para el negocio. Esto es especialmente importante en lo que respecta a la topología de despliegue, el manejo de datos sensibles y el comportamiento en producción de un agente, que debe ser preciso y predecible. La infraestructura que nadie en el equipo quiere asumir como responsabilidad debe delegarse. En cambio, el comportamiento que define la fiabilidad de un producto o la postura de cumplimiento de una empresa no debe delegarse.

Fundamentos abiertos

Una característica que aporta credibilidad a esta versión es que se basa en fundamentos de código abierto. OpenAI opera y mantiene la versión de producción dentro del servicio gestionado, mientras que el código subyacente sigue estando disponible para inspección pública. Quienes deseen conocer cómo funcionan el ciclo del modelo, la selección de herramientas y la coordinación de subagentes pueden leer la lógica implementada y omitir la documentación. Esa apertura equilibra el carácter, de por sí cerrado, de un servicio en la nube completamente gestionado y ayuda a los equipos a confiar en lo que ejecuta sus cargas de trabajo de producción.

Precios y estado de beta

La beta pública está abierta a todos los desarrolladores, sin ningún costo de suscripción adicional por el uso regular. Los cargos se calculan en función de los tokens que utiliza una sesión y las herramientas a las que accede, según la tarifa estándar ya establecida para los modelos subyacentes. Dado que los comentarios de los desarrolladores seguirán influyendo en el desarrollo del servicio hasta su disponibilidad general, quienes lo adopten tempranamente deben prepararse para cambios en el comportamiento, las opciones predeterminadas y las funcionalidades en los próximos meses.

Una API de Agents gestionada, construida sobre la plataforma que ya impulsa a Codex, representa un cambio real en la cantidad de infraestructura que un equipo debe crear antes de que un agente autónomo pueda realizar tareas útiles. Al ofrecer un entorno completamente alojado y una opción de autoalojamiento que sigue contando con una orquestación gestionada de forma centralizada, OpenAI permite a los desarrolladores elegir la opción que mejor se adapte a sus necesidades, sin imponer un único modelo de despliegue a todos.

El llamado a la adopción se reduce a una pregunta que aplica a cualquier nueva capa de infraestructura: ¿elimina el trabajo que nadie quería asumir y mantiene al equipo firmemente a cargo de lo que define el producto?