Cómo la API de Agents de OpenAI cambia la economía del trabajo con IA
El agente gestiona los turnos del modelo de paquetes, las llamadas a herramientas, los entornos aislados, los intentos repetidos y la revisión humana, por lo que las cuentas de tokens ya no indican el costo. En su lugar, mida las tareas aceptadas.
Fuentes: OpenAI’s Agents API Changes the Economics of AI Work
La API Agents de OpenAI está diseñada para ejecutar agentes en la nube durante sesiones prolongadas, equipados con herramientas, entornos aislados, archivos, capacidad de manejo de contexto y subagentes que trabajan en paralelo. Un agente puede analizar un problema, ejecutar código, asignar tareas a otros, guardar resultados intermedios y continuar hasta que el trabajo esté terminado.
Eso cambia no solo la forma en que los desarrolladores crean agentes, sino también la forma en que una empresa debe calcular su costo.
Una sola solicitud ahora puede desencadenar una cadena de procesos del modelo, llamadas a herramientas, operaciones en entornos aislados, intentos repetidos, almacenamiento de resultados y aprobaciones humanas. Los tokens siguen apareciendo en la factura, pero ya no indican cuál es el costo real del trabajo. La unidad que debe seguirse para hacer un seguimiento es la tarea completada: correcta, recuperable, auditable y con un valor equivalente al esfuerzo invertido en su producción.
Una solicitud ya no es una unidad de trabajo
Una llamada normal al modelo tiene un proceso claro: la aplicación envía la entrada, el modelo devuelve la salida y la aplicación continúa con sus tareas habituales.
La API de Agents está diseñada para otro tipo de ejecución. El agente recibe un objetivo y decide cómo abordarlo. Por ejemplo, si le pides que investigue un aumento en los errores 5xx:
Descubre por qué
service-apiha registrado un aumento inusual en errores durante los últimos 30 minutos y recomienda una solución segura.
Un asistente convencional describiría cómo podría investigar un ingeniero. Un agente conectado a los sistemas adecuados puede comenzar a hacerlo de inmediato: verifica las implementaciones recientes, consulta los registros de la aplicación, compara las versiones de las dependencias, examina las métricas de infraestructura, asigna análisis separados, ejecuta código de diagnóstico, guarda pruebas y espera aprobación antes de realizar cualquier cambio.
El usuario ve una sola solicitud. El sistema llevó a cabo todo el flujo de trabajo.
La guía práctica de OpenAI para crear agentes denomina a esto un “ejecución”: un bucle que continúa hasta que el agente completa la tarea, genera una salida final, se produce un error o se alcanza un límite configurado. El costo se acumula dentro de ese bucle.
El tiempo de ejecución tiene una cuenta oculta
Los tokens forman parte de la cuenta. Son simplemente la parte más fácil de ver.
Volviendo al incidente de producción: primero el agente obtiene las tasas de error recientes de una herramienta de monitoreo, luego lee el historial de despliegue y después busca en los registros. Cada una de esas llamadas tiene un precio, un tiempo de espera, un conjunto de permisos y su propio modo de fallar.
Luego, la herramienta de registro devuelve 500 registros. Eso parece útil hasta que se observa lo que sucede a continuación. Esos registros deben ser movidos, procesados y colocados en el contexto del modelo. La mayoría son irrelevantes, y el modelo pierde tiempo leyendo información no relevante antes de encontrar los cinco eventos que explican el incidente.
Por lo tanto, el diseño de la herramienta implica también un diseño de costos. Una herramienta de búsqueda que devuelve un resumen estructurado breve puede ser más económica y fiable que una que muestra todos los registros que coinciden. La solución de la API consiste en una búsqueda de herramientas combinada con llamadas programáticas a dichas herramientas, lo cual permite mostrar las definiciones de las herramientas solo cuando es necesario y filtrar o combinar los resultados antes de que lleguen al modelo.
La misma lógica se aplica a la ejecución en entorno aislado. Un script de diagnóstico consume CPU, memoria, almacenamiento, tiempo de instalación de paquetes y, posiblemente, acceso a red. Si genera un informe o un conjunto de pruebas, dichos archivos deben almacenarse, indexarse, revisarse o conservarse.
Las ejecuciones prolongadas de los agentes también producen más que texto. Al investigar un incidente, las pruebas que sustentan un diagnóstico pueden ser más importantes que el resumen escrito. En el trabajo de programación, el parche es una parte del resultado, mientras que los resultados de las pruebas y un análisis de dependencias pueden ser igualmente valiosos.
Un pequeño ejemplo del SDK de agentes muestra dónde se encuentra el límite de ejecución:
from agents import Agent, Runner, function_tool
@function_tool
def get_error_rate(service: str, minutes: int = 30) -> str:
"""Return the recent error rate for a service."""
return f"{service}: 8.4% errors over {minutes} minutes"
investigator = Agent(
name="Incident investigator",
instructions=(
"Investigate the incident, use evidence, and recommend "
"the safest next action. Do not change production state."
),
tools=[get_error_rate],
)
result = Runner.run_sync(
investigator,
"Investigate the elevated 5xx rate in service-api."
)
La función es muy sencilla. Pero la economía detrás de ella no lo es. Todo esto depende del agente: si se le llama, si se le llama una segunda vez, cómo se lee su resultado y si se necesita otra herramienta o la aprobación de un humano.
La fiabilidad, el control y la aceptación definen el éxito
El SDK proporciona los componentes necesarios para que funcione ese ciclo: agentes, ejecutores, herramientas, pasajes de control, sesiones, medidas de seguridad y seguimiento. Son importantes porque los flujos de trabajo reales rara vez tienen éxito en una sola intentona.
La consulta de registros podría agotar el tiempo de ejecución, por lo que el agente vuelve a intentarlo. La segunda consulta funciona, pero devuelve datos incompletos. Entonces reescribe la consulta, obtiene un conjunto de datos más grande y pide a un agente especializado que examine el historial de despliegue. Al final, la investigación tiene éxito.
Para el usuario, el agente completó la tarea. En términos económicos, la tarea también incluyó intentos fallidos, más procesamientos del modelo, más llamadas a herramientas y más tiempo transcurrido.
Los intentos de repetición no son necesariamente un desperdicio. Un intento que permite superar un fallo temporal puede ser precisamente lo que hace que un agente sea fiable. El problema surge al incluir esos intentos en una sola cifra general de éxito.
Los agentes paralelos intercambian tiempo por costos
La API puede dividir el trabajo complejo entre subagentes que operan simultáneamente. La investigación de un incidente podría entregar al primer especialista el historial de despliegue, al segundo los errores de la aplicación y al tercero los cambios en las dependencias, mientras que un coordinador combina sus hallazgos.
El tiempo real puede reducirse ya que todo se ejecuta al mismo tiempo. Sin embargo, la factura total podría aumentar, porque ahora se paga por varios contextos de modelo independientes, múltiples cadenas de llamadas a herramientas, la coordinación, un paso de síntesis y, muy posiblemente, por el mismo trabajo realizado dos veces.
Por eso los sistemas multiagente se asemejan a sistemas distribuidos con modelos de lenguaje integrados en el proceso. El coordinador actúa como planificador, los especialistas son los trabajadores, las herramientas externas son servicios, y los archivos y bases de datos se convierten en estado compartido. Surgen los problemas habituales: fallos parciales, intentos de reintentar, estado inconsistente, trabajo repetido, límites de concurrencia y una atribución de costos poco clara. Tener más agentes no implica automáticamente un razonamiento mejor. El paralelismo debe justificarse según la forma en que está estructurada la tarea y cuánto vale el tiempo.
La aceptación es la línea de meta
La generación puede terminar mucho antes de que finalice el trabajo real. En el caso de un servicio de soporte, la aceptación podría significar que el problema del cliente se resolvió sin una escalada innecesaria. En una tarea de programación, podría significar que las pruebas se superaron, se cumplieron los estándares de revisión y el cambio se integró. En la respuesta a incidentes, podría significar que un diagnóstico estuvo respaldado por pruebas y condujo a una mitigación segura. La métrica que se deriva de esto es:
cost per accepted task =
total execution cost / tasks accepted without rework
Si un agente responde en diez segundos y luego una persona pasa diez minutos arreglándolo, la respuesta en diez segundos no fue la solución más económica. Fue solo un intento barato.
Que una persona revise el resultado no significa que la automatización haya fallado. En trabajos de alto riesgo, la aprobación final puede ser lo que hace que automatizarlos sea siquiera aceptable. Lo que se desea es el menor esfuerzo humano posible que aún permita un control humano real.
El SDK ofrece límites de seguridad para las entradas, salidas y herramientas, y su documentación separa las verificaciones a nivel de agente de las a nivel de herramienta: las configuraciones con especialistas delegados pueden requerir verificaciones relacionadas con operaciones específicas de funciones-herramientas y MCP. Estos límites de seguridad implican esfuerzo adicional y, a veces, llamadas adicionales al modelo. También pueden evitar costos mucho mayores derivados de acciones incorrectas, exposición de datos, violaciones de políticas o problemas regulatorios. La salida se considera una tarea completada solo después de las verificaciones de calidad y con el grado adecuado de control humano.
De los registros a el valor empresarial
Cada nueva herramienta amplía las capacidades de un agente. También incrementa los permisos del sistema, la latencia, los modos de fallo y las necesidades de gobernanza.
La API admite funciones personalizadas, herramientas integradas y servidores MCP. El estándar MCP estandariza la forma en que las aplicaciones de IA se conectan a herramientas, recursos y comandos externos. Esto reduce la fricción en la integración, pero no hace que una herramienta remota sea confiable por defecto. La especificación MCP advierte que las descripciones y anotaciones de herramientas provenientes de servidores no confiables no deben considerarse automáticamente fiables, y recomienda la invocación visible de herramientas y la aprobación humana para las operaciones. La autorización remota plantea preocupaciones adicionales, como la validación del público al que está dirigido el token, el almacenamiento seguro de los tokens, el uso de PKCE y la prevención de ataques de tipo confused-deputy. Cada capacidad adicional crea un nuevo límite en materia de autorización, auditoría y gobernanza.
Las trazas son datos contables
La respuesta final revela poco sobre cómo se llegó a ella. No se puede saber qué herramientas se consideraron, cuántas se ejecutaron, si algún subagente falló o qué motivó la inclusión de una persona en el proceso.
El SDK incluye un sistema de seguimiento que abarca generaciones, llamadas a herramientas, transferencias de tareas, restricciones y eventos personalizados. El seguimiento suele presentarse como una ayuda para la depuración, pero también funciona como un sistema de contabilidad. Un seguimiento puede revelar que una herramienta causa la mayor parte de la latencia, que un flujo de trabajo repite constantemente la misma búsqueda o que una elección de modelo genera una mayor aceptación con menos intentos. Sin seguimiento, los equipos optimizan promedios; con él, pueden optimizar cada etapa individual del flujo de trabajo.
La tabla de indicadores debe combinar los datos de ejecución con los datos de resultados: el costo de cada tarea aceptada junto con la cantidad de iteraciones del modelo y llamadas a herramientas utilizadas, el tiempo en el entorno de pruebas, la frecuencia con la que se realizan los intentos de nuevo y la frecuencia con la que se recuperan, además del trabajo de retoque, los minutos dedicados por los revisores, las escalaciones y el valor entregado. El panel de control exacto depende del flujo de trabajo. Un equipo de soporte podría estar interesado en los casos cerrados sin escalaciones, un equipo de plataforma en los incidentes mitigados, y un equipo de producto en los ingresos protegidos o el tiempo del personal ahorrado. Lo que cambia es por qué se realiza la división.
La decisión estratégica
Las organizaciones no deberían empezar preguntándose cómo hacer que un agente sea más económico por llamada. La pregunta más difícil debe plantearse primero:
¿Es este agente capaz de manejar este tipo de trabajo de manera lo suficientemente fiable como para que el costo total sea inferior al del proceso actual?
Para ello se necesita una base honesta del proceso actual, que incluya el tiempo del personal, el tiempo de espera en colas, las transferencias repetidas, la infraestructura, los errores y su corrección, las oportunidades perdidas y los esfuerzos de cumplimiento. Un agente que cuesta 2 dólares por tarea aceptada puede ser una excelente inversión cuando el proceso existente cuesta 20 dólares. Uno que cuesta 0,10 dólares por intento puede ser una mala opción si solo la mitad de sus resultados son aceptados y cada fallo requiere corrección manual.
Un plan de optimización sensato comienza con el sistema más simple capaz de completar la tarea. Utilice modelos más pequeños para el enrutamiento, el filtrado o la simple validación, y pase a modelos más potentes cuando se necesite un razonamiento más profundo. Haga que las herramientas devuelvan resultados compactos y estructurados. Paralice únicamente el trabajo independiente. Valide las acciones resultantes. Guarde suficiente evidencia para respaldar la revisión y la recuperación.
El SDK resulta útil cuando el propio entorno de ejecución necesita gestionar turnos, herramientas, sesiones, transferencias, restricciones o la coordinación entre agentes. La API Responses sigue siendo adecuada cuando un equipo prefiere encargarse personalmente del ciclo y del manejo del estado. Esa elección es arquitectónica, y también tiene implicaciones financieras.
Mida el trabajo, no las palabras
La API Agents facilita la creación de agentes que operan en diferentes herramientas, entornos, sesiones y subagentes, mientras que el SDK ofrece primitivas a nivel de aplicación para coordinarlos, protegerlos con restricciones y examinarlos mediante trazas. Juntos, indican una forma diferente de pensar en la economía de la IA.
La solicitud que llega es simplemente el punto de entrada, no la unidad de cuenta. La unidad es la tarea completada, aquella que puede ser aceptada como correcta, recuperada si algo sale mal, inspeccionada posteriormente y justificada en términos de costos. La tarificación por token sigue siendo útil como un único ítem. Todo lo demás: herramientas, procesamiento, almacenamiento, intentos de reintentar, latencia, seguridad y atención humana, se refleja en otras partes de la factura.
Los mejores sistemas de agentes no serán aquellos que generen la menor cantidad de tokens. Serán aquellos que completen el trabajo más valioso a un costo total razonable.
Leer más
- Construyendo sistemas RAG que resisten en producción: desde la ingesta hasta la observabilidad — Desde el particionamiento y la recuperación híbrida hasta el reclasificación, el control de acceso, los conjuntos de evaluación y el rastreo: las capas que diferencian una demostración RAG de un sistema en producción.
- Razonamiento sobre un árbol de documentos en lugar de buscar vectores — PageIndex crea un índice jerárquico que permite a un LLM navegar por él, omitiendo el particionamiento y las representaciones vectoriales. Cómo funciona, su resultado en FinanceBench y cuándo utilizarlo.