Construcción de Agentes con Estado con la API Responses de OpenAI: Una Guía Práctica

Conclusiones clave

• La API Responses es la primitiva de API recomendada por OpenAI para todos los proyectos nuevos, y la API Assistants se retiró el 26 de agosto de 2026 — la ventana de migración está cerrada; Chat Completions sigue siendo compatible, pero no es donde aterrizan primero las nuevas capacidades agénticas.
• Las evaluaciones internas de OpenAI muestran una mejora del 3% en SWE-bench y una mejor utilización de caché de 40–80% frente a Chat Completions cuando se usan modelos de razonamiento como GPT-6 Astra a través de la API Responses — el bucle agéntico no es solo conveniencia, mejora mediblemente la calidad de salida.
• Los servidores MCP remotos son un tipo de herramienta de primera clase en la API Responses — conectas cualquier servidor MCP con un server_url y server_label, y el modelo descubre y llama sus herramientas dentro de la misma solicitud, sin orquestación personalizada.
• El monitor de desalineación de GPT-6 Astra detiene las tareas de API directamente cuando detecta comportamiento no autorizado — no hay ruta de reanudación; el flujo de trabajo debe ser recuperable desde estado durable, lo cual es la restricción arquitectónica más importante para la adopción en producción.
• El modo con estado es aproximadamente 2x más lento que Chat Completions sin estado según múltiples informes de desarrolladores — la conveniencia de previous_response_id viene con un impuesto de latencia que importa para flujos orientados al usuario sensibles a la latencia.

La API Responses de OpenAI es la primitiva de API recomendada por la empresa para todo desarrollo nuevo, y la API Assistants se retiró oficialmente el 26 de agosto de 2026. Chat Completions sigue siendo compatible, pero la API Responses es donde las nuevas capacidades agénticas — herramientas integradas, conversaciones con estado, MCP remoto, modo en segundo plano, dirección mid-turn — aterrizan primero. Para un equipo que construye agentes en producción sobre GPT-6 Astra, la pregunta ya no es si migrar, sino cómo arquitecturar alrededor del modelo de estado de la API, sus características de latencia y las restricciones de gobernanza que impone el monitor en tiempo de ejecución de Astra. Esta guía mapea las cinco capacidades que importan, las tres decisiones que determinan la adopción y el patrón arquitectónico que mantiene tu agente portable entre proveedores.

Qué cambia la API Responses

La API Chat Completions es sin estado: envías el historial completo de conversación con cada solicitud, y la API devuelve un único mensaje. La API Responses introduce tres cambios estructurales que afectan cómo construyes agentes.

Items en lugar de mensajes. Chat Completions devuelve un array de choices, cada uno conteniendo un message. La API Responses devuelve un array de Items de output, donde cada Item es una unión tipada — un message, un function_call, un function_call_output, un resumen de razonamiento o una llamada a herramienta. Esto no es cosmético: significa que las llamadas a herramientas, el razonamiento y el texto son objetos de primera clase en la respuesta, no campos pegados a un mensaje. Cuando encadenas respuestas con previous_response_id, la API preserva todos los tipos de Item — incluyendo razonamiento cifrado — entre turnos, lo que hace que los flujos de trabajo agénticos multi-turno funcionen sin repetición manual del contexto.

Un bucle agéntico en una solicitud. La API Responses está diseñada como un bucle agéntico: el modelo puede llamar múltiples herramientas — web_search, file_search, computer_use, code_interpreter, image_generation, servidores MCP remotos y funciones personalizadas — dentro de una sola llamada a la API, iterando hasta alcanzar una condición de parada. Con Chat Completions, implementas este bucle tú mismo: llamas al modelo, analizas la llamada a herramienta, la ejecutas, añades el resultado, llamas de nuevo. La API Responses ejecuta el bucle del lado del servidor. Las evaluaciones internas de OpenAI muestran una mejora del 3% en SWE-bench con el mismo prompt y configuración cuando se usan modelos de razonamiento a través de la API Responses, además de 40–80% mejor utilización de caché — el bucle del lado del servidor se beneficia de aciertos de caché que un bucle manual no puede replicar.

Contexto con estado vía previous_response_id. En lugar de enviar el historial completo con cada solicitud, pasas el ID de la respuesta anterior y la nueva entrada del usuario. La API reconstruye el contexto del lado del servidor, incluyendo los items de razonamiento. Las respuestas se almacenan por defecto durante 30 días; cualquier respuesta adjunta a una conversación persiste sus items sin TTL. Puedes desactivar el almacenamiento con store: false para flujos de trabajo de cero retención de datos, pero entonces debes repetir manualmente el historial completo de Items — incluyendo los items de razonamiento cifrado — para preservar el contexto de razonamiento entre turnos.

Las cinco capacidades que importan

Las capacidades de la API Responses se mapean a cinco decisiones arquitectónicas, cada una con una contrapartida concreta:

1. previous_response_id: encadenamiento con estado

El patrón con estado más simple encadena respuestas por ID:

from openai import OpenAI
client = OpenAI()

first = client.responses.create(
    model="gpt-6-astra",
    input="What is the capital of France?",
    store=True,
)

second = client.responses.create(
    model="gpt-6-astra",
    previous_response_id=first.id,
    input="And its population?",
    store=True,
)

La segunda llamada no reenvía la primera pregunta ni respuesta. La API reconstruye el contexto completo desde la respuesta almacenada, incluyendo cualquier razonamiento que el modelo haya realizado. Este es el patrón para agentes conversacionales, asistentes de investigación y cualquier flujo donde el seguimiento del usuario dependa de turnos anteriores.

La contrapartida es la latencia. Múltiples informes de desarrolladores en el foro comunitario de OpenAI y Microsoft Q&A indican que la ruta con estado es aproximadamente 2x más lenta que Chat Completions sin estado — 1 segundo frente a 0.5 segundos en casos típicos, y hasta 9x más lenta (2.9 segundos frente a 0.3 segundos) bajo carga. Para un agente de investigación en segundo plano que funciona durante minutos, esto es irrelevante. Para un chat orientado al usuario que debe responder en menos de 500ms, el impuesto de latencia puede justificar quedarse en Chat Completions con gestión manual del contexto.

2. Servidores MCP remotos como herramienta integrada

La API Responses soporta servidores MCP remotos como tipo de herramienta de primera clase. Registras un servidor por URL, y el modelo descubre sus herramientas y las llama dentro del bucle agéntico:

response = client.responses.create(
    model="gpt-6-astra",
    tools=[{
        "type": "mcp",
        "server_label": "inventory",
        "server_description": "NetSuite inventory and pricing lookups",
        "server_url": "https://your-mcp-server.example.com/mcp",
        "require_approval": "never",
    }],
    input="Check stock levels for SKU A100-23 and suggest a reorder quantity.",
)

El campo require_approval controla si el modelo necesita aprobación humana antes de llamar a las herramientas del servidor. Para despliegues en producción, las opciones de filtrado de herramientas MCP — allowed_tools para listar herramientas específicas por nombre, y políticas de aprobación personalizadas por herramienta — son la capa de gobernanza que evita que el modelo llame operaciones destructivas sin autorización explícita.

Esta es la capacidad más relevante para el patrón de integración de IdeaBosque. Un módulo MCP personalizado que envuelve las APIs de NetSuite, HubSpot o BigCommerce puede registrarse como servidor MCP remoto en una llamada a la API Responses, y el modelo lo usa de la misma forma que usa web_search o code_interpreter. La capa semántica — esquemas tipados, logs de auditoría, gestión de rate-limit — vive en el módulo MCP, no en el prompt. La API Responses no resuelve el problema de la capa semántica; hace del módulo MCP el punto de integración natural. Para un tratamiento más profundo de ese patrón, ver MCP Module Code Standard.

3. Modo en segundo plano para tareas de larga duración

El modo en segundo plano desacopla la llamada al modelo de la conexión del cliente. La API acepta la solicitud, devuelve un ID de respuesta inmediatamente y ejecuta el trabajo del modelo de forma asíncrona. Sondeas el estado o recibes los resultados en streaming según llegan:

resp = client.responses.create(
    model="gpt-6-astra",
    input="Analyze all 200 RFQs from last week and categorize by supplier risk tier.",
    background=True,
)

while resp.status in {"queued", "in_progress"}:
    sleep(2)
    resp = client.responses.retrieve(resp.id)

print(resp.output_text)

Para agentes de horizonte largo — síntesis de investigación, análisis por lotes de documentos, flujos de aprovisionamiento multi-paso — el modo en segundo plano es el patrón que sobrevive a caídas de red y timeouts del cliente. Una respuesta en segundo plano que tarda seis minutos no depende de una conexión HTTP viva; si el cliente se desconecta, el trabajo continúa, y te reconectas con una reanudación por streaming usando el último número de secuencia.

El problema operativo es que el modo en segundo plano no es una cola de jobs. Como un análisis lo expresa: la API ejecuta la llamada al modelo, pero tu aplicación sigue siendo dueña del estado del job — lo que la UI muestra, cómo evitar procesar un webhook dos veces, cuándo cancelar trabajo que ya no importa. Para producción, necesitas un sistema de jobs durable alrededor de la respuesta en segundo plano, no solo el ID de respuesta. Este es el mismo patrón descrito en Long-running Agent Patterns: el runtime del agente, no la API del modelo, es la capa de fiabilidad.

4. Razonamiento cifrado para flujos de cero retención de datos

Cuando store: false, la API no persiste la respuesta, pero devuelve items de razonamiento cifrado en la salida. Pasas estos items de vuelta en la entrada de la siguiente solicitud para preservar el contexto de razonamiento entre turnos sin almacenar nada en los servidores de OpenAI. Este es el patrón para entornos regulados donde la retención de datos está prohibida — sistemas de alto riesgo del EU AI Act, flujos de salud bajo HIPAA, flujos de defensa bajo ITAR.

La contrapartida es que tú te conviertes en el almacén de estado. Debes serializar, almacenar y repetir el array completo de Items — incluyendo los blobs opacos de razonamiento cifrado — en cada turno. Si pierdes los items de razonamiento cifrado, el modelo pierde su contexto de razonamiento y la calidad de salida se degrada. Esta es la misma carga de gestión de estado que Chat Completions, pero con un tipo de item adicional que gestionar.

5. El monitor de parada de tareas Astra

GPT-6 Astra incluye monitorización de desalineación en cada solicitud que usa herramientas. Cuando el monitor detecta comportamiento potencialmente no autorizado, la respuesta del modelo incluye una señal de parada. En ChatGPT y Codex, el usuario ve una tarea pausada para revisar. En la API, la tarea se detiene directamente — no hay ruta de reanudación.

Para agentes en producción construidos sobre la API Responses, esta es la restricción arquitectónica más importante. Una tarea que se ejecuta durante horas a través de cadenas de previous_response_id o modo en segundo plano puede ser terminada a mitad de vuelo por un clasificador. Tu flujo de trabajo debe ser recuperable desde estado durable — cada llamada a herramienta, cada resultado intermedio, cada salida parcial debe persistirse en tu propio almacén antes de la siguiente llamada a la API. Si el monitor detiene la tarea en el paso 47 de 50, necesitas poder reanudar desde el paso 47, no reiniciar desde cero.

El director científico de OpenAI, Jakub Pachocki, reveló en An Alien Mind (6 de septiembre de 2026) que la capacidad de la empresa para depender de la monitorización de la cadena de pensamiento está "progresivamente disminuyendo" — los modelos son mejores razonando sobre y manipulando su propio proceso de razonamiento, y el preentrenamiento mejorado hace que los modelos sean más inteligentes incluso sin razonamiento verbalizado. El monitor que detiene tu tarea es la mejor capa de ejecución en tiempo de ejecución disponible, pero su proveedor ha dicho que la señal de la que depende se está degradando. Para un tratamiento más profundo de las capas de ejecución que no leen el razonamiento del modelo, ver GPT-6 Astra Ships the Runtime Kill Switch.

Las tres decisiones de adopción

Decisión 1: ¿Con estado o sin estado?

Usa store: true con previous_response_id cuando tu flujo sea conversacional, multi-turno y tolerante a la latencia. Usa store: false con repetición manual de Items cuando tu flujo requiera cero retención de datos o cuando necesites control total sobre la gestión del contexto. La diferencia de latencia es aproximadamente 2x — aceptable para agentes en segundo plano, potencialmente inaceptable para chat orientado al usuario.

Decisión 2: ¿Herramientas integradas o funciones personalizadas?

Las herramientas integradas (web_search, file_search, code_interpreter, computer_use, image_generation, MCP remoto) se ejecutan del lado del servidor y se benefician de la optimización de caché del bucle agéntico. Las funciones personalizadas requieren que implementes el bucle de llamadas a herramientas tú mismo. La regla práctica: usa herramientas integradas para capacidades que OpenAI proporciona mejor de lo que tú puedes (búsqueda web, ejecución de código), y usa servidores MCP remotos para tus propias integraciones de sistema (NetSuite, HubSpot, BigCommerce). Usa funciones personalizadas solo para capacidades que no pueden exponerse como un servidor MCP.

Decisión 3: ¿Solo OpenAI o flexible en modelos?

La API Responses es una primitiva de OpenAI. Si construyes tu agente enteramente sobre previous_response_id y herramientas integradas, estás bloqueado al almacén de estado y ecosistema de herramientas de OpenAI. Si tu requisito de producción incluye flexibilidad de modelos — enrutando a modelos open-weight como Qwen3.8-27B para tareas sensibles al coste, o a Claude para capacidades específicas — necesitas una capa de abstracción que traduzca entre el modelo de Items de la API Responses y el formato de mensajes de Chat Completions que otros proveedores usan.

Esta es la decisión arquitectónica que determina si la API Responses es todo tu runtime de agente o un backend entre varios. Una construcción flexible en modelos mantiene el bucle del agente en tu propio runtime, usa la API Responses cuando sus capacidades justifican la latencia y el bloqueo, y recurre a Chat Completions o inferencia open-weight cuando no lo justifican. La economía de inferencia es clara: el 29% del volumen de tokens en producción ya se ejecuta en modelos open-weight con menos del 4% del gasto. La disciplina de enrutamiento es una realidad de producción, no un plan futuro.

Checklist de migración

La guía de migración de OpenAI proporciona el checklist completo. Las decisiones que afectan la arquitectura, no solo el código:

• Decide tu modelo de estado. previous_response_id, repetición manual de Items, o la API Conversations. Esto determina tu perfil de latencia y tu postura de retención de datos.
• Audita tus definiciones de funciones. Las funciones personalizadas migran tal cual, pero las salidas de llamadas a funciones deben incluir el call_id correcto. Descartar items de razonamiento o de llamadas a funciones al transportar contexto manualmente es el error de migración más común.
• Mueve los esquemas de Structured Outputs de response_format a text.format — el nombre del campo cambió.
• Añade persistencia de estado durable para cualquier flujo que se ejecute más de unos segundos. El monitor de parada de tareas Astra puede terminar una tarea larga sin ruta de reanudación; tu almacén de estado es el mecanismo de recuperación.
• Compara latencia, uso de tokens y tasas de error antes de enrutar tráfico de producción. La mejora del 3% en SWE-bench y la mejora de caché del 40–80% son promedios; tu carga de trabajo puede diferir.
• Mantén un fallback de Chat Completions si la flexibilidad de modelos importa. La API Responses es solo de OpenAI; otros proveedores hablan Chat Completions.

Lecturas relacionadas

• GPT-6 Astra Ships the Runtime Kill Switch — el paquete de ejecución y la revelación de monitorabilidad que determinan cómo arquitecturar alrededor de la restricción de parada de tareas
• Inference Economics: Why Always-On Production Agents Are Now Affordable — los datos de coste detrás de la decisión de enrutamiento flexible en modelos, incluyendo el ratio 29% open-weight / 4% gasto
• Long-running Agent Patterns: Keeping Agents Alive Across Hours and Days — los patrones de estado durable y recuperación que el monitor de parada Astra hace obligatorios

---

Un distribuidor de mid-market que ejecuta NetSuite y BigCommerce quiere añadir un agente que monitorice los RFQ entrantes, verifique inventario y precios por nivel, y redacte respuestas de cotización. La API Responses con un servidor MCP remoto envolviendo el módulo conector de NetSuite es el camino más rápido a un prototipo funcional — una llamada a la API, bucle de herramientas integrado, sin orquestación personalizada. Pero la arquitectura de producción necesita la capa de enrutamiento flexible en modelos (modelos open-weight para el 60% del volumen de inferencia al 4% del coste), el almacén de estado durable (el monitor Astra puede detener una tarea larga de análisis de RFQ a mitad de vuelo), y la capa semántica en el módulo MCP (esquemas tipados, logs de auditoría, gestión de rate-limit que la API Responses no proporciona). Esa es la construcción que evaluamos: la API Responses como un backend de ejecución, los módulos MCP como capa de integración, tu runtime como capa de fiabilidad y enrutamiento.

Solicita una construcción evaluada. Discovery de una semana. Obtienes un inventario de sistema, mapa de flujos y alcance fijo — construyas con nosotros o no.