Agents API de OpenAI: controles para agentes de larga duración

El 10 de septiembre de 2026, OpenAI presentó Agents API en beta pública. Expone la infraestructura de ejecución de Codex para integrar agentes en aplicaciones, con entornos administrados por OpenAI, infraestructura propia o proveedores asociados. El anuncio incluye gestión de contexto para sesiones prolongadas y trabajo con herramientas.

La pregunta para un equipo de producto es qué ocurre cuando un trabajo deja de caber en una interacción corta. Un agente puede analizar documentos, producir archivos y necesitar aclaraciones antes de terminar. La aplicación debe explicar al usuario qué está ocurriendo, conservar decisiones importantes y distinguir una propuesta de una acción ya ejecutada. Ese contrato operativo merece atención desde el primer piloto.

La documentación distingue agente, entorno, sesión y eventos. OpenAI administra sesiones, orquestación, compactación y recuperación; la aplicación aporta herramientas y elige dónde ejecutar. Puede recibir avances mediante eventos o webhooks y continuar una sesión. Conviene entender esos componentes antes de diseñar la interfaz y el almacenamiento del producto.

Nuestra recomendación es conservar un registro de trabajo propio, separado de la conversación: identificador del caso, versión de los datos de entrada, responsable, estado de revisión y resultado aprobado. La sesión contiene la interacción técnica; el registro explica qué compromiso asumió tu producto. Esa separación facilita responder preguntas sencillas pero decisivas, como quién aprobó un informe y sobre qué información se preparó.

En los entornos alojados por OpenAI, cada sesión tiene un espacio de trabajo separado. La documentación distingue archivos del entorno y artefactos publicados: las copias publicadas pueden seguir disponibles tras expirar el entorno. También permite configurar el acceso de red. Cerrar el flujo de eventos, por sí solo, no cancela una tarea.

Diseña la recuperación alrededor de esa diferencia. Guarda referencias verificables a los resultados que el producto necesita conservar y una política explícita de retención. No utilices un archivo temporal como única constancia de una decisión aprobada. En la interfaz, muestra por separado trabajo en curso, material listo para revisar y entrega aceptada; un archivo creado todavía puede contener errores o estar incompleto.

En nuestro diseño de piloto, la interfaz ofrecería detener, aclarar y volver a intentar como acciones distintas. Detener requiere comprobar que cesaron las operaciones pendientes; aclarar conserva el caso y añade información; volver a intentar exige explicar qué se reutiliza y qué se recalcula. Muestra cuándo hubo el último avance comprobado y quién debe actuar si el proceso está esperando. Un indicador animado permanente comunica actividad, pero no ayuda a saber si el trabajo progresa o necesita intervención.

Imagina un flujo hipotético para revisar diferencias entre órdenes de compra y recepciones. El usuario selecciona un período y el agente recibe una copia acotada de los registros. Su objetivo inicial es producir una lista de diferencias con referencias a cada documento, no actualizar automáticamente inventario ni aprobar pagos. La salida útil es un paquete de revisión que permita comprobar cómo llegó a cada conclusión.

Antes de ejecutar, define qué significa una diferencia: unidades, cantidades, fechas, tolerancias y registros anulados. Si falta una recepción, el agente debería señalar la ausencia y pedir el dato pertinente en lugar de asumir incumplimiento. Un revisor valida la evidencia y acepta o rechaza las propuestas. Este alcance permite probar razonamiento y continuidad sin confundir una observación del modelo con un hecho contable confirmado.

Propón límites pequeños que el equipo pueda comprobar con casos reales. Las instrucciones ayudan a orientar al agente, pero la autorización de una herramienta debe verificarse en el servicio que ejecuta la operación. Si una herramienta recibe un identificador de empresa, no basta con confiar en el valor enviado por el modelo: el servidor debe validarlo contra el usuario y el alcance permitido.

Interrumpe deliberadamente un piloto con datos de prueba después de generar una propuesta y antes de aceptarla. Al retomarlo, el producto debería reconocer qué existe y qué queda pendiente. Haz también la prueba inversa: la operación se completó, pero la confirmación no llegó a la interfaz. El sistema necesita poder consultar el resultado real antes de decidir si repite una acción.

Para operaciones con efectos externos, diseña una clave de operación estable y una forma de detectar reintentos. Registra la versión de entrada y conserva el resultado confirmado por el servicio. Si los datos cambiaron durante una pausa, vuelve a validar la propuesta: una aprobación sobre una versión anterior no debería extenderse silenciosamente a otra. Estas decisiones pertenecen a tu aplicación y requieren pruebas explícitas.

Evalúa una muestra con respuestas de referencia y desacuerdos conocidos. Registra qué conclusiones están respaldadas, qué omisiones detectó el revisor, cuánto trabajo quedó sin resolver y cuánto costó producir y revisar el paquete completo. Añade casos difíciles: datos contradictorios, documentos incompletos y cambios de alcance. Un promedio atractivo en casos fáciles puede esconder precisamente los problemas que importan en operación.

Para adoptar la beta, exige además una demostración de pausa, recuperación y rechazo de una acción no autorizada. Empieza con un proceso acotado, responsable identificado y revisión humana; amplía permisos solo cuando la evidencia lo justifique. El valor potencial de una sesión prolongada está en completar trabajo útil con continuidad. Tu criterio de compra debería incluir cómo se comprueba, cómo se detiene y cómo se corrige ese trabajo.