Alquila el arnés del agente, conserva la señal de éxito

Un agente de larga duración puede detenerse mientras el trabajo sigue sin terminar. OpenAI abrió la API de Agentes a beta pública para todos los desarrolladores el 10 de septiembre de 2026. Para diseñadores de producto y líderes de ingeniería que lanzan agentes de larga duración, la pregunta de construir o comprar es qué capa genera la confianza que los usuarios pueden ver y verificar.

Alquila la orquestación, no la confianza del usuario

Expone la pila de orquestación gestionada —gestión de sesiones, compresión de contexto, coordinación de subagentes y sandboxes alojados— y se describe como la misma infraestructura que respalda Codex y ChatGPT for Work. Si tu producto no necesita reemplazar ese bucle interno, alquila el estado de sesión y la orquestación. El cliente se mantiene ligero: le pide al arnés que continúe una sesión y muestra hitos, mientras la plataforma se encarga del trabajo interno.

El propio arnés no se factura como un cargo separado. Eso elimina un motivo de coste para reconstruir la contabilidad de sesiones, pero no elimina la pregunta de diseño. La plataforma puede llevar el bucle interno, mientras tu equipo conserva el contrato visible para el usuario: el estado que los usuarios pueden inspeccionar, el límite de ejecución que pueden comprender y la señal de éxito en la que pueden confiar. Cuando un equipo dedica semanas a reintentos, presupuestos de tokens y transferencias entre subagentes, pregúntate si ese trabajo cambia lo que el usuario ve. Alquila la capa cuando no lo cambie. Mantenla lo suficientemente cerca para probarla, auditarla y rediseñarla cuando sí cambie lo que el usuario ve.

Coloca la ejecución detrás del límite de datos

Elige la ejecución después del contrato de éxito, no antes. Puedes dirigir el trabajo al sandbox alojado de OpenAI, a tu propio entorno o a un proveedor de sandbox conectado. OpenAI ha designado nueve socios de sandbox para la API, lo que da al equipo de producto una lista corta de entornos de ejecución. Las opciones son útiles, pero las restricciones de datos y control siguen dando forma al producto.

El estado de sesión permanece con el servicio, la residencia de datos está actualmente limitada a Estados Unidos y el soporte de retención cero de datos no está disponible. Trata esos límites como restricciones de producto cuando tus usuarios estén en industrias reguladas. La elección de ejecución debe ser visible en el producto, no oculta en un diagrama de arquitectura. Una nota de decisión debe nombrar la ruta de ejecución, el límite de datos y los puntos de control que tu equipo debe conservar. Si tu equipo debe mantener la ejecución dentro de su propio límite, dilo claramente en el flujo de usuario. Si la respuesta es un sandbox de socio, el flujo debe nombrar al proveedor y las herramientas que habilita. Si necesitas herramientas específicas del proveedor, haz que ese compromiso sea parte del contrato de éxito.

Convierte el éxito en un recibo, no en una marca de verificación verde

Un turno finalizado no debe tratarse como confirmación de que todas las llamadas a herramientas funcionaron, y un evento de inactividad por sí solo no indica éxito. La interfaz debe separar la finalización de la plataforma del estado en el que tus usuarios pueden confiar. Un panel de finalización puede listar qué herramientas se ejecutaron, qué artefactos cambiaron, qué verificaciones superaron y qué debe verificar el usuario a continuación, en lenguaje claro.

La trampa es una marca de verificación verde que aparece cuando el agente se calla. El rediseño es un recibo que muestra claramente el trabajo, la evidencia y la siguiente acción humana. Los fallos silenciosos de llamadas a herramientas necesitan un estado visible, no una fila ausente. Un subagente que modifica un archivo debe mostrar el archivo, el cambio y la marca de tiempo. Un usuario que no puede saber qué pasó no tiene un producto terminado; el agente simplemente se detuvo.

Construye el contrato de éxito antes de la primera demostración. El recibo debe responder cuatro preguntas:

• Qué salidas espera el usuario
• Qué herramientas pueden ejecutarse sobre sus datos
• Qué datos salen del cliente
• Qué verificación marca la finalización

Cuando un turno termina, la interfaz debe auditar, no celebrar. Muestra lo que el agente intentó, lo que verificó, lo que no pudo verificar y lo que el usuario debe hacer a continuación. Un turno finalizado es un evento de transporte; el resultado del producto es el artefacto, el estado modificado y la evidencia que el usuario puede inspeccionar. Mantén el recibo visible hasta que el usuario confirme el resultado, no hasta que el indicador de carga se detenga o el agente quede inactivo.