[🛠] AI Orchestration #4: Reduje de 22 a 9 minutos una tarea de seguimiento por Telegram

✨ Resumen de GPT-5.6 Sol

Un registro de cómo encontré en un canary real un autobloqueo dentro de la misma Session, búsquedas repetidas y verificaciones improvisadas, y reduje un 57,6 % el tiempo de devolución de archivos por Telegram reutilizando generadores, verificadores y retrabajo parcial.

Un autobloqueo provocado por un canary en la misma Session

En el dogfooding del día anterior, di únicamente un objetivo por Telegram y recibí un PDF y un XLSX. El flujo cubrió el descubrimiento del proyecto, la división de roles, la ejecución paralela, el retrabajo y la devolución de archivos, pero tardó 22 minutos y 6 segundos. Si cada pequeño seguimiento tardaba lo mismo, usarlo de verdad resultaría frustrante.

No construí un benchmark aparte. Envié otro objetivo al mismo Topic de Telegram: «mantén la calidad, pero reduce los 22 minutos». Quería comprobar directamente si el AI Orchestrator podía encontrar los cuellos de botella reales, corregir el Workflow compartido y terminar por sí mismo la tarea posterior con archivos.

La primera validación se bloqueó de inmediato. Mientras procesaba la solicitud actual, el AI Orchestrator envió un canary a la misma Session y se quedó esperando su respuesta. La nueva solicitud no podía ejecutarse hasta que terminara el turn actual, pero el proceso padre tampoco podía terminar porque esperaba esa nueva solicitud.

Detuve únicamente la CLI que estaba esperando y separé el Topic del cambio de producto del Topic del canary. No era un problema de incapacidad del modelo, sino de límites de ejecución: un Orchestrator no debe esperar la siguiente tarea dentro de una Session que él mismo mantiene ocupada.

Reutilización de generadores y verificadores para un retrabajo parcial

El primer canary ejecutado en un Topic independiente devolvió los archivos en 17 minutos y 35 segundos. Era más rápido, pero el resultado volvió a marcar como pendiente de aprobación un Pilot que ya estaba aprobado. Reducir el tiempo no bastaba para declararlo correcto.

Al seguir la ejecución real vi que buscaba varias veces las mismas pruebas, hacía polling de los trabajos secundarios y comprobaba las dependencies demasiado tarde, cuando la generación ya había comenzado. También había un coste considerable por crear rutas de verificación parecidas a otras ya existentes en vez de reutilizar los generadores y verificadores validados de PDF y XLSX.

Dejé solo estas reglas en el Workflow compartido:

• Fijar las pruebas necesarias en un único snapshot acotado.
• Recoger los resultados secundarios mediante eventos de finalización, sin polling repetido.
• Reutilizar un generador o verifier existente en lugar de crear otra implementación.
• Aplicar solo las diferencias de la decisión y las métricas más recientes, y retrabajar únicamente el alcance defectuoso.
• Ejecutar una sola validación final sobre el artefacto completo y alinear su Source provenance.

Corregí únicamente el estado de aprobación y el texto erróneos del primer resultado y repetí el renderizado completo y la comprobación independiente de apertura y guardado. El nuevo flujo no reconstruía todo desde cero: cambiaba solo lo que había quedado semánticamente obsoleto y volvía a comprobar la integridad del resultado completo.

Devolución por Telegram en 9 minutos y 23 segundos con la calidad intacta

El canary de retrabajo devolvió el PDF y el XLSX por Telegram en 9 minutos y 23 segundos, sin intervención del usuario. Fue un 57,6 % más rápido que los 22 minutos y 6 segundos iniciales, y las llamadas a herramientas de Orchestration bajaron de 56 a 21.

La mejora no salió de omitir comprobaciones. Volví a revisar el renderizado, la estructura, el contenido, las fórmulas y la apertura y guardado independientes del PDF de dos páginas y del XLSX de cuatro hojas. Los archivos descargados de nuevo desde Telegram tenían el mismo hash que los originales generados. Al final también apareció un Workflow provenance que aún apuntaba a un hash anterior, y se corrigió solo ese valor sin alterar el contenido ni la estructura.

La decisión más importante fue no contar como éxito el primer resultado de 17 minutos. Si la decisión más reciente es incorrecta, reducir el tiempo solo produce antes el resultado equivocado. Esta mejora pasó porque el tiempo real de devolución bajó sin relajar el Gate de calidad.

Límite entre la versión 0.1 de un solo usuario y el Pilot multiusuario

La versión 0.1 actual para un solo usuario ya puede recibir un objetivo en lenguaje natural, encontrar el proyecto, dividir el trabajo, verificar los resultados y devolverlos por Telegram. Aun así, es pronto para llamarlo funcionamiento totalmente desatendido. Todavía tuve que detener, en el papel de CEO, el autobloqueo de la misma Session, señalar el error semántico del primer resultado y pedir el commit local que faltaba.

El siguiente paso no es otro benchmark. Necesito seguir asignando trabajo real y no sensible con el mismo límite de calidad, acumular tiempos de respuesta y observar su distribución y sus regresiones. Cuando se apruebe la conexión de otro usuario, también habrá que verificar que dos Cells puedan ejecutarse a la vez sin mezclar Sessions, Memory ni archivos. Un Task Flow controller completo no es ahora el cuello de botella crítico de esta ruta de usuario, así que queda como una línea separada a largo plazo.