OpenAI abre la Agents API y vende el harness que hay detrás de Codex

OpenAI pasó los últimos dos años vendiendo a los desarrolladores llamadas a modelos y, más recientemente, un framework para conectar agentes entre sí. El 10 de septiembre de 2026 empezó a vender algo distinto: la maquinaria intermedia. La empresa abrió su Agents API en beta pública, dando a cualquier desarrollador acceso al «Codex harness» gestionado (el bucle del agente y la infraestructura que hay detrás de Codex) con una sola llamada a la API.

Lectura relacionada: Las acciones de ServiceNow cayeron un 27% cuando el miedo a la IA llegó al negocio del software · Cloudflare adquiere Deno para que Workers pueda autoalojarse.

La propuesta es deliberadamente concreta y, para los equipos que han construido agentes de larga duración, reconocible de inmediato. Tú describes la tarea, el modelo, las herramientas y el entorno de ejecución. OpenAI ejecuta todo lo demás. Eso incluye las partes que la mayoría de los equipos subestiman hasta que llevan meses desarrollando: mantener viva una sesión, gestionar una ventana de contexto que se desborda, reintentar pasos fallidos y coordinar un trabajo que tiene que sobrevivir más que un único ciclo de petición y respuesta.

Es un movimiento de productización tanto como técnico. OpenAI ya no es solo el proveedor de la inteligencia que usa un agente; ahora quiere ser el entorno de ejecución en el que vive el agente.

La parte que OpenAI vende en realidad

OpenAI ya ofrece piezas básicas en este terreno. La Responses API permite a los desarrolladores combinar modelos con capacidades integradas como la búsqueda web, la búsqueda de archivos y el uso del ordenador, y el Agents SDK ayuda a definir y orquestar flujos de trabajo de agentes. Lo que esas herramientas dejan en tus manos es la infraestructura que rodea al modelo: el entorno de ejecución, la gestión de sesiones, los reintentos, el ciclo de vida de los sandboxes y el estado.

La Agents API absorbe esa capa en un servicio gestionado. Como informa Anirban Ghoshal, de InfoWorld, el servicio empaqueta la orquestación, la gestión del contexto y la infraestructura de ejecución en una sola API, con OpenAI alojando y manteniendo el harness. La propuesta de valor a la que los analistas vuelven una y otra vez es una reducción de la complejidad de ingeniería: sin cola, sin base de datos de estado, sin flota de sandboxes, sin rutina de compactación y sin política de reintentos que un equipo tenga que mantener y por la que recibir alertas.

Según la documentación de la API, el harness gestionado permite:

• Ejecutar comandos y código en un sandbox.
• Aplicar habilidades e instrucciones relevantes.
• Conectarse a datos externos mediante herramientas o servidores MCP.
• Guiar al agente mientras trabaja.
• Resumir el trabajo anterior para gestionar su ventana de contexto.
• Dividir el trabajo en subtareas y delegarlas en subagentes.
• Retomar una sesión donde se quedó.

Las aplicaciones siguen aportando las herramientas y eligiendo dónde se ejecuta el trabajo. Todo lo que queda por encima de esa línea es ahora problema de OpenAI.

La distinción entre un framework y un servicio gestionado es la clave. El Agents SDK, disponible desde marzo de 2025, ofrece a los desarrolladores un conjunto de bibliotecas para ejecutarlas por su cuenta. La Agents API es la contraparte alojada: un servicio en el que el proveedor opera el bucle. Los frameworks cambian flexibilidad por control; los entornos de ejecución gestionados cambian control por menos código que mantener. Lo que OpenAI dice explícitamente es que este es el mismo harness que usa internamente (no una reimplementación solo para desarrolladores), lo que es una afirmación significativa sobre su rodaje, incluso si las limitaciones de la beta que se describen abajo significan que todavía no es un sustituto equivalente para cualquier carga de trabajo.

Sesiones que persisten, contexto que se compacta solo

La API se organiza en torno a cuatro conceptos, según la documentación: el agente (modelo, instrucciones, herramientas y servidores MCP), el entorno (un sandbox opcional para archivos, comandos y habilidades), la sesión (una instancia de agente duradera que responde a nuevas entradas) y los eventos e ítems (las entradas enviadas y las salidas producidas).

La durabilidad es el titular. Una sesión puede durar minutos, horas o días, y OpenAI conserva el estado para que los desarrolladores puedan continuar el trabajo entre turnos sin reconstruir el contexto de la conversación. La compactación del contexto es automática: a medida que una sesión se acerca a su límite, el contenido anterior se condensa sin que el desarrollador tenga que escribir lógica de compactación. Cuando se activa el modo multiagente, la compactación se aplica de forma independiente al agente raíz y a cada subagente para que sus contextos no interfieran.

La coordinación de subagentes sigue el mismo patrón gestionado. El agente raíz puede generar subagentes, encomendarles tareas acotadas, esperar los resultados y sintetizar una respuesta final; el análisis de Simon Carter señala un max_concurrent_subagents predeterminado de tres como punto de partida recomendado. Una sesión también puede retomarse tras un fallo, eliminarse cuando ya no se necesita o guiarse a mitad de turno mientras trabaja, algo que importa para cualquier cosa que toque sistemas de producción.

La guía de inicio rápido concreta la forma: un asistente de programación que escribe tree.py, lo ejecuta e informa de un árbol de directorios, con OpenAI gestionando el agente, su conversación y el sandbox. El primer ejemplo funcional es una sola llamada al SDK.

En lo operativo, las aplicaciones siguen una sesión transmitiendo la salida o suscribiéndose a webhooks, de modo que saben cuándo termina un agente o necesita información en lugar de sondear a ciegas. La documentación advierte de que un turno completado no garantiza que todas las herramientas hayan funcionado (los eventos que terminan en turn.failed, turn.cancelled o session.failed indican fallo o cancelación) y de que una transmisión desconectada debería recuperarse obteniendo primero los ítems guardados de la sesión antes de reintentar. Esa orientación recuerda que gestionar un agente de larga duración tiene tanto que ver con el manejo de fallos como con la calidad del modelo, que es precisamente el trabajo que OpenAI ahora ofrece absorber.

Tres lugares donde ejecutar el trabajo

El entorno de ejecución es una de las pocas decisiones que la API sí deja al desarrollador, y hay tres opciones:

1. Un sandbox alojado por OpenAI, la misma infraestructura de sandbox que hay detrás de Codex, configurable con archivos, paquetes, habilidades y plugins, y facturada a las tarifas estándar de contenedores.
2. Un sandbox autoalojado, ejecuta codex exec-server dentro de tu propio entorno. Se registra con una clave restringida y se conecta hacia el exterior por WebSocket, de modo que no hay que abrir ningún puerto de entrada.
3. Sandboxes de socios, Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop y Vercel son compatibles, lo que permite a las empresas mantener el cómputo dentro de su propia VPC y elegir su propio enfoque para archivos, secretos y configuración.

El propio harness es además de código abierto a través del repositorio de Codex, según el informe de Carter, de modo que los equipos pueden inspeccionar cómo funciona sea cual sea el entorno de ejecución que elijan.

La economía: sin tarifa por el harness

El precio es inusualmente sencillo, y es la parte con más probabilidades de impulsar las decisiones de adopción. OpenAI no cobra ninguna tarifa adicional por la propia Agents API. El uso de modelos se factura a las tarifas estándar de la API del modelo elegido, las herramientas de OpenAI usan sus tarifas estándar y los sandboxes alojados por OpenAI se facturan a las tarifas estándar de contenedores. El cómputo que ejecutas tú mismo, o que encargas a un proveedor asociado, lo factura quien lo opere.

Para los equipos que sopesan construir o comprar, eso elimina una fuente habitual de dudas: no hay un impuesto separado por el harness que de otro modo habría que justificar frente al coste de desarrollar el entorno de ejecución internamente. La contrapartida es que, una vez que las piezas gestionadas están en su sitio, reemplazarlas es una tarea más pesada que cambiar un endpoint de modelo.

Los límites que importan: residencia solo en EE. UU. y sin ZDR

Las restricciones de la beta no son notas a pie de página. Durante la beta pública, la residencia de datos es solo en EE. UU., y el servicio no admite la retención cero de datos (ZDR), una limitación que se aplica incluso cuando un equipo aporta su propio sandbox autoalojado. OpenAI no ha dado un calendario público para ampliar la residencia.

Esa combinación es un obstáculo real para una gran parte del mercado. Las cargas de trabajo sanitarias, financieras, jurídicas y europeas dependen a menudo de mantener los datos en una jurisdicción concreta y de garantías contractuales de que las peticiones y las salidas no se conservan. InfoWorld cita a analistas que señalan exactamente esto: uno observa que la laguna de ZDR podría limitar la adopción en sectores regulados y otro que los equipos con sede en la UE tienen una restricción dura que comprobar antes de planear cualquier migración. Las startups, las empresas de SaaS y las compañías que ya se han estandarizado en OpenAI son, en cambio, los primeros usuarios más probables.

La competencia y la cuestión del lock-in

El entorno de ejecución de agentes gestionado ya es una categoría abarrotada, lo que importa porque cambia el enfoque de «¿puede OpenAI hacer esto?» a «¿por qué elegir la versión de OpenAI?».

• Claude Managed Agents de Anthropic está en beta pública desde abril de 2026.
• Amazon Bedrock AgentCore de AWS alcanzó la disponibilidad general para su harness gestionado en junio de 2026 y realiza el mismo tipo de trabajo (el bucle, la ejecución de herramientas, el contexto, el estado y la recuperación) a la vez que permite a los clientes usar cualquier modelo y cambiar de proveedor a mitad de sesión sin perder el contexto.
• Foundry Agent Service de Microsoft y LangGraph se sitúan en el mismo vecindario, según InfoWorld.

La diferencia competitiva es la portabilidad. Un harness gestionado que es favorable a varios modelos reduce el coste de cambiar; uno que está atado a los modelos, la gestión del contexto, las herramientas, la orquestación y el entorno de ejecución de un único proveedor lo eleva. Los analistas citados por InfoWorld señalan el lock-in como la mayor preocupación, y apuntan que una dependencia más profunda puede debilitar la posición negociadora de una empresa en cuanto a precios y condiciones. Las empresas que siguen estrategias multimodelo pueden preferir un harness independiente o un reparto híbrido.

Acceso y un reloj de migración

El acceso está abierto a cualquier desarrollador. Crear una clave de API de aplicación requiere api.agents.read y api.agents.write para las operaciones de sesión, además de api.responses.write para la inferencia del modelo. Las peticiones llevan la cabecera OpenAI-Beta: agents=v1; los SDK oficiales la añaden automáticamente para quienes usan una biblioteca cliente en lugar de cURL.

También hay una fecha límite ligada al cambio más amplio. OpenAI retira Agent Builder y Evals el 30 de noviembre de 2026, orientando los flujos de trabajo basados en código hacia el Agents SDK y la Agents API. Los equipos que usan cualquiera de las dos herramientas tienen una ventana finita para planear una migración, y la llegada de la API gestionada les da un destino hacia el que moverse, o un motivo para replantearse el enfoque por completo.

Qué hay que observar

• Residencia y retención. Si OpenAI añade residencia regional de datos o una vía de ZDR es la restricción que más probablemente determine la adopción empresarial. No se ha dado ningún calendario, así que conviene vigilar la documentación de controles de datos de la API.
• El coste real a escala. «Sin tarifa por el harness» suena limpio en una página de precios. La cifra que importa es el coste total una vez sumadas las sesiones de larga duración, las horas de contenedor de los sandboxes y el consumo de tokens, sobre todo frente a los entornos autoalojados y de socios.
• La portabilidad de modelos. Si la Agents API admite modelos más allá de los de OpenAI, o permite cambiar de proveedor a mitad de sesión como anuncia Bedrock AgentCore, decidirá cuánto lock-in aceptan realmente los equipos.
• La retirada del 30 de noviembre. Conviene ver con qué rapidez se encauza a los usuarios de Agent Builder y Evals hacia el Agents SDK y la Agents API, y si las rutas de migración se sostienen.
• La presión competitiva. Con Anthropic y AWS ya ofreciendo entornos gestionados comparables, hay que ver si OpenAI compite por funciones, precio o apertura, y si la postura de «sin tarifa adicional» sobrevive a la disponibilidad general.

Imagen de portada: desarrolladores trabajando en portátiles durante un evento de programación. Foto de Matthew (WMF), vía Wikimedia Commons, CC BY-SA 3.0.