[🛠] AI Orchestration #3: Probé el AI Orchestrator dándole solo un objetivo por Telegram

✨ Resumen de GPT-5.6 Sol

Un registro de cómo pedí solo el resultado por Telegram, sin indicar la ruta del proyecto ni el Agent, y fui corrigiendo cada obstáculo hasta recibir el PDF y el XLSX.

Objetivos en lenguaje natural por Telegram y descubrimiento automático del proyecto

Quería decir «crea este resultado» en Telegram y que el AI Orchestrator encontrara el proyecto, repartiera el trabajo, corrigiera los resultados defectuosos y devolviera los archivos. Si solo llamaba una vez a Codex y entregaba una respuesta, no había demasiado motivo para construir un Orchestrator.

El primer obstáculo fueron los permisos. Incluso dentro del Cell de cada empleado, las restricciones globales de Codex dificultaban encontrar proyectos fuera del Workspace abierto al inicio. Eliminé esa limitación para los proyectos del mismo usuario de macOS y mantuve la aprobación justo antes de acciones con impacto externo, como push, despliegues o envíos.

Recuperación de respuestas y adjuntos por Topic con una CLI de Telethon

Construí una CLI basada en Telethon para enviar órdenes al Bot del AI Orchestrator y recibir sus respuestas y adjuntos. Dejé las credenciales y la Session del usuario fuera del repositorio y usé cada Topic de proyecto como unidad de trabajo.

La primera CLI podía terminar con éxito después de limitarse a enviar el mensaje. La orden parecía correcta aunque nunca llegaran la respuesta final del Bot ni el archivo.

Cambié el criterio de finalización: ya no era que terminara el comando local, sino recibir realmente la respuesta y el adjunto de Telegram. Aunque enviara tareas a distintos Topics al mismo tiempo, cada OpenClaw Session mantenía su contexto separado y devolvía el resultado al Topic original.

Reparto de responsabilidades entre OpenClaw Session y la ejecución paralela de Codex

Las tareas cortas creadas directamente por OpenClaw perdían eventos de finalización, mientras que los native sub-agents de Codex reunían de forma estable los resultados paralelos. Una estructura que terminaba el trabajo pero no podía recuperar su finalización no servía como base de ejecución del Orchestrator.

Solo con el Task Flow de OpenClaw era difícil vincular la ejecución y el estado final de las tareas hijas a un único registro de referencia. Dejé de usar Task Flow como única fuente de verdad: OpenClaw se ocupa de Telegram, Topics, Sessions y Memory; Codex, del descubrimiento de proyectos, la división del trabajo, la ejecución paralela, la integración y la nueva validación.

Streaming del estado de progreso en Telegram

Si una tarea larga no decía nada, era imposible saber si se había detenido. Si mostraba los comandos internos, Telegram parecía un volcado de terminal. Durante la ejecución actualicé un máximo de cuatro líneas de estado en coreano y eliminé ese mensaje cuando llegó el resultado final.

Así podía distinguir desde Telegram si estaba buscando material o produciendo el entregable.

Selección automática de Agent, Skill y Tool con revalidación de entregables

Cuando las funciones individuales ya estaban conectadas, probé deliberadamente la forma de uso más incómoda. Actué como máximo responsable, encargué a Codex el papel de CEO en funciones y le indiqué al AI Orchestrator únicamente el resultado. No especifiqué ruta del proyecto, modelo, Agent, Skill, Tool ni orden de ejecución.

El AI Orchestrator encontró el proyecto adecuado, eligió los Skills y Tools necesarios y ejecutó en paralelo native sub-agents de Codex para planificación, ingeniería y validación. Repartió quién debía hacer cada cosa sin que yo le indicara la ruta ni el método.

El PDF y el XLSX tampoco llegaron bien a la primera. Volví a renderizar el PDF con una fuente TTF porque una TTC había roto el texto coreano. En el XLSX corregí las fechas y la distribución de columnas, y después revisé de nuevo las fórmulas y la visualización de todas las hojas.

Veintidós minutos y seis segundos después de la petición, el PDF con el informe de decisión del CEO Pilot y el XLSX de gestión de ejecución de dos semanas regresaron al Topic original de Telegram. Los SHA-256 de los archivos descargados otra vez desde Telegram coincidían con los originales generados. No era solo un mensaje diciendo que había terminado: los archivos reales habían completado el recorrido de ida y vuelta.

Validación E2E de un solo usuario y brecha de aislamiento multiusuario

El E2E de un solo usuario llegó hasta el final, pero 22 minutos seguían siendo demasiado para tareas cotidianas pequeñas. El mismo Agent que creó los entregables finales también los revisó, por lo que no podía llamarlo verificación independiente. Tampoco había probado todavía un controller que gestionara todos los estados de tareas hijas en un solo Task Graph y confirmara la finalización una sola vez, ni el aislamiento de Sessions entre empleados.

El siguiente dogfooding debe comprobar primero que las Sessions de dos empleados no se mezclan. Después tengo que localizar el mayor cuello de botella del flujo de 22 minutos. Ambas pruebas deben superarse antes de pasar del dogfooding personal a un sistema usado por varios empleados.