[🛠] AI Orchestration #3: Testei o AI Orchestrator informando apenas o objetivo pelo Telegram

✨ Resumo do GPT-5.6 Sol

Um registro de pedir apenas o resultado pelo Telegram, sem indicar caminho do projeto ou Agent, e corrigir cada obstáculo até receber o PDF e o XLSX.

Objetivos em linguagem natural pelo Telegram e descoberta automática do projeto

Eu queria dizer “crie este resultado” no Telegram e deixar o AI Orchestrator encontrar o projeto, dividir o trabalho, corrigir resultados problemáticos e devolver os arquivos. Se ele apenas chamasse o Codex uma vez e entregasse uma resposta, não haveria muito motivo para construir um Orchestrator.

O primeiro obstáculo foi a permissão. Mesmo dentro do Cell de cada funcionário, as restrições globais do Codex dificultavam encontrar projetos fora do Workspace aberto inicialmente. Removi essa limitação para projetos pertencentes ao mesmo usuário do macOS, mas mantive a aprovação imediatamente antes de ações com impacto externo, como push, deploy e envio de mensagens.

Recuperação de respostas e anexos por Topic com uma CLI em Telethon

Criei uma CLI baseada em Telethon para enviar comandos ao Bot do AI Orchestrator e receber respostas e anexos. As credenciais e a Session do usuário ficaram fora do repositório, e cada Topic de projeto virou uma unidade de trabalho.

A primeira CLI podia encerrar com sucesso depois de apenas enviar a mensagem. O comando parecia concluído mesmo quando a resposta final do Bot ou o arquivo nunca chegavam.

Mudei o critério de conclusão: em vez do encerramento do comando local, passou a valer o recebimento real da resposta e do anexo no Telegram. Mesmo enviando trabalhos simultaneamente para Topics diferentes, cada OpenClaw Session manteve seu contexto separado e devolveu o resultado ao Topic original.

Divisão de responsabilidades entre OpenClaw Session e execução paralela no Codex

Tarefas curtas criadas diretamente pelo OpenClaw perdiam eventos de conclusão, enquanto os native sub-agents do Codex reuniam os resultados paralelos de forma estável. Uma estrutura que concluía o trabalho, mas não recuperava sua conclusão, não poderia ser a base de execução do Orchestrator.

Somente o Task Flow do OpenClaw dificultava vincular execução e conclusão das tarefas filhas a um único registro de referência. Deixei de tratá-lo como fonte única: OpenClaw cuida de Telegram, Topics, Sessions e Memory; Codex cuida da descoberta de projetos, decomposição do trabalho, execução paralela, integração e revalidação.

Streaming do progresso no Telegram

Sem mensagens durante um trabalho longo, não dava para saber se ele havia parado. Exibir os comandos internos fazia o Telegram parecer um despejo de terminal. Durante a execução, atualizei no máximo quatro linhas de status em coreano e apaguei a mensagem quando o resultado final chegou.

Assim, só pelo Telegram, eu já distinguia se o sistema estava procurando material ou produzindo o entregável.

Seleção automática de Agent, Skill e Tool com revalidação dos entregáveis

Depois que as funções individuais foram conectadas, testei de propósito a forma de uso mais inconveniente. Assumi o papel de decisor final, coloquei o Codex como CEO interino e passei ao AI Orchestrator somente o resultado esperado. Não especifiquei caminho do projeto, modelo, Agent, Skill, Tool nem ordem de execução.

O AI Orchestrator encontrou o projeto adequado, escolheu os Skills e Tools necessários e executou em paralelo native sub-agents do Codex para planejamento, engenharia e validação. Ele dividiu quem faria o quê sem que eu informasse caminho ou método.

O PDF e o XLSX devolvidos também não vieram corretos na primeira tentativa. Renderizei novamente o PDF com uma fonte TTF porque uma TTC havia quebrado o texto em coreano. No XLSX, corrigi a exibição das datas e a estrutura das colunas, depois conferi novamente as fórmulas e a renderização de todas as planilhas.

Vinte e dois minutos e seis segundos após o pedido, o PDF do brief de decisão do CEO Pilot e o XLSX de gestão de execução de duas semanas voltaram ao Topic original do Telegram. Os SHA-256 dos arquivos baixados novamente pelo Telegram eram iguais aos originais gerados. Não era apenas uma mensagem dizendo que havia concluído: os arquivos reais fizeram todo o percurso de ida e volta.

Validação E2E de usuário único e lacuna de isolamento multiusuário

O E2E de usuário único chegou ao fim, mas 22 minutos ainda eram demais para pequenas tarefas cotidianas. O mesmo Agent que criou os entregáveis finais também os revisou, portanto eu não poderia chamar isso de verificação independente. Eu também ainda não havia testado um controller que gerenciasse todos os estados das tarefas filhas em um único Task Graph e confirmasse a conclusão final uma única vez, nem o isolamento de Sessions entre funcionários.

O próximo dogfooding precisa primeiro confirmar que as Sessions de dois funcionários realmente não se misturam. Depois disso, preciso encontrar o maior gargalo do fluxo de 22 minutos. Os dois pontos precisam passar antes de sair do dogfooding pessoal para um sistema usado em conjunto pelos funcionários.