OpenAI Agents API vs Agents SDK vs Responses API: ¿Sobre qué deberías construir en 2026?

El stack de agentes de OpenAI cambió sustancialmente en septiembre de 2026. La nueva Agents API introdujo un harness de Codex gestionado para agentes duraderos en la nube, mientras que el Agents SDK anterior pasó a una fase de mantenimiento con funcionalidad completa. La Responses API sigue siendo la superficie de nivel inferior para aplicaciones que requieren llamadas directas al modelo o gestionar el bucle del agente por sí mismas. No son tres wrappers intercambiables sobre lo mismo: sitúan el límite del runtime en lugares distintos.

La arquitectura ha cambiado: elija un límite de runtime, no una biblioteca

La decisión importante ya no es simplemente: «¿Qué SDK debo instalar?». Se trata de quién controla el harness, el bucle del agente, el estado duradero de la sesión, la compactación del contexto, la recuperación, el entorno de ejecución y el ciclo de vida de la aplicación.

La descripción general actual de Agents de OpenAI hace explícito este límite. La Agents API ejecuta un harness de Codex alojado y gestiona la orquestación además del estado de sesión duradero. La Responses API proporciona respuestas del modelo y capacidades alojadas mientras su aplicación gestiona el bucle del agente circundante. El Agents SDK ejecuta el bucle en su aplicación y ahora está en estado de funcionalidad completa (feature complete) en lugar de ser la vía a seguir para nuevas características importantes de agentes.

Comparativa resumida

1. Agents API: harness gestionado, agente duradero en la nube

La Agents API expone el harness de Codex a través de un servicio gestionado por OpenAI. OpenAI gestiona las sesiones, la orquestación, la compactación del contexto y la recuperación. Su aplicación sigue proporcionando herramientas y eligiendo el entorno de ejecución.

Esa última distinción es importante. «Agente gestionado» no significa necesariamente que «todo el cómputo se ejecute dentro de OpenAI». La arquitectura de la Agents API admite no tener entorno, un entorno alojado por OpenAI o un entorno autohospedado conectado al harness gestionado. Con un entorno autohospedado, su aplicación asume el aprovisionamiento, la reconexión, el apagado y los archivos persistentes, mientras que el harness permanece gestionado.

Por lo tanto, la Agents API es un servicio de runtime, no un simple formato de solicitud. Las sesiones pueden persistir, transmitir el progreso en tiempo real, recibir tareas adicionales, usar herramientas, trabajar con archivos y recuperarse a lo largo de trabajos de ejecución prolongada.

Qué se obtiene con la Agents API

• Un harness de Codex gestionado en lugar de construir y operar el bucle principal del agente por su cuenta.
• Sesiones duraderas para tareas que abarcan múltiples turnos y procesos de larga duración.
• Orquestación gestionada, compactación de contexto y recuperación.
• Entornos de ejecución alojados en OpenAI o autohospedados, según los requisitos de la carga de trabajo.
• Streaming y webhooks para el seguimiento del progreso y eventos del ciclo de vida.
• Una dirección de plataforma que OpenAI recomienda explícitamente para nuevas aplicaciones de agentes.

Qué sigue bajo su control

• Su producto y servidor de aplicaciones.
• Implementaciones de herramientas de funciones y lógica de negocio.
• Decisiones de autorización y políticas relativas a sus propios sistemas.
• El ciclo de vida del entorno de ejecución al optar por cómputo autohospedado.
• Evaluación, criterios de aceptación, barreras de seguridad (guardrails) específicas del dominio y la decisión sobre qué tiene permitido hacer el agente.

2. API Responses: controle el bucle, use las primitivas de la plataforma

La API Responses es la opción de menor nivel cuando desea las capacidades de modelos y herramientas de OpenAI sin delegar el entorno de ejecución general del agente. OpenAI describe Responses como la primitiva de API recomendada para nuevos proyectos y como una evolución de Chat Completions con herramientas integradas, opciones de estado multiturno, entrada multimodal y uso agéntico de herramientas.

Una solicitud a Responses puede invocar herramientas por sí misma, pero su aplicación sigue siendo responsable del flujo de trabajo general cuando crea un agente a su alrededor. Eso significa que su código decide cómo persistir el estado de la aplicación, cuándo continuar, cómo recuperarse, cómo coordinar especialistas, cómo compactar historiales largos y cómo representar el trabajo reanudable.

Esto no es intrínsecamente inferior. Es el límite adecuado cuando el comportamiento del agente debe estar profundamente integrado en la lógica de la aplicación existente, cuando necesita un modelo de estado personalizado o cuando un entorno de ejecución administrado ocultaría un control que realmente necesita.

3. Agents SDK: con soporte, pero ya no es la vía predeterminada hacia el futuro

El Agents SDK sigue siendo un marco de código abierto para ejecutar flujos de trabajo de agentes en su aplicación. Proporciona definiciones de agentes, herramientas, transferencias (handoffs), barreras de seguridad (guardrails), trazado, sesiones y el bucle de ejecución en TypeScript y Python.

Pero su estatus estratégico cambió. OpenAI ahora califica el Agents SDK como completo en características (feature complete): el mantenimiento, las correcciones de seguridad, las correcciones de errores críticos y el trabajo de compatibilidad continúan, pero no se planean nuevas características importantes. OpenAI recomienda la API Agents para nuevas aplicaciones.

Eso no significa que una aplicación existente construida con el SDK deba reescribirse de inmediato. Significa que la arquitectura debe dejar de asumir que el SDK es donde llegarán las próximas capacidades importantes del entorno de ejecución de agentes.

Dónde encaja el Codex SDK

La elección actual no es una simple bifurcación de tres vías. La descripción general del entorno de ejecución de OpenAI incluye el Codex SDK como la opción para ejecutar el entorno de Codex en la infraestructura que usted opera. Eso es arquitectónicamente diferente tanto de la API Agents alojada como del Agents SDK.

Si su requisito real es «Quiero el entorno de Codex, pero necesito operarlo yo mismo», el Codex SDK es la superficie a evaluar. Si su requisito es «Quiero controlar el bucle alrededor de las llamadas al modelo», evalúe Responses. Si su requisito es «Ya tengo una aplicación funcional con Agents SDK», el SDK existente puede seguir siendo válido mientras planifica en función de su estado de mantenimiento.

La prueba de propiedad del entorno de ejecución

Una decisión de arquitectura útil comienza por determinar qué debe poseer su equipo. Califique cada requisito como: debe controlar, prefiere controlar o prefiere administrado.

Un árbol de decisión para nuevos sistemas

Qué no debería motivar la decisión

La migración es un cambio arquitectónico, no un renombramiento de importaciones

Pasar del Agents SDK a la Agents API cambia la titularidad. En el SDK, el bucle se ejecuta en tu aplicación. En la Agents API, OpenAI ejecuta el arnés y la sesión, mientras que tu aplicación se integra a través de tareas, eventos, herramientas y límites de entorno.

Por lo tanto, un plan de migración real debe mapear el estado de la sesión, la orquestación personalizada, los traspasos (handoffs), la ejecución de herramientas, las aprobaciones, el almacenamiento, el rastreo, los reintentos, la recuperación ante fallos, el ciclo de vida del entorno y cualquier abstracción específica del proveedor. El volumen de código puede disminuir mientras los supuestos operativos cambian.

El inventario de migración

• Definiciones de agentes y titularidad de las instrucciones.
• Definiciones de herramientas y dónde se ejecuta cada herramienta.
• Traspasos (handoffs), patrones de gestor/especialista y comportamiento de subagentes.
• Identificadores de sesión, estado de la conversación, capacidad de reanudación y retención del historial.
• Aprobaciones humanas y semántica de interrupción.
• Lógica personalizada de recorte o compactación de contexto.
• Rastreo (tracing), evaluaciones, observabilidad y depuración en producción.
• Archivos autohospedados, contenedores, acceso a redes privadas u otras dependencias de ejecución.
• Abstracción de proveedores o dependencias de modelos ajenos a OpenAI.
• Supuestos de reintento, tiempo de espera, idempotencia, recuperación y ciclo de vida.

La beta pública cambia el modelo de riesgo

La Agents API es la dirección recomendada para nuevas aplicaciones de agentes, pero también está en beta pública. Esos hechos no son contradictorios. La dirección estratégica responde a “¿hacia dónde va la plataforma?”. El estado beta responde a “¿cuánto cambio operativo y de interfaz debo presupuestar?”.

Para los sistemas en producción, aísla la integración detrás de un límite de la aplicación. Mantén el estado del dominio, los permisos, los datos de auditoría y las reglas de negocio fuera de los objetos de sesión específicos del proveedor siempre que sea posible. Esto facilita absorber la evolución de la API sin convertir el entorno de ejecución del agente en la fuente de verdad de todo tu producto.

Una arquitectura predeterminada práctica

Para muchas aplicaciones nativas de OpenAI nuevas, un valor predeterminado razonable para 2026 es: Agents API para el arnés gestionado y la sesión duradera, servicios de dominio y autorización propios de la aplicación, herramientas de función explícitas para acciones comerciales, y ejecución alojada en OpenAI o autohospedada según los requisitos de datos y cómputo.

Eso mantiene la potencia del entorno de ejecución del agente sin convertirlo en el propietario de la verdad del negocio. La aplicación sigue decidiendo qué puede hacer un usuario, qué datos son autoritativos, qué acciones requieren aprobación y cómo se validan los resultados.

¿Qué cambiaría esta respuesta?

La recomendación cambia si la Agents API añade o elimina capacidades, sale de la beta con contratos diferentes, cambia los límites de entorno o de precios, o introduce herramientas de migración que reduzcan las diferencias de titularidad. También cambia si tu aplicación depende de la portabilidad de proveedores, semánticas de orquestación personalizadas, ejecución exclusivamente local o una capacidad que el arnés alojado no pueda admitir.

Para una aplicación existente de Agents SDK, la respuesta también varía en función del coste de migración. Si el sistema es estable, está bien evaluado y no se ve bloqueado por el estado de funciones completas del SDK, la migración inmediata puede generar más riesgos que valor. Si la hoja de ruta del producto depende de capacidades que solo llegan a la Agents API, retrasar la migración puede generar un tipo diferente de deuda.

Limitaciones

Esta comparación se centra en la titularidad del entorno de ejecución y la dirección de la plataforma declarada por OpenAI. No evalúa la latencia, la calidad ni el coste total para una carga de trabajo específica. Esas propiedades dependen de la elección del modelo, el uso de herramientas, el entorno, la duración de la tarea, el almacenamiento en caché, el uso de sandboxes y la arquitectura de la aplicación.

La API de Agents también es lo suficientemente nueva como para que la experiencia en producción aún se esté acumulando. Por lo tanto, un diseño debe validarse con cargas de trabajo representativas en lugar de elegirse únicamente a partir del posicionamiento del producto.

Conclusión

La decisión sobre agentes de OpenAI en 2026 trata fundamentalmente sobre la propiedad del entorno de ejecución (runtime). La API de Agents significa que OpenAI asume una mayor parte del arnés y de la maquinaria de sesiones duraderas. Responses implica que su aplicación es propietaria del bucle en torno a las primitivas de la plataforma. El Agents SDK sigue siendo válido para los sistemas existentes, pero ya no es el destino predeterminado para las nuevas características importantes del runtime de agentes.

Para una aplicación nueva, siga la dirección de la plataforma a menos que un requisito real lo empuje hacia una capa inferior de la pila. Comience con la API de Agents, pase a Responses cuando necesite controlar el bucle, evalúe Codex SDK cuando necesite el arnés en su propia infraestructura y conserve el Agents SDK donde las inversiones existentes o las brechas temporales de capacidades lo justifiquen.

Preguntas frecuentes

Glosario

Fuentes principales y lecturas complementarias