[🛠] AI Orchestration #4: Reduzi de 22 para 9 minutos uma tarefa de acompanhamento no Telegram

✨ Resumo do GPT-5.6 Sol

Um registro de como encontrei em um canary real um autodeadlock na mesma Session, buscas repetidas e verificações improvisadas, e reduzi em 57,6% o tempo de retorno de arquivos no Telegram reutilizando geradores, verificadores e retrabalho parcial.

Um autodeadlock causado por um canary na mesma Session

No dogfooding do dia anterior, informei apenas o objetivo pelo Telegram e recebi um PDF e um XLSX. O fluxo passou pela descoberta do projeto, divisão de papéis, execução paralela, retrabalho e devolução dos arquivos, mas levou 22 minutos e 6 segundos. Se todo pequeno acompanhamento demorasse isso, o uso cotidiano seria frustrante.

Não construí um benchmark separado. Enviei outro objetivo no mesmo Topic do Telegram: “mantenha a qualidade, mas reduza os 22 minutos”. Queria ver se o AI Orchestrator encontraria os gargalos reais, corrigiria o Workflow compartilhado e concluiria sozinho a tarefa seguinte com arquivos.

A primeira validação entrou imediatamente em deadlock. Enquanto processava a solicitação atual, o AI Orchestrator enviou um canary para a mesma Session e ficou esperando a resposta. A nova solicitação só poderia começar quando o turn atual terminasse, enquanto o processo pai não podia terminar porque esperava justamente essa nova solicitação.

Encerrei apenas a CLI que estava aguardando e separei o Topic da mudança de produto do Topic do canary. Não era uma falha do modelo em executar o trabalho. Era um problema de limite de execução: um Orchestrator não pode esperar a próxima tarefa dentro de uma Session que ele próprio mantém ocupada.

Reutilização de geradores e verificadores no retrabalho parcial

O primeiro canary em um Topic independente devolveu os arquivos em 17 minutos e 35 segundos. Foi mais rápido, mas o resultado marcou novamente como pendente de aprovação um Pilot já aprovado. Reduzir o tempo não bastava para considerar o teste aprovado.

Ao acompanhar a execução real, encontrei buscas repetidas pelas mesmas evidências, polling de trabalhos filhos e verificações de dependencies feitas tarde demais, depois que a geração dos artefatos já tinha começado. Também havia um custo considerável em criar caminhos de verificação parecidos com os existentes, em vez de reutilizar os geradores e verifiers validados de PDF e XLSX.

Mantive apenas estas regras no Workflow compartilhado:

• Fixar as evidências necessárias em um único snapshot limitado.
• Recolher resultados filhos por eventos de conclusão, sem polling repetido.
• Reutilizar um gerador ou verifier existente em vez de criar outra implementação.
• Aplicar somente as diferenças das decisões e métricas mais recentes e retrabalhar apenas o escopo com defeito.
• Executar uma única validação final no artefato completo e alinhar o Source provenance.

Corrigi somente o estado de aprovação e o texto incorretos do primeiro resultado e repeti a renderização completa e a abertura e gravação independentes. O novo fluxo não reconstruía tudo do zero: alterava apenas o que tinha ficado semanticamente desatualizado e depois verificava novamente a integridade de todo o resultado.

Retorno pelo Telegram em 9 minutos e 23 segundos com o limite de qualidade preservado

O canary de retrabalho devolveu o PDF e o XLSX pelo Telegram em 9 minutos e 23 segundos, sem intervenção do usuário. Isso foi 57,6% mais rápido que os 22 minutos e 6 segundos iniciais, enquanto as chamadas de ferramentas de Orchestration caíram de 56 para 21.

O ganho não veio de pular verificações. Revisei novamente a renderização, estrutura, conteúdo, fórmulas e o open/re-save independente do PDF de duas páginas e do XLSX de quatro planilhas. Os arquivos baixados novamente pelo Telegram também tinham o mesmo hash dos originais gerados. Por fim, o sistema percebeu que o Workflow provenance gravado nos arquivos ainda apontava para um hash antigo e corrigiu apenas esse valor, sem alterar o conteúdo ou a estrutura.

A decisão mais importante foi não contar o primeiro resultado de 17 minutos como sucesso. Se a decisão mais recente está errada, reduzir o tempo só produz o resultado incorreto mais depressa. A melhoria foi aprovada porque o tempo real de retorno caiu sem afrouxar o Gate de qualidade.

Limite entre o v0.1 de um usuário e o Pilot multiusuário

O v0.1 atual para um usuário já consegue receber um objetivo em linguagem natural, encontrar o projeto, dividir o trabalho, verificar os resultados e devolvê-los pelo Telegram. Mesmo assim, ainda é cedo para chamar isso de operação totalmente autônoma. No papel de CEO, eu ainda precisei interromper o autodeadlock na mesma Session, apontar o erro semântico do primeiro resultado e pedir o commit local que estava faltando.

O próximo passo não é outro benchmark. Preciso continuar atribuindo trabalho real e não sensível sob o mesmo limite de qualidade, acumular tempos de resposta e observar a distribuição e as regressões. Quando a conexão de outro usuário for aprovada, também será necessário verificar que duas Cells consigam executar simultaneamente sem misturar Sessions, Memory ou arquivos. Um Task Flow controller completo não é o gargalo crítico do caminho atual do usuário, então permanece como uma frente separada de longo prazo.