OpenAI Assistants API: agentes con estado sin infraestructura propia

Actualizado: 2026-05-03

La Assistants API de OpenAI, que va por su versión v2 tras un rediseño importante, es un intento consciente de empaquetar los patrones más comunes que cualquiera acaba reinventando cuando construye un agente: una conversación multi-turno que sobrevive entre sesiones, un mecanismo estructurado para que el modelo pida la ejecución de funciones, un intérprete de Python aislado y un sistema de recuperación sobre documentos propios. Todo ello sin que tengamos que montar una base de datos para el historial, un pipeline de embeddings o un sandbox de código. El coste de esa comodidad es renunciar a parte del control y firmar una dependencia clara con un proveedor concreto.

Puntos clave

• La abstracción Assistant + Thread + Run elimina la infraestructura necesaria para el estado de conversación y el historial — útil en prototipos y bots internos.
• File search (RAG gestionado) ahorra semanas de trabajo en casos simples; se queda corto cuando la calidad del retrieval es crítica.
• Code interpreter es un sandbox Python efímero — útil para analítica sobre datos del usuario, con latencia no trivial.
• Function calling es el punto donde el assistant deja de ser chat y se convierte en agente con capacidad real de actuar.
• Para tráfico alto, costo predecible o arquitectura multi-proveedor, Chat Completions con stack propio es la opción correcta.

El modelo conceptual

La abstracción central es el assistant: una configuración reutilizable con modelo (GPT-4o o GPT-4o mini), instrucciones como system prompt y lista de herramientas disponibles. Sobre ese assistant se crean threads (conversaciones individuales con sus mensajes). Para que el modelo procese el thread se lanza un run, cuyo estado transita entre queued, in_progress, requires_action, completed, failed, cancelled y expired. La distinción entre thread (datos) y run (ejecución) es deliberada: permite lanzar el mismo thread contra distintos assistants o reutilizar un assistant en miles de threads.

from openai import OpenAI

client = OpenAI()

assistant = client.beta.assistants.create(
    name="Soporte clientes",
    instructions="Eres un asistente de soporte amable y conciso.",
    model="gpt-4o",
    tools=[{"type": "code_interpreter"}, {"type": "file_search"}],
)

thread = client.beta.threads.create()

client.beta.threads.messages.create(
    thread_id=thread.id,
    role="user",
    content="Tengo un problema con mi pedido 12345",
)

run = client.beta.threads.runs.create_and_poll(
    thread_id=thread.id,
    assistant_id=assistant.id,
)

if run.status == "completed":
    messages = client.beta.threads.messages.list(thread_id=thread.id)

create_and_poll encapsula el patrón de crear el run y esperar a que termine. En producción, la variante de streaming emite eventos a medida que el modelo genera tokens — necesaria para interfaces fluidas.

Las tres herramientas que cambian el cálculo

Code interpreter arranca un sandbox efímero con Python y librerías habituales de análisis de datos. El assistant puede generar código, ejecutarlo y devolver resultados incluyendo archivos (PNG, CSV procesados). Útil para asistentes de analítica donde el usuario sube un Excel y pide conclusiones. Introduce latencia no trivial — arrancar el sandbox y ejecutar código tiene coste real.

File search es donde la API ahorra más trabajo. Subimos archivos, los asociamos a un vector store gestionado por OpenAI, y el modelo los consulta automáticamente cuando detecta que la pregunta lo requiere. OpenAI gestiona chunking, embeddings, índice y recuperación. Para bases documentales pequeñas o medianas con contenido homogéneo, evita montar pgvector o Pinecone, un pipeline de ingestion y toda la lógica de citación. Para casos serios, el file search se queda corto: sin control sobre el tamaño del chunk, estrategia de recuperación opaca, sin personalización del reranking. Ver RAG en producción: patrones que funcionan para cuándo se necesita el control total.

Function calling es el mecanismo por el que el modelo pausa su ejecución, declara que quiere invocar una función que hemos definido con su esquema JSON, y espera a que devolvamos el resultado. Cuando el run pasa a requires_action, leemos qué función pidió, la ejecutamos en nuestra infraestructura y enviamos la respuesta. Este es el punto donde el assistant deja de ser un chat y se convierte en un agente con capacidad real de actuar — conectar a nuestra base de datos, APIs internas, servicios externos.

Threads persistentes y el coste real

Que el thread sobreviva en los servidores de OpenAI es cómodo: el usuario vuelve tres días después, recuperamos el thread por su identificador y continuamos con todo el contexto anterior. No hay tabla de mensajes que mantener ni backup que orquestar. El truco es que ese historial se vuelve a enviar al modelo en cada run. A medida que la conversación crece, el coste por turno crece con ella.

El precio debe mirarse en su conjunto:

• Tokens de entrada/salida al precio estándar del modelo elegido.
• Code interpreter: 0,03 USD por sesión-hora.
• File search: 0,10 USD/GB-día de almacenamiento de vector store, más los tokens del contenido recuperado.

Para tráfico alto el total puede superar con holgura el coste de Chat Completions con RAG propio sobre pgvector — especialmente si los documentos ya están indexados para otros fines. La comparativa con modelos alternativos como Mistral Large es relevante si el control de costes es un requisito.

Cuándo conviene y cuándo no

La Assistants API brilla en:

• Prototipos que deben estar en manos de alguien no técnico en días.
• Bots internos de soporte sobre documentación que cabe en memoria.
• Asistentes de analítica donde el valor está en combinar lenguaje natural con ejecución de código.

En todos esos casos, el ahorro de no construir infraestructura compensa el lock-in.

Conviene evitarla cuando:

• La aplicación es seria y el tráfico es alto.
• La fiabilidad del RAG es crítica — el file search es una caja negra.
• Los costes necesitan ser predecibles al céntimo.
• La arquitectura contempla más de un proveedor de modelos.

En esos casos, Chat Completions con base vectorial propia, almacenamiento de conversaciones y orquestación en código da más control, más transparencia y más portabilidad. El patrón de multi-agente más controlado está descrito en CrewAI: equipos de agentes.

El patrón mixto que mejor funciona

Usar Assistants para iterar rápido en experimentos, bots internos y funcionalidades secundarias, y reservar el stack propio para el producto principal donde la diferenciación y el coste a escala exigen que cada decisión arquitectónica sea propia. La cuestión no es elegir un lado: es reconocer que estas dos opciones no compiten en el mismo terreno — una vende velocidad inicial y la otra vende control a largo plazo.

Conclusión

La Assistants API es una herramienta poderosa para casos donde el time-to-value importa más que el control granular. Para prototipos, bots internos y analítica sobre datos del usuario, elimina semanas de infraestructura. Para producción seria con tráfico alto, RAG crítico o multi-proveedor, el stack propio es la respuesta correcta. La decisión no es técnica en el sentido estricto: es operativa y estratégica.