Encargar un agente propio dejó de ser un proyecto de ingeniería

Hasta ahora, pedirle a alguien que te construyera un agente que de verdad trabajara solo —no un chatbot que contesta, sino algo que sigue un proceso completo, revisa su propio avance y sabe cuándo detenerse— significaba pedirle que construyera, además del agente, todo el motor que lo sostiene: dónde guarda su progreso si la tarea dura más de una sesión, dónde ejecuta lo que hace sin arriesgar tus sistemas reales, cómo decide qué herramienta usar entre muchas. Eso es trabajo de ingeniería de infraestructura, no de construir el agente en sí.

El 10 de septiembre, OpenAI sacó de beta cerrada su Agents API: la misma capa que coordina a Codex, ahora disponible para que cualquier desarrollador la use para construir un agente propio. No es un producto nuevo que hay que aprender a usar como usuario — es la pieza de infraestructura que, hasta ahora, había que construir para poder empezar. Si estabas por encargar un agente propio para tu negocio, esta nota es sobre qué cambia en esa conversación.

Qué hace exactamente, sin la parte técnica

OpenAI corre el ciclo del agente en su propia infraestructura: coordina cada llamada al modelo, qué herramienta usa y en qué orden, y mantiene el hilo aunque la tarea dure mucho más de lo que cabe en una sola conversación. Quien construye el agente conecta sus propias herramientas, elige dónde se ejecuta el trabajo, y paga solo por lo que el agente realmente usa — no hay una cuota aparte por usar esta capa.

Tres cosas de lo que trae son las que más le importan a un negocio, aunque nunca vaya a tocar el código: primero, el agente sigue trabajando entre sesiones — puede continuar días después donde se quedó, en vez de olvidar todo al cerrar la ventana. Segundo, se conecta a tus propias herramientas y sistemas mediante el mismo protocolo abierto —MCP— que ya usan Claude y otros asistentes, así que no depende de que todo viva dentro de OpenAI. Y tercero, puede repartir partes del trabajo entre varios agentes a la vez, en vez de hacer todo en fila.

Lo que hace posible que un agente ejecute cosas sin poner en riesgo tus sistemas es que corre dentro de un espacio de prueba aislado — un entorno separado donde puede intentar, fallar y volver a intentar sin tocar nada real hasta que el resultado esté listo. OpenAI ofrece uno propio, con la misma infraestructura que usa Codex, y también funciona con varios proveedores externos de este tipo de entornos, entre ellos Cloudflare, Vercel, DigitalOcean y Oracle.

El mismo protocolo que ya usan Claude y otros

Vale la pena explicar qué es MCP, porque va a aparecer cada vez más seguido en cualquier conversación sobre agentes. Es un protocolo abierto —no lo inventó ni lo controla una sola empresa— que define una forma estándar de conectar un modelo de IA a una herramienta externa: tu correo, tu base de datos, un sistema interno. Antes, cada asistente necesitaba su propia integración a medida con cada herramienta; con MCP, una herramienta que ya construiste para conectarse a Claude puede, en principio, conectarse también a un agente construido con esta API de OpenAI.

Esto importa para la conversación con quien te construya el agente: si lo que pides usa MCP para conectarse a tus sistemas, no estás casado con un solo proveedor de IA de por vida. El trabajo de conectar tus herramientas se puede reaprovechar si el día de mañana cambias de modelo o de proveedor — algo que, en la infraestructura de agentes de hace un año, prácticamente no existía.

Los números que reporta OpenAI

Según el anuncio oficial, los primeros equipos que migraron su orquestación propia a esta capa reportan una reducción de hasta 4 veces en el tiempo de respuesta, un costo 60% menor por tarea completada, y 86% menos respuestas que terminan en falla. Son cifras de OpenAI sobre sus propios primeros usuarios — no una medición independiente — y vale leerlas así: como lo que promete el fabricante, no como un resultado garantizado para cualquier proceso.

Lo que sí es verificable sin depender de esa cifra es la lógica detrás: antes, cada equipo que construía un agente persistente tenía que resolver por su cuenta los mismos problemas de orquestación — mantener el estado, aislar la ejecución, coordinar herramientas. Ahora esa parte es una capa que se renta, no que se construye cada vez. Eso es lo que de verdad baja el costo: no el modelo, sino dejar de reinventar el motor.

Lo que cambia en la conversación con quien te lo construya

Antes de esta capa, un desarrollador honesto te habría cotizado dos cosas: el agente que pediste, y el motor que lo sostiene. La segunda parte solía ser la más cara y la más lenta de construir bien, porque los errores ahí —un agente que pierde su progreso, que no sabe cuándo parar, que se queda ejecutando algo indefinidamente— son los más caros de arreglar después.

Con esta capa ya hecha, lo que se cotiza es casi solo el agente: qué proceso sigue, a qué herramientas se conecta, qué reglas respeta. Eso no vuelve gratis el proyecto — sigue haciendo falta alguien que lo construya bien—, pero mueve la conversación de “primero hay que construir la base” a “esto ya se puede pedir directo”.

También cambia cómo se presupuesta. No hay una cuota fija por usar esta capa de OpenAI — se paga por los tokens y las herramientas que el agente de verdad consume mientras trabaja. Eso quiere decir que el costo de tener un agente propio depende directamente de qué tan seguido lo usas y qué tan largo es cada proceso, no de una licencia mensual que pagas exista o no la uses. Para un negocio chico, es una diferencia real frente a comprar una plataforma completa por adelantado: se puede empezar con un solo proceso y ver el gasto real antes de decidir si vale la pena ampliarlo.

Eso sí, esa misma flexibilidad es la razón por la que el paso 6 del brief —el tope de gasto antes de detenerse solo— no es opcional. Un agente que paga por lo que consume y no tiene un límite puesto puede, en teoría, seguir trabajando y gastando mucho más tiempo del que alguien pensó que iba a tomar.

Quién lo debería construir, y quién no debería intentarlo solo

Esta capa está pensada para quien ya sabe programar — reduce el trabajo de infraestructura, no la necesidad de un desarrollador. Si tu negocio tiene alguien de tecnología interno con experiencia construyendo integraciones, esta nota le ahorra explicarle desde cero por qué esta API es distinta a construir todo desde cero él mismo.

Si no tienes a esa persona adentro, lo que cambia para ti no es que ahora puedas construirlo tú — es que contratar a alguien externo para construirlo debería costar menos y tomar menos tiempo que hace seis meses, precisamente porque la parte más cara del trabajo ya no hay que inventarla. Es información útil para negociar el alcance y el precio de ese proyecto, aunque nunca vayas a tocar una línea de configuración tú mismo.

Lo que hay que leer con cautela

Dos cosas conviene tener presentes antes de decidir con esto. La primera: los números de 4 veces menos tiempo de respuesta, 60% menos costo y 86% menos fallas son de OpenAI, sobre sus propios primeros usuarios. No sabemos cuántos fueron, ni qué tan parecidos eran sus procesos a los tuyos, ni si esos equipos ya tenían experiencia previa construyendo agentes que hizo más fácil aprovechar la capa nueva. Son un techo posible, no un promedio garantizado.

La segunda: sigue siendo beta pública, no una versión estable de largo plazo. Eso no significa que no sirva — significa que el comportamiento puede cambiar entre ahora y la versión final, y que un agente que construyas hoy puede necesitar ajustes cuando OpenAI la mueva a disponibilidad general. Para un primer proceso pequeño y bien acotado —como el que describe el diagnóstico de abajo— ese riesgo es razonable. Para algo que va a correr sin supervisión sobre un proceso crítico del negocio, vale la pena esperar a que la capa madure, o al menos construir con esa fecha límite en mente desde el principio.

Lo que se vuelve más fácil también se vuelve más fácil de descuidar

Que construir un agente persistente sea más barato tiene una consecuencia menos cómoda: también es más fácil terminar con uno corriendo por días sobre tus sistemas reales sin que nadie lo esté mirando de cerca. Antes, el costo de construir la infraestructura obligaba a pensarlo dos veces. Ahora esa fricción bajó, y la disciplina de definir límites —qué puede tocar, cuánto puede gastar, cuándo debe detenerse a preguntar— pasa a depender enteramente de quien lo pide, no de que sea difícil de construir.

Ya escribimos sobre esto en otra nota de esta comunidad, a propósito de otro agente: antes de darle a cualquier agente acceso a una cuenta o un sistema real, vale la pena tener candados explícitos, no asumir que el agente los trae puestos por defecto. El brief de esta nota cubre la parte de qué debe hacer el agente; esa otra nota cubre la parte de qué tanto confiarle una vez que ya existe.

Qué tipo de proceso es el que suele calificar

No hace falta imaginarlo desde cero. Los procesos que mejor encajan con este tipo de agente comparten una forma, aunque el negocio sea distinto: clasificar y responder tickets de soporte que siguen un patrón conocido, revisar facturas o comprobantes contra reglas fijas antes de que lleguen a contabilidad, dar seguimiento a un mismo tipo de trámite hasta que se completa, o monitorear que un conjunto de sistemas siga cumpliendo reglas específicas y avisar cuando algo se sale de rango.

Lo que tienen en común esos ejemplos no es el giro del negocio — es que en los cuatro hay reglas, no juicio caso por caso; hay una forma de medir si el resultado quedó bien; y a nadie le urge la respuesta en el segundo exacto en que empieza. Si tu candidato se parece a alguno de esos cuatro, vas por buen camino. Si se parece más a “negociar con un cliente difícil” o “decidir qué proyecto priorizar esta semana”, ese no es un proceso para un agente — sigue siendo trabajo de una persona, con o sin esta capa nueva de por medio.

Lo que esto no resuelve

No decide qué construir. Esta capa hace más barato y más confiable construir un agente persistente. No te dice cuál de tus procesos vale la pena convertir en uno — esa sigue siendo una decisión de negocio, no técnica.

No reemplaza a quien programa. Sigue haciendo falta un desarrollador que conecte tus herramientas, defina las reglas y pruebe que el agente hace lo que debe. Lo que cambió es cuánto de su tiempo se va en la infraestructura contra cuánto se va en tu proceso específico.

No es para procesos que dependen de juicio caso por caso. Si lo que marcaste en el diagnóstico fue sobre todo criterio de una persona, el problema no lo resuelve una mejor infraestructura de agentes — lo resuelve, primero, escribir el proceso.

Qué hacer el lunes

Paso 1 (15 minutos). Elige un proceso — uno, el mismo del diagnóstico de arriba — y pásalo por las siete preguntas del brief. No lo completes de memoria: escríbelo mirando cómo se hace hoy de verdad.

Paso 2 (10 minutos). Marca cuáles preguntas no pudiste contestar. Esas son el trabajo real antes de hablar con nadie de tecnología — no faltan datos técnicos, falta terminar de definir el proceso.

Paso 3 (20 minutos). Si el brief quedó completo, llévalo a la primera conversación con quien pudiera construirlo — interno o externo. Un brief así de específico cambia esa conversación de una cotización a ciegas a una conversación sobre un proceso que ya conoces mejor que nadie.

Ninguno de los tres pasos requiere tocar la API, abrir una consola ni escribir una sola línea de configuración. Es, a propósito, el mismo trabajo que harías si en vez de un agente fueras a contratar a una persona para ese proceso: describirlo bien es lo que hace que la contratación —de una persona o de un agente— salga bien.