OpenAI publica la documentación de su Agents API: sesiones persistentes y el arnés de Codex como servicio

Qué es exactamente lo que se abre

La Agents API permite que una aplicación use el harness de Codex a través de una API que gestiona OpenAI. La palabra clave es «gestiona»: según la documentación, OpenAI se ocupa de las sesiones, la orquestación, la compactación del contexto y la recuperación, mientras la aplicación que integra el servicio aporta las herramientas y elige el entorno de ejecución.

Los agentes trabajan dentro de un sandbox: ahí ejecutan código, editan ficheros, se conectan a servidores MCP y generan artefactos. No hablamos, por tanto, de un modelo que devuelve texto, sino de un proceso capaz de actuar sobre un sistema de ficheros y sobre servicios externos.

Para empezar, la documentación incluye dos ejemplos completos: crear y ejecutar un script que genere un árbol de directorios en un sandbox alojado por OpenAI, y comparar notas de versión con varios subagentes que después reúnen sus hallazgos en una sola respuesta.

Cuatro conceptos: Agent, Environment, Session, Events

La API descansa sobre cuatro piezas. El Agent define el modelo, las instrucciones, las herramientas y los servidores MCP disponibles. El Environment es un sandbox o una máquina opcional donde el agente accede a ficheros, carga skills y ejecuta comandos. La Session es una instancia duradera de un agente que avanza en sus tareas y atiende nuevas entradas. Y los Events e Items son, respectivamente, lo que se envía al agente y lo que este produce durante la sesión.

El ciclo de vida que describe la documentación tiene cuatro pasos. Primero se crea la sesión y OpenAI aprovisiona su entorno. Después se le encarga una tarea: cuando el entorno está listo, la entrada del usuario arranca un turno de trabajo. Luego se sigue el progreso, ya sea recibiendo la salida en streaming o mediante webhooks que avisan cuando el agente termina o necesita que alguien intervenga. Por último se continúa o se reorienta el trabajo, enviando otra tarea a la misma sesión o guiando al agente durante el turno en curso.

En el modo alojado por OpenAI, la aplicación envía entradas y recibe eventos; OpenAI ejecuta el agente y aprovisiona y administra su sandbox. Para la configuración y los límites de cada modalidad, la documentación remite a las opciones de entorno.

Qué ofrece el harness gestionado

La documentación enumera lo que sabe hacer el harness gestionado de Codex: ejecutar comandos y código en un sandbox; aplicar las skills e instrucciones que vengan al caso; conectarse a datos externos con herramientas o vía MCP; dejar que el usuario reoriente (steering) al agente mientras trabaja; resumir lo ya hecho para no desbordar la ventana de contexto; trocear el trabajo en subtareas y repartirlas entre subagentes; y retomar una sesión donde se quedó.

Todo eso se configura al crear la sesión. El ejemplo en Python de la documentación define un agente con el modelo gpt-6-astra, instrucciones para responder preguntas técnicas apoyándose en el MCP de documentación de OpenAI y en web search, herramientas de programmatic_tool_calling, un servidor MCP declarado por transporte HTTP contra https://developers.openai.com/mcp y un bloque multi_agent con hasta cuatro subagentes en paralelo.

En ese mismo ejemplo el entorno es de tipo self_hosted, con un workspace_directory que apunta a /workspace y un capability_directories que señala /workspace/capabilities/skills. La llamada devuelve un identificador de sesión con el que seguir trabajando.

Casos de uso y aplicaciones de referencia

Además de los ejemplos mínimos, OpenAI publica aplicaciones completas que muestran hasta dónde llega la idea: un agente de respuesta a incidentes que investiga alertas y pide aprobación antes de ejecutar acciones de recuperación; un bot de Slack que atiende peticiones con las herramientas de trabajo conectadas; un analista de datos que responde preguntas sobre un almacén de datos con SQL de solo lectura; un investigador de issues de GitHub que reproduce los bugs notificados y publica allí sus hallazgos; y un revisor de documentos que se apoya en skills de política y en agentes especializados.

El patrón se repite: autonomía acotada con puntos de control humanos. El agente de incidentes, por ejemplo, pide aprobación explícita antes de cualquier acción de recuperación, y el analista de datos solo puede leer, nunca escribir.

Precios, datos y la letra pequeña

Usar agentes no añade una tarifa propia: el uso del modelo se cobra al precio de API del modelo elegido, las herramientas de OpenAI aplican sus tarifas estándar y los sandboxes alojados por OpenAI se facturan a las tarifas estándar de contenedor.

Lo que más pesa en cualquier despliegue corporativo son las restricciones sobre los datos, y ahí la documentación no deja margen: por ahora la Agents API solo ofrece residencia de datos en Estados Unidos y no admite Zero Data Retention (ZDR, retención cero de datos). Añade además un matiz que conviene leer dos veces: elegir un sandbox self-hosted tampoco hace que la Agents API sea elegible para ZDR.

Sí se pueden borrar las sesiones y los artefactos publicados cuando ya no hacen falta. Para los detalles sobre residencia y retención, la documentación remite a la sección de controles de datos de la plataforma de OpenAI.