El problema del contexto largo en agentes de IA

Cada modelo tiene una ventana de contexto finita. Por tanto, una conversación no puede crecer indefinidamente sin que llegue un momento en el que necesites eliminar, resumir o compactar información anterior.

Además, el problema no es únicamente técnico. Un contexto más grande puede aumentar el número de tokens procesados. Asimismo, cuanto más ruido incluyes, más difícil puede resultar mantener clara la tarea principal.

Tres formas de mantener estado con Responses API

No existe una única estrategia. La mejor opción depende de si quieres que OpenAI gestione el hilo, si necesitas control manual o si tu aplicación debe funcionar de manera stateless.

Cómo usar previous_response_id

Para una conversación lineal, previous_response_id es una de las formas más sencillas de continuar un turno anterior.

Primero creas una Response. Después, utilizas su ID en la siguiente petición. De esta forma, Responses API puede continuar la conversación sin que tengas que reconstruir manualmente todos los mensajes.

from openai import OpenAI

client = OpenAI()

first = client.responses.create(
    model="gpt-5.6",
    instructions="Eres un asistente técnico para una aplicación SaaS.",
    input="Mi cliente utiliza PostgreSQL y Redis."
)

second = client.responses.create(
    model="gpt-5.6",
    instructions="Eres un asistente técnico para una aplicación SaaS.",
    previous_response_id=first.id,
    input="¿Qué arquitectura de caché recomendarías?"
)

print(second.output_text)

Ventajas

Cuándo se queda corto

Si el producto necesita sesiones que sobreviven durante días, varias interfaces accediendo al mismo hilo o una gestión explícita de items, suele ser más natural utilizar Conversations.

Cómo utilizar Conversations API

Conversations API crea un objeto persistente al que puedes asociar diferentes Responses. Además, puedes añadir metadata para relacionar la conversación con tu propia aplicación.

Cuando una Response incluye el identificador de la Conversation, los items existentes se añaden al contexto de la petición. Después, los inputs y outputs nuevos se incorporan automáticamente a esa Conversation.

from openai import OpenAI

client = OpenAI()

conversation = client.conversations.create(
    metadata={
        "customer_id": "customer_482",
        "channel": "support"
    }
)

print(conversation.id)

response = client.responses.create(
    model="gpt-5.6",
    conversation=conversation.id,
    instructions=(
        "Ayuda al usuario con su cuenta. "
        "No inventes datos que no existan en el contexto."
    ),
    input="Estoy intentando configurar el webhook de pagos."
)

print(response.output_text)

next_response = client.responses.create(
    model="gpt-5.6",
    conversation=conversation.id,
    instructions=(
        "Ayuda al usuario con su cuenta. "
        "No inventes datos que no existan en el contexto."
    ),
    input="El endpoint ya responde 200. ¿Qué debería validar ahora?"
)

print(next_response.output_text)

Qué guarda realmente una Conversation

Una Conversation no debe imaginarse solamente como una lista de mensajes. Responses API trabaja con items, y esos items pueden representar diferentes partes de una ejecución.

Por tanto, un agente puede mantener más que texto. Según la operación, el contexto puede incluir mensajes, llamadas a herramientas, resultados y otros items compatibles con Responses API.

Qué es compaction en Responses API

Compaction está diseñada para conversaciones y flujos de larga duración. En lugar de seguir enviando un historial completo cada vez más grande, puedes ejecutar una pasada de compactación.

El endpoint actual es POST /responses/compact. El resultado contiene los mensajes de usuario correspondientes y un item de compaction con contenido cifrado.

Ese item es opaco. En consecuencia, tu aplicación no debería intentar interpretar su estructura interna ni convertirlo en una fuente de información para la interfaz.

Cuándo resulta útil

Cómo compactar una conversación paso a paso

El patrón general es sencillo. Primero conservas los items relevantes del flujo. Después, llamas al endpoint de compaction. Finalmente, reutilizas el output compacto como parte del siguiente input.

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-5.6",
    input="Diseña la arquitectura inicial de un CRM con agentes."
)

history = [
    {
        "role": "user",
        "content": "Diseña la arquitectura inicial de un CRM con agentes."
    },
    *[item.model_dump() for item in response.output]
]

compacted = client.responses.compact(
    model="gpt-5.6",
    input=history
)

compact_state = [
    item.model_dump()
    for item in compacted.output
]

next_response = client.responses.create(
    model="gpt-5.6",
    input=[
        *compact_state,
        {
            "role": "user",
            "content": "Ahora agrega facturación y permisos por equipo."
        }
    ]
)

print(next_response.output_text)

Context management automático en Responses API

Además del endpoint manual de compaction, la referencia actual de responses.create expone una configuración context_management.

Esta configuración incluye un umbral de compactación. Por tanto, la API puede ayudarte a definir cuándo debe intervenir la gestión de contexto en lugar de depender únicamente de lógica personalizada en tu backend.

Arquitectura recomendada para un agente de larga duración

Una buena arquitectura separa tres tipos de memoria. Primero, utiliza el contexto del modelo para el trabajo inmediato. Después, usa Conversations o estado equivalente para continuidad. Finalmente, guarda hechos duraderos en tu propia base de datos.

Qué debes conservar cuando el agente utiliza herramientas

Los agentes de producción no generan únicamente texto. También llaman APIs, consultan bases de datos y ejecutan acciones. Por eso, el contexto importante incluye resultados operativos.

Ejemplo

Si un agente creó una orden con ID ord_7281, ese identificador puede ser importante diez turnos después. En cambio, probablemente no necesitas conservar cada campo de la respuesta JSON original si ya guardaste la orden en tu base de datos.

Qué cambia con store:false o Zero Data Retention

Algunas aplicaciones no quieren depender del estado almacenado por Responses API. En ese caso, tu backend debe reenviar los items relevantes en los turnos posteriores.

La guía actual de modelos de OpenAI recomienda preservar los output items relevantes cuando administras el historial manualmente. Esto es especialmente importante en flujos de razonamiento y tools.

Compaction vs prompt caching: resuelven problemas diferentes

Prompt caching y compaction pueden parecer similares porque ambos ayudan con prompts grandes. Sin embargo, no hacen lo mismo.

Por tanto, una aplicación puede utilizar ambas estrategias. Puedes mantener un prompt estable que aproveche caching y, al mismo tiempo, compactar una conversación cuando su estado crece demasiado.

Por qué truncation no debería ser tu estrategia principal

Responses API todavía expone truncation en su referencia, aunque actualmente aparece como deprecado.

Con la opción automática, el sistema puede eliminar items del principio cuando el input supera la ventana disponible. El problema es que esos items antiguos pueden contener una decisión o ID que siga siendo crítico.