Agentes asíncronos: cómo trabajar sin bloquear el flujo

Un agente que investiga un incidente puede iniciar una consulta de logs, pedir una exportación al data warehouse y ejecutar una suite de pruebas. Si trata cada herramienta como una llamada bloqueante, la tarea más lenta detiene análisis que no dependen de ella. Si continúa sin modelar dependencias, puede redactar una causa raíz antes de recibir el dato crítico, reintentar un job que todavía corre o actuar con una respuesta desactualizada. El problema no es solo latencia: es distinguir con precisión qué trabajo puede avanzar y qué decisión debe esperar.

OpenAI publicó el 2 de octubre de 2026 una guía de producción para la familia GPT-6 que reúne steering, herramientas asíncronas y delegación como mecanismos para tareas que duran horas o días. La publicación ocurrió un día calendario antes de este artículo en Lima; no implica que cada mecanismo se haya lanzado ese día. Su valor práctico está en cambiar el diseño: el modelo puede continuar trabajo independiente mientras la aplicación ejecuta una herramienta lenta, pero la aplicación sigue siendo responsable de registrar el job, entregar su resultado y preservar los límites de autorización.

En una llamada convencional, el turno del modelo se pausa hasta recibir la salida de la herramienta. En una herramienta asíncrona, el modelo emite la llamada y puede razonar, responder partes independientes o iniciar otro trabajo antes de que llegue el resultado. La ejecución no se mueve mágicamente al proveedor del modelo: la aplicación inicia el job, conserva la relación entre la llamada y el proceso externo, y devuelve la salida en una continuación. Esa separación permite ocultar espera útil, pero también convierte al orquestador en un pequeño sistema distribuido.

La documentación de OpenAI limita este modo a herramientas function y custom ejecutadas por la aplicación; no aplica a herramientas hospedadas ni a llamadas programáticas. También advierte que, en el modo multiagente actual, no debe combinarse con llamadas paralelas de herramientas. Esas restricciones importan porque «asíncrono» no significa «todo concurrente». El diseño necesita un grafo explícito, ownership del estado y una barrera que espere solo cuando la próxima acción realmente dependa del dato pendiente.

Representa cada unidad de trabajo con entradas, salida esperada, efectos, timeout y dependencias. Una consulta de inventario y una lectura de contrato pueden correr a la vez si ninguna consume a la otra; comparar precio, moneda y vigencia depende de ambas. La barrera debe estar en esa comparación, no justo después de lanzar el primer job. Este grafo evita dos extremos: bloquear trabajo independiente y permitir que una conclusión use datos incompletos. También deja visible el camino crítico que realmente determina la latencia.

Separa además lectura de escritura. Las búsquedas y validaciones sin efecto suelen ser buenas candidatas para ejecución anticipada; crear, enviar, borrar o aprobar requiere una dependencia adicional de autorización y una verificación de estado fresco. Una corrección del usuario puede volver obsoleto un resultado aunque el job haya terminado correctamente. Por eso cada nodo debe declarar no solo de qué datos depende, sino bajo qué versión de objetivo, alcance y permisos sigue siendo válido.

Un handle legible para el modelo no reemplaza la identidad de transporte. Conserva una tabla que relacione handle, call_id original, job externo, conversación, tenant, versión del objetivo, estado, timestamps, intentos y hash de argumentos. OpenAI recomienda mantener handles únicos durante toda la conversación, incluso después de completar un job. Esa regla evita que una salida tardía se asocie a una nueva consulta con el mismo nombre y ayuda a detectar resultados duplicados o entregados fuera de orden.

El registro debe sobrevivir reinicios del worker y desconexiones. Estados mínimos útiles son registered, running, completed, failed, cancelled, expired y outcome_unknown. Guarda la salida o una referencia verificable, pero no vuelques secretos ni payloads sensibles al prompt. Si el resultado cambia un sistema, añade una clave de idempotencia y un mecanismo de reconciliación. La recuperación correcta no consiste en repetir todo: primero pregunta si el efecto ya ocurrió, luego reanuda desde el último estado confirmado.

Una herramienta de espera no acelera el job; expresa que la siguiente decisión necesita uno o más resultados pendientes. Debe recibir un conjunto explícito de handles, resolver solo esos trabajos y devolver estados claros para completado, fallo, timeout o cancelación. La aplicación puede entregar resultados apenas estén disponibles sin esperar una barrera. Cuando sí existe una espera, la documentación recomienda devolver primero cada salida sobre su call_id original y después el estado de la propia llamada de espera, para que el modelo reanude con la evidencia disponible.

Diseña la entrega como at-least-once y el consumo como idempotente. Marca qué versión de la conversación recibió el resultado y evita que un retry produzca dos decisiones. Si una herramienta finaliza después de que el usuario cambió el alcance, conserva la evidencia pero clasifícala como stale hasta revalidar. No mezcles «job terminado» con «resultado aceptado»: el primero es un hecho de infraestructura; el segundo requiere comprobar esquema, procedencia, actualidad y compatibilidad con la decisión que sigue.

Mid-turn steering permite enviar una corrección mientras la respuesta está en curso, pero OpenAI aclara que el mensaje se encola: no reescribe la salida ya emitida, no deshace acciones anteriores y no cancela herramientas iniciadas. La confirmación de aceptación solo significa que la actualización está en cola. Por eso un cambio de «analiza todas las cuentas» a «solo la región norte» debe incrementar la versión del objetivo, invalidar dependencias afectadas y bloquear cualquier escritura todavía no comprometida; no puede asumir que la consulta amplia dejó de correr.

Mantén un log de cada steer, su ID, la versión objetivo y el momento en que se aplicó. La cola pendiente vive en la conexión WebSocket y no debe asumirse persistente después de una desconexión; antes de reenviar, compara el registro propio con los eventos recibidos. Para acciones materiales, introduce un commit point: prepara el efecto, revalida objetivo y autorización, y solo entonces ejecuta. Steering cambia el futuro del flujo; compensar el pasado exige otra operación explícita y revisable.

Un eval debe comparar el flujo bloqueante y el asíncrono sobre tareas equivalentes. Mide aceptación completa, latencia de pared, tiempo ocioso ocultado, costo, número máximo de jobs pendientes y tiempo hasta detectar que una dependencia ya era necesaria. Añade métricas de corrección: resultados stale consumidos, duplicados, waits innecesarios, escrituras después de un steer y decisiones tomadas sin todos los inputs requeridos. Una mejora promedio de latencia no compensa una sola acción material basada en el objetivo anterior.

Prueba fallos deliberados: job que termina dos veces, worker reiniciado, timeout seguido de éxito tardío, respuesta mal formada, cambio de permisos, steer durante una aprobación y desconexión con una actualización aceptada pero no aplicada. Verifica que el sistema entregue un handoff con jobs pendientes, evidencia recibida, estado incierto y siguiente acción segura. Si usa compaction para conversaciones largas, conserva por separado el ledger operativo: el item compactado puede transportar contexto con menos tokens, pero es opaco y no sustituye una bitácora auditable.

Este ejemplo es hipotético. Un agente recibe una solicitud de alta y lanza en paralelo una validación fiscal, una búsqueda de duplicados y una revisión de sanciones. Mientras corren, verifica que el formulario tenga campos obligatorios, prepara preguntas sobre datos faltantes y resume la política interna. No redacta la recomendación final porque depende de los tres resultados. El registro durable vincula cada handle con su call_id, proveedor, tenant, versión de solicitud y job externo.

La persona corrige el país del proveedor durante la ejecución. El steer crea una nueva versión: la búsqueda de duplicados sigue siendo válida, pero las validaciones fiscal y de sanciones quedan stale y se relanzan con nuevas claves. La barrera espera solo esos dos reemplazos. Si la conexión cae, el orquestador consulta el ledger antes de reenviar. El agente produce un borrador y evidencia; crear el proveedor sigue detrás de una aprobación fresca. La concurrencia reduce espera sin convertir una corrección tardía en una escritura equivocada.

Conviene adoptar herramientas asíncronas cuando una tarea contiene operaciones lentas, independientes y observables, y cuando la latencia de pared cambia el valor del flujo. No conviene usarlas para cada llamada corta ni para ocultar un diseño sin idempotencia, cancelación o ownership. Empieza con herramientas de lectura, un máximo pequeño de jobs pendientes y una barrera explícita. Solo amplía concurrencia cuando puedes explicar qué resultado alimentó cada decisión y recuperar una ejecución interrumpida sin duplicar efectos.

Los cinco gates —dependencias, registro, barrera, steering y recuperación— convierten «seguir trabajando mientras espero» en un contrato operable. El beneficio no es mantener al modelo ocupado, sino reducir el camino crítico sin rebajar consistencia ni control. Si necesitas diseñar un agente de larga duración con herramientas, permisos, trazas y evaluaciones, el servicio de agentes a medida de Wasyra puede ayudar a construir esa capa. Es un servicio de implementación separado del producto disponible en agents.wasyra.com.