
La "OpenAI Agents API" no es un solo producto. Es una familia de superficies para crear agentes, es decir, modelos que razonan, llaman a herramientas y repiten el ciclo hasta terminar una tarea, que se lanzaron por etapas: la Responses API y el Agents SDK de código abierto en marzo de 2025, AgentKit en octubre de 2025 y un entorno de ejecución gestionado que ejecuta el bucle por ti. Lo único que debes interiorizar antes de construir: un agente es un bucle, no una sola llamada. En ese bucle viven todo el poder y todas las sorpresas.
Si hoy estás eligiendo una superficie, las duraderas son la Responses API, el Agents SDK y la Agents API gestionada. El Agent Builder sin código está de salida (desaparece el 30 de noviembre de 2026). Y si lo que de verdad quieres es un agente de soporte que funcione en lugar de un bucle que construir y mantener, ese es el trato que ofrece eesel: un compañero listo para trabajar con precio mensual fijo desde $299 por 500 créditos, sin orquestación de la que ocuparte.
Qué es realmente la "OpenAI Agents API"
Conviene aclararlo primero, porque la expresión apunta a varias cosas relacionadas que llegaron en momentos distintos, y los nombres son realmente confusos.
Empezó en marzo de 2025, cuando OpenAI lanzó la Responses API y el Agents SDK de código abierto juntos, junto con las primeras herramientas integradas. La Responses API es la pieza básica: un superconjunto de Chat Completions a través del cual generan los modelos y la superficie a la que se conecta cada herramienta alojada. También es el futuro reemplazo de la antigua Assistants API. El Agents SDK es la capa de orquestación encima, que gestiona el bucle del agente, los traspasos entre agentes y las barreras de seguridad dentro de tu propia aplicación.
Luego, en octubre de 2025, llegó AgentKit, un conjunto de herramientas para quienes no querían escribir el bucle a mano: Agent Builder (un lienzo de arrastrar y soltar), el Connector Registry, ChatKit (una interfaz de chat incrustable) y Evals ampliado. Más recientemente, OpenAI añadió un entorno de ejecución Agents API totalmente gestionado que ejecuta el bucle por ti en su propio arnés de Codex, con compactación de contexto y orquestación multiagente integradas.
Yo desarrollo las integraciones de eesel, así que he construido este mismo bucle a mano más de una vez, y el modelo mental que más ayuda es este: nada de esto es magia. Un agente es un modelo al que le has dado un trabajo, un conjunto de herramientas y permiso para seguir llamándose a sí mismo hasta terminar. Todo lo demás, el SDK, el entorno gestionado, el lienzo visual, es una respuesta distinta a una pregunta: ¿quién ejecuta ese bucle y dónde?
Cómo funciona realmente el bucle del agente
Este es el concepto más importante y el que hace tropezar a todos los equipos nuevos. Una llamada normal a una API es una solicitud y una respuesta. Un agente es un bucle de ellas.

Le das al agente una tarea. El modelo razona sobre ella, decide que necesita información y llama a una herramienta (una búsqueda web, una consulta a una base de datos, una función que escribiste). La herramienta devuelve un resultado, ese resultado se reincorpora al contexto del modelo y el modelo razona de nuevo con la nueva información. Si ha terminado, responde. Si no, llama a otra herramienta. Así hasta que la tarea se completa o un límite lo detiene.
El diagrama de ejecución de OpenAI hace concreta la versión multiagente: un agente de triaje llama a POST /v1/responses, pasa por una barrera de seguridad y luego traspasa a un agente de CRM, que vuelve a llamar al modelo y activa una herramienta. Eso ya son varias llamadas al modelo para una sola tarea.

Lo que sorprende a la gente es el crecimiento del contexto. Cada resultado de herramienta vuelve a acumularse en el prompt de la siguiente llamada, así que el bucle no solo multiplica las llamadas, sino que infla el tamaño de todas las posteriores. Un desarrollador lo expresó con más crudeza que cualquier página de documentación:
"I was spending $200/day running agents with tool calls. The problem: tools return huge JSON (search results, DB queries, file listings). Each response bloats context. By turn 10, you're paying for 100k+ tokens on every LLM call."
No es una advertencia para asustarte, es aquello en torno a lo que diseñar. El bucle es tu poder (es lo que permite a un agente encadenar investigación, decisiones y acciones) y tu principal palanca. Bucles más cortos, salidas de herramientas más ajustadas y reintentos limitados son casi todo lo que separa a un agente barato de uno caro. Los mejores agentes de IA son aquellos en los que alguien pensó a fondo cuántos turnos necesita realmente cada tarea.
Los cuatro entornos de ejecución: elige dónde corre el bucle
Una vez que aceptas que un agente es un bucle, la siguiente decisión es dónde se ejecuta. OpenAI ofrece ahora cuatro entornos de ejecución, y se diferencian sobre todo en cuánto del bucle te corresponde a ti.

- Agents API ejecuta el bucle por ti en un arnés de Codex gestionado, con compactación automática de contexto, orquestación multiagente y un sandbox alojado opcional. La opción que menos trabajo exige, y la compactación ayuda de verdad a mantener el bucle ligero.
- Agents SDK ejecuta el bucle dentro de tu propia aplicación. Tú te encargas del despliegue, el almacenamiento y las aprobaciones; el runner gestiona el bucle y los traspasos. Aquí acaban la mayoría de los equipos que quieren control real.
- Responses API es construir desde la pieza básica: llamas al modelo directamente y montas tu propia orquestación e historial. Máximo control, máxima responsabilidad.
- ChatKit es la interfaz de chat incrustada que sueltas en tu producto, apoyada sobre cualquiera de las anteriores que haga el trabajo real.
Ninguno cambia lo que hacen el modelo o las herramientas. Cambian quién es responsable de poner en marcha el bucle, que es la decisión que da forma a toda tu arquitectura. Si quieres que el agente sea tu producto, el SDK o la Responses API te dan el control. Si quieres un agente dentro de una app existente sin alojar un runner, la Agents API gestionada es el atajo.
Las herramientas alojadas a las que puede recurrir un agente
Un agente es tan útil como las herramientas que puede llamar. Junto a tus propias funciones, OpenAI ofrece un conjunto de herramientas integradas que se conectan directamente a la Responses API:
- Web search permite al agente obtener información en vivo de internet, con un parámetro
return_token_budgetque limita cuántos tokens de resultados vuelven al modelo. Útil, porque los resultados de búsqueda son justo el tipo de salida voluminosa que infla un bucle. - File search hace recuperación sobre tus propios documentos en un almacén de vectores, construido sobre embeddings. Es la forma de darle a un agente tu base de conocimiento, y puedes limitar el número de resultados recuperados para mantener el contexto ajustado.
- Code Interpreter ejecuta Python en un contenedor aislado, para análisis de datos, manipulación de archivos y matemáticas que el modelo no debería hacer de cabeza.
- Computer use permite al agente operar un navegador o un escritorio. Para los modelos más nuevos, la vía que recomienda OpenAI es un bucle de ejecución de código en el que el modelo escribe un script que ejecuta tu propio sandbox, en lugar de una acción alojada dedicada.
Las herramientas son lo que convierte un chatbot en un agente, y elegirlas bien es la mitad del trabajo de diseño. Un agente de soporte que puede buscar en tu centro de ayuda y leer el historial de pedidos hace algo que un simple bot de preguntas frecuentes nunca podría. Cada llamada a una herramienta es además un turno del bucle, así que la regla práctica es darle al agente exactamente las herramientas que el trabajo necesita y no más.
AgentKit y lo que se está cerrando
Si escribir el bucle a mano te parece mucho, AgentKit fue la respuesta de OpenAI: una capa visual para ensamblar agentes sin código. Agent Builder es su lienzo de arrastrar y soltar, y merece un vistazo porque hace visible la forma multiagente.

Ese flujo (inicio, una barrera contra jailbreaks, un agente de clasificación, un if/else que enruta a un agente de devoluciones, de retención o de información, y luego una barrera contra alucinaciones antes de la respuesta) es una buena imagen de lo que realmente necesita un flujo de soporte real. Cada nodo que dice "agente" es al menos un POST /v1/responses más.
Aquí está el problema, y importa si hoy estás eligiendo una superficie. OpenAI está cerrando Agent Builder y Evals, y a partir del 30 de noviembre de 2026 ya no estarán disponibles. En la documentación ya aparecen bajo el encabezado "Legacy APIs", y OpenAI ahora te orienta hacia el Agents SDK basado en código o hacia los Workspace Agents en ChatGPT.

Así que construye sobre las superficies duraderas: la Responses API, el Agents SDK, el entorno de la Agents API gestionada, ChatKit y el Connector Registry. Trata el lienzo visual como una buena forma de prototipar y entender la estructura, no como aquello a lo que comprometer la producción. La buena noticia es que las propias capas no tienen una tarifa aparte; OpenAI es explícita en que las herramientas de AgentKit están "included with standard API model pricing", así que la elección es sobre durabilidad, no sobre coste.
Cómo construir uno de verdad
Basta de conceptos. Esta es la secuencia que seguiría para poner en marcha un primer agente, sea cual sea el entorno que elijas.
- Elige un modelo. Ajústalo al trabajo, no al folleto. Un enrutador o clasificador simple va bien en un modelo más barato como gpt-5.6-luna; un agente de investigación o razonamiento de varios pasos necesita uno más potente. Incluso puedes mezclar modelos en un flujo multiagente: uno pequeño para el triaje, uno mayor para el paso difícil.
- Elige un entorno de ejecución. La Agents API gestionada si quieres que OpenAI ejecute el bucle, el Agents SDK si quieres ejecutarlo en tu propia app con control total.
- Escribe las instrucciones y elige las herramientas. El prompt del sistema es la descripción del puesto del agente. Luego dale exactamente las herramientas que necesita: integradas como web search y file search, más tus propias llamadas a funciones para todo lo específico de tu producto.
- Añade barreras de seguridad. Barreras de entrada (comprobaciones de jailbreak y de tema) y de salida (una comprobación de alucinaciones o de seguridad antes de que la respuesta llegue a un usuario). Es la parte que los equipos se saltan y lamentan.
- Prueba antes de lanzarlo. Ejecuta el agente con entradas realistas y observa el bucle completo, no solo la respuesta final. Ver que un agente dio cuatro vueltas porque las tres primeras salidas no pasaron la validación es justo lo que quieres detectar antes que un cliente.
- Lánzalo y vigila el coste de ejecución. La unidad que importa es la ejecución completa, con reintentos y llamadas a herramientas incluidos, no el precio de un solo token. Instrumenta para ver la longitud del bucle por tarea desde el primer día.
Si esa lista suena a un proyecto de ingeniería de verdad, es porque lo es. Construir un agente sobre infraestructura en bruto es la decisión correcta cuando el agente es tu producto y quieres control hasta el último token. Es la decisión equivocada cuando solo necesitas que se haga un trabajo, como un buen servicio al cliente, y no quieres ser dueño para siempre de un bucle, un banco de evaluaciones y una pila de monitorización.
Cuánto cuesta (la versión corta)
No existe un único "precio de la Agents API". Se apilan tokens del modelo en cada turno, cargos por llamada de las herramientas alojadas y tiempo de contenedor para ejecutar código, y la longitud del bucle es lo que realmente mueve la factura. Las tarifas de los modelos van desde $0.20 por 1M de tokens en el más barato hasta $10 por 1M de entrada en el de gama alta; web search cuesta $10 por 1.000 llamadas; file search cuesta $2.50 por 1.000 llamadas.
Ese es el titular, pero las cuentas reales están en el bucle, así que le dedicamos su propia guía: el desglose completo, un ejemplo resuelto y un estimador de costes en vivo están en precios de la OpenAI Agents API. Si estás comparando proveedores, nuestro artículo OpenAI API vs Anthropic API hace los mismos números para Claude.
Prueba eesel y sáltate el bucle por completo

Este es el planteamiento honesto. La OpenAI Agents API es infraestructura: la materia prima con la que montas un agente, más el bucle, las evaluaciones y la monitorización que construyes y mantienes tú. Es la decisión correcta cuando el agente es tu producto.
eesel es el otro extremo de ese trato: no es infraestructura, sino un compañero listo para trabajar. Contratas al compañero de soporte con IA, lo conectas a tu helpdesk y llega ya conociendo tu empresa por tus tickets anteriores y tu centro de ayuda. Llevamos años poniendo agentes de IA en colas de soporte reales, por eso cada despliegue se simula con tus tickets históricos antes de responder a un solo cliente real. No hay bucle que tengas que medir, porque el precio es fijo: desde $299 al mes por 500 créditos, donde 1 crédito es un ticket o un chat, sin facturarse por cuántas llamadas al modelo o saltos de herramienta hicieron falta para resolverlo. El bucle impredecible es nuestro problema, no el tuyo.
Y si lo que te atrajo de la Agents API fue el control programático, eesel lo conserva. Hay una CLI pública real (@eesel/cli) además de un servidor MCP, webhooks y acceso a red, así que puedes conectar una integración, editar las instrucciones permanentes del agente, listar y aprobar acciones con humano en el bucle y leer el registro de actividad ejecución por ejecución desde una terminal o un script. La documentación lo dice claro, "everything on this site can be done from the terminal", y agentes de programación como Claude Code y Cursor pueden manejarlo directamente. Obtienes la superficie amigable para agentes sin construir ni vigilar el agente en sí.
Si construyes un agente porque quieres ser dueño de cada token, la OpenAI Agents API es un lugar realmente bueno para hacerlo. Si lo construyes porque necesitas resolver el servicio al cliente, empieza una prueba gratuita y deja que el compañero haga el trabajo.