Meu orquestrador entre seis projetos não tem código, e isso foi decisão de design

Seis sistemas de trading algorítmico rodando em paralelo, cada um com o próprio agente Claude Code, cada um acumulando lições num arquivo que ninguém de fora abre. SignalForge, Equity_Tracker, Daytrading, Solo_Trader, DMR e um sexto que na época ainda não tinha código nenhum. Um achado feito numa terça dentro de um deles ficava preso ali para sempre, e o projeto vizinho gastava outra semana descobrindo a mesma coisa do zero.

Montei um analista cross-projeto para fechar esse buraco, chamado One_Ring. A pergunta que ele me obrigou a responder antes da primeira linha era de arquitetura, não de modelo: esse analista precisa de automação, de canal agente-a-agente, de despacho programático? Ou precisa só de disciplina de leitura e escrita? Fui na segunda opção, e a pasta de código-fonte continua vazia.

O problema não era falta de IA, era falta de alguém lendo todos os projetos

Cada repositório já tinha agente próprio, arquivo de lições, lista de itens de ação, documento de handoff. O que não existia era o papel de ler os seis e comparar um com o outro. Nenhum agente de projeto tem incentivo nem permissão para abrir o repositório do vizinho.

A diferença entre um achado local e um achado cruzado é maior do que parece. A comparação lado a lado revelou que o runner.py de produção de um dos sistemas checava saídas e entradas todo dia, enquanto o backtest já validado daquele mesmo sistema usava rebalanceamento semanal. A configuração diária deixava 1.200 pontos-base na mesa.

O achado virou mudança de código, com um gate semanal adicionado ao runner. Ninguém olhando só para aquele repositório tinha visto a discrepância em meses de trabalho.

A decisão central foi não escrever nenhuma linha de orquestração

O README do One_Ring diz o que ele é logo na abertura: o valor do repositório está nos documentos, não no código, e a pasta de fonte está vazia de propósito. Não é rascunho à espera de implementação. É a arquitetura.

Na prática, abro uma sessão do Claude Code, peço ao agente para ser o One_Ring e ele lê os repositórios-alvo direto do sistema de arquivos. A saída é um documento em Markdown. Os seis alvos aparecem numa tabela do README, identificados por caminho de sistema de arquivos, e um deles ainda estava marcado como pendente de scaffold quando a tabela foi escrita.

Não existe registro de agentes. Não existe configuração MCP entre os projetos, não existe barramento compartilhado, não existe despacho programático. "Agente do projeto" quer dizer uma coisa bem concreta aqui: eu abrindo outra sessão do Claude Code dentro daquele repositório.

Todo achado sai como item de ação com nome e dono, entregue ao agente do projeto a que pertence, e nenhum é aplicado sozinho. O que esse desenho ganha é que o orquestrador nunca mexe num sistema que não é dele. O que ele cobra é que nada anda sem mim no meio: a análise só vira mudança quando eu abro a segunda sessão e mando aplicar.

O orquestrador já generalizou errado e teve que se retratar

Uma nota de achado afirmou que um dos projetos já tinha resolvido a disciplina de paridade. Uma varredura de correção feita depois, naquele mesmo projeto, encontrou três bugs de paridade entre críticos e altos. A generalização não envelheceu mal: ela já estava errada no dia em que foi escrita.

Numa janela de poucos dias, três recomendações do orquestrador precisaram ser invertidas depois de contestação do agente do projeto afetado. Três retratações não é ruído estatístico; é sintoma de um jeito de errar.

O padrão ficou descrito assim na documentação do próprio projeto: um endosso com detalhe operacional não é neutro em relação ao enquadramento. Recomendar algo específico já embute uma leitura do problema, e essa leitura pode estar torta antes mesmo de a recomendação sair. A mitigação que adotei é declarar a suposição de enquadramento em uma frase, antes de qualquer recomendação. Reduz o risco e não elimina — é estrutural no modelo consultivo.

Rodar isso custa uma pessoa por passada e um orçamento de token que nunca foi medido

Não existe executor agendado. Não existe comando de linha, nem detecção automática de diferença entre projetos. Cada passada começa comigo abrindo a sessão e escolhendo quais documentos entram na leitura, e só acontece quando eu decido que deve acontecer.

O único jeito de contexto atravessar sessões é o que está escrito em documento, e daí vem o segundo custo. Um perfil de sistema é uma foto de um instante; os sistemas não são. Um perfil com poucos dias de idade já apresentou desvio material em projeto que recebia remessas substanciais de mudança quase todo dia.

O terceiro é o que menos gosto de admitir: não existe registro de custo de token de nenhuma passada do orquestrador. O único número de custo que tenho pertence a uma tarefa interna de um dos projetos-alvo, e não serve de proxy para nada. Passadas de análise leem perfis inteiros, documentos de análise e repositórios completos — é operação de contexto alto rodando sem orçamento definido.

Aceito os três porque a alternativa é pior, e ela tem nome: deixar o orquestrador agir sozinho sobre sistemas que não são dele, com perfil vencido, sem ninguém conferindo. O custo da disciplina manual é visível e chato de pagar todo mês; o custo do erro automático não aparece até o dia em que aparece inteiro.

O que já mudou, e o ponto cego que continua aberto

Uma prática entrou em vigor por causa desses erros: lição de um projeto só vira princípio cross-sistema quando pelo menos dois projetos bateram na mesma parede de forma independente. Foi assim que "premissas de spec são evidência, não suposição" saiu de um repositório só e virou regra para todos.

Outra está escrita e não automatizada: varrer as diferenças antes de reescrever qualquer perfil de sistema, em vez de gerar o perfil inteiro de novo a cada passada. A disciplina existe no documento; a ferramenta que a executa, não.

Se eu recomeçasse hoje, mediria custo de token por passada desde a primeira. É o maior ponto cego confessado da arquitetura, e é o único dos três limites que se fecha com instrumentação em vez de disciplina.

Coordenação manual bem disciplinada vem antes de qualquer automação

O que o caso provou é modesto e me poupou meses de trabalho: o orquestrador não precisava de autonomia. Precisava de leitura disciplinada e de um canal de volta em forma de item de ação com nome e dono.

Zero código aqui não é limitação técnica. É a lição do agente vácuo aplicada à própria arquitetura — um orquestrador decidindo sozinho sobre seis sistemas que não são dele teria mais chance de agir sobre contexto vencido do que de ajudar. Antes de automatizar a coordenação entre agentes, prove que a coordenação manual já produz achado que vira mudança de código. Depois disso, e só depois, escolha o que vale automatizar.