La Agents API de OpenAI cambia principalmente quién opera el bucle del agente. En lugar de que la aplicación mantenga por sí sola la secuencia de llamadas al modelo, el estado de la sesión, la compactación del contexto, la recuperación tras interrupciones y la coordinación de subagentes, ese trabajo pasa a un harness de Codex ejecutado y mantenido por OpenAI. La aplicación, sin embargo, sigue siendo responsable de definir qué puede hacer el agente, qué herramientas y datos recibe, cómo se presenta la experiencia al usuario y, según el entorno elegido, de la propia infraestructura de ejecución.
Esa división es la clave para evaluar la novedad. La Agents API no convierte toda la arquitectura de un producto en un servicio administrado: externaliza una capa específica —el runtime del agente— y mantiene el resto bajo control de la aplicación. OpenAI lanzó el recurso en beta pública el 10 de septiembre de 2026. La documentación oficial resume la frontera indicando que OpenAI gestiona sesiones, orquestación, compactación de contexto y recuperación, mientras que la aplicación aporta las herramientas y elige el entorno de ejecución. Consulte el anuncio oficial y la descripción general de la Agents API.
Respuesta corta: el harness queda gestionado; el producto no
La forma más clara de entender la Agents API es separar tres piezas: harness, entorno y servidor de la aplicación. El harness es la instancia de Codex alojada por OpenAI que ejecuta el modelo, coordina el bucle de herramientas y mantiene la sesión. El entorno es donde se manipulan comandos, código y archivos. El servidor de la aplicación es su código: inicia tareas, recibe eventos, conecta datos y herramientas y aplica las reglas del producto.
En la práctica, la Agents API puede eliminar una gran cantidad de código de unión para orquestación, pero no elimina decisiones de producto, seguridad, autorización, integración o infraestructura. Esa distinción aparece explícitamente en la documentación oficial de arquitectura.
Qué pasa al harness gestionado
El bucle del agente y la continuidad de la sesión
El harness llama al modelo, procesa el uso de herramientas, mantiene la sesión y permite que el trabajo continúe entre turnos. Las sesiones son duraderas: la aplicación puede volver al mismo contexto sin reconstruir manualmente todo el historial. La documentación también describe la recuperación y la reanudación del trabajo como parte del servicio gestionado.
Compactación del contexto
Cuando una sesión se acerca al límite de contexto, la Agents API puede compactar trabajo anterior para conservar lo necesario para continuar. Esto reduce la necesidad de implementar una capa propia de resúmenes, recorte de historial y reconstrucción de contexto en tareas largas. La calidad de las instrucciones, los datos proporcionados y la política de memoria de la aplicación siguen siendo responsabilidades del producto.
Coordinación de subagentes
El soporte multiagente permite dividir el trabajo en partes independientes y delegarlas a subagentes, cada uno con su propio contexto, mientras el agente raíz combina los resultados. Esto reemplaza buena parte del código que antes creaba workers, controlaba concurrencia y reconciliaba respuestas. El beneficio es mayor en investigación, análisis y programación, donde las subtareas pueden avanzar realmente en paralelo.
Selección y uso de herramientas dentro del bucle
El harness decide cuándo invocar herramientas ya configuradas y puede usar mecanismos como búsqueda de herramientas y llamadas programáticas. Admite herramientas integradas, MCP y funciones personalizadas. El matiz importante es que el harness gestiona el uso; la aplicación sigue definiendo las capacidades. Un servidor MCP remoto puede ser invocado directamente por el harness, pero las funciones de la aplicación siguen necesitando un handler propio que ejecute la acción y devuelva el resultado.
Ejecución en sandbox cuando se elige el entorno alojado
Con environment.type: "openai_hosted", OpenAI aprovisiona y administra el sandbox en el que el agente puede ejecutar código, editar archivos y producir artefactos. La aplicación sigue configurando los archivos, paquetes y acceso de red necesarios. Si el entorno es self-hosted, la frontera cambia: el harness sigue gestionado, pero la infraestructura deja de estarlo.
Comparación: quién se encarga de cada capa
| Capa | Agents API / harness | Aplicación |
|---|---|---|
| Bucle del agente | Ejecuta el ciclo de modelo, herramientas, continuidad y reanudación. | Define objetivos, instrucciones, límites y cuándo iniciar o detener el trabajo. |
| Contexto | Mantiene la sesión y realiza compactación automática cuando hace falta. | Decide qué datos entran, la política de retención del producto y el contexto de negocio. |
| Ejecución | Ejecuta comandos directamente en un sandbox alojado por OpenAI. | Elige el entorno; en self-hosted, aprovisiona, reconecta y apaga el compute. |
| Archivos | Trabaja con archivos disponibles en el entorno y puede producir artefactos. | Proporciona archivos y decide persistencia; en self-hosted, la preservación es suya. |
| Herramientas | Selecciona e invoca herramientas configuradas dentro del bucle. | Elige MCP, funciones e integraciones; los handlers de funciones siguen en la app. |
| Subagentes | Crea, coordina y sigue trabajo delegado cuando multiagente está habilitado. | Decide si usar multiagente, límites de concurrencia, tareas y políticas. |
| Observabilidad | Emite eventos, conserva historial, registra uso y ofrece traces en el dashboard. | Consume eventos/webhooks, integra alertas y convierte la telemetría en operación del producto. |
| Infraestructura | Puede administrar el sandbox alojado por OpenAI. | Sigue siendo responsable de infraestructura propia, red privada, UX, backend y sistemas externos. |
Qué sigue siendo responsabilidad de la aplicación
Lógica de producto y experiencia de usuario
La Agents API no decide cuándo debe existir una tarea, qué promesa hace el producto, cómo aparecen los resultados, qué confirmaciones son necesarias ni qué ocurre cuando el agente falla. Colas, pantallas, notificaciones, estados de UI, límites de sesión por usuario y decisiones de negocio siguen en la aplicación.
Permisos, seguridad y reglas de negocio
Dar al agente acceso a una herramienta no delega la política de autorización. La aplicación todavía debe decidir qué usuarios pueden activar qué acciones, validar parámetros, aplicar controles de acceso, exigir aprobaciones y limitar efectos secundarios. Para operaciones sensibles, el handler de la herramienta debe seguir siendo una frontera de seguridad, no un proxy ciego.
Herramientas, datos e integraciones
OpenAI opera el harness, pero no conoce automáticamente sus bases de datos, CRM, sistemas internos ni reglas de dominio. Usted debe exponer esas capacidades mediante MCP, funciones u otras integraciones y elegir qué puede ver el agente. En otras palabras, la Agents API sustituye la orquestación del uso de herramientas, no el trabajo de construir y gobernar las herramientas.
Infraestructura propia, cuando se utiliza
La Agents API admite entornos alojados por OpenAI, de socios y self-hosted. En modo self-hosted, su aplicación sigue siendo responsable del aprovisionamiento, reconexión, apagado y preservación de archivos que deban sobrevivir. La documentación recomienda esta vía cuando el agente necesita infraestructura privada, red interna o software especializado.
Operación del producto alrededor del agente
Los eventos y webhooks ayudan a seguir el trabajo, pero la aplicación todavía debe gestionar handlers no disponibles, experiencia de espera, idempotencia de acciones, reintentos en sistemas externos y políticas de cancelación. Si una función personalizada no responde, por ejemplo, la sesión puede quedar esperando su resultado. Un runtime gestionado no elimina la necesidad de ingeniería de sistemas distribuidos en el borde del producto.
La observabilidad mejora, pero no se convierte en una plataforma operativa completa
La Agents API expone eventos de sesión en tiempo real, historial guardado y uso registrado por turno, incluido el trabajo de subagentes. El dashboard de tracing muestra respuestas del modelo, llamadas a herramientas, duración y estado de los pasos. Esto reduce el esfuerzo necesario para entender qué ocurrió dentro del bucle y facilita depurar agentes complejos. Consulte la documentación de observabilidad y uso y de tracing.
Sin embargo, hay límites importantes en la beta pública: los traces detallados viven en el dashboard, la API pública no expone configuración de tracing ni exportadores externos, y la telemetría del agente todavía debe correlacionarse con logs, métricas y traces de su propio backend. Por eso, “observabilidad gestionada” significa buena visibilidad del runtime del agente, no sustitución automática de Datadog, Grafana, OpenTelemetry o un SIEM.
Cuándo la Agents API puede sustituir orquestación propia
- Tareas largas e iterativas: cuando el agente necesita muchos pasos, continuidad entre turnos y gestión del crecimiento del contexto.
- Uso intensivo de herramientas: cuando mantener manualmente el bucle de llamada, resultado y reanudación ya se volvió infraestructura repetitiva.
- Subtareas paralelizables: cuando los subagentes pueden dividir investigación, análisis, depuración o generación de artefactos.
- Necesidad de sandbox: cuando ejecutar código y trabajar con archivos forma parte natural de la tarea.
- Equipo que quiere reducir mantenimiento del harness: cuando seguir cambios de modelos, compactación y patrones de agentes no es un diferenciador del producto.
En estos casos, el intercambio es claro: se cede parte del control del runtime a cambio de menos código de orquestación y de un harness que OpenAI afirma que evolucionará junto con sus modelos.
Cuándo no sustituye su arquitectura
- Workflows deterministas: si el proceso es una máquina de estados estricta, una cola tradicional o una secuencia altamente auditable, un agente puede ser un componente, no el sustituto.
- Portabilidad entre proveedores: si evitar dependencia de un harness específico es un requisito central, mantener una capa propia puede ser deliberado.
- Control fino del compute: cargas con hardware especializado, redes privadas, compliance o aislamiento específico pueden seguir en self-hosted —y una parte relevante de la operación seguirá siendo suya.
- Políticas de autorización complejas: el runtime no sustituye los sistemas de identidad, políticas y aprobaciones del producto.
- Exportación obligatoria de traces: como la beta pública no ofrece exportadores de trace externos, equipos con requisitos estrictos de observabilidad pueden necesitar instrumentación adicional.
Criterios prácticos para decidir la adopción
- Liste el código que existe solo para mantener al agente funcionando. Si hay mucha lógica de bucle, estado, compactación, recuperación de sesión y subagentes, existe una fuerte superposición con el harness gestionado.
- Separe “orquestación del agente” de “orquestación del negocio”. La primera es candidata a migrar; la segunda normalmente debe seguir explícita en la aplicación.
- Elija el entorno antes de estimar el ahorro operativo. Con sandbox alojado también externaliza el compute de la sesión. Con self-hosted sigue operando la infraestructura.
- Mapee funciones y servidores MCP. Las herramientas remotas pueden encajar bien; las funciones locales y acciones con efectos secundarios siguen exigiendo handlers robustos y autorización propia.
- Mida el costo por tarea, no solo por llamada al modelo. Un agente puede realizar varias llamadas, usar subagentes, herramientas y compute de sandbox. En la beta de lanzamiento, la Agents API no tenía una tarifa adicional por el servicio, pero tokens, herramientas y contenedores siguen sus precios estándar.
- Revise requisitos de datos antes de producción. A 13 de septiembre de 2026, la documentación indica que la Agents API ofrece residencia de datos solo en Estados Unidos y no admite Zero Data Retention, incluso cuando el sandbox es self-hosted.
Conclusión: la nueva frontera está entre runtime y producto
La Agents API sustituye mejor la parte de la stack que existe para mantener al agente trabajando: bucle, sesión, contexto, recuperación, delegación e integración operativa con un entorno de ejecución. No sustituye la parte que existe para hacer que el producto sea correcto: lógica de negocio, UX, identidad, permisos, gobierno, integraciones, fiabilidad de handlers y decisiones de infraestructura.
Para equipos que ya construyeron un harness propio, la pregunta útil no es “¿podemos borrar nuestra orquestación?”, sino “¿cuánto de nuestra orquestación es runtime genérico y cuánto es comportamiento específico del producto?”. Cuanto mayor sea la primera parte, mayor será la probabilidad de que la Agents API simplifique la arquitectura. Cuanto mayor sea la segunda, más tenderá a entrar como una capa gestionada dentro de una aplicación que sigue explícitamente al mando.
