# Todos na Mesma Página: A Equipe Híbrida
Até aqui, o sistema funciona com um agente só. O Claude lê o Segundo Cérebro, acessa os dossiês, produz as entregas. Para muitos profissionais, isso já basta. Mas quando o volume cresce, ou quando os dados são sensíveis demais para sair do computador, a arquitetura precisa se expandir.
Este é o módulo mais técnico da trilha. Mas vou manter a promessa: sem código. O que você precisa entender aqui é a lógica de coordenação, não a implementação técnica. Se você entender por que três agentes precisam de um “contrato” para trabalhar juntos, e por que parte desse trabalho não pode sair do seu computador, já está na frente de 99% dos profissionais que usam IA.
Por Que Uma Equipe Híbrida
Cada modelo de IA tem forças diferentes. Em 2026, a distinção mais importante não é só qual modelo é mais capaz, mas onde ele processa os dados: na nuvem de terceiros ou dentro do seu próprio computador.
O Claude (nuvem) é forte em escrita longa, análise de tom, produção editorial e raciocínio complexo. É o agente que conhece seus clientes pelos dossiês e produz as entregas finais.
O Gemini CLI (nuvem com capacidade local) é forte em processamento de arquivos, automações de sistema e interação com APIs. Se você precisa renomear 200 arquivos seguindo uma regra, converter formatos em lote ou processar planilhas, o Gemini CLI faz isso rápido e direto via linha de comando.
Um modelo local via Ollama (como o Gemma 4) roda dentro do seu computador, sem enviar dados para fora da sua rede. Para analisar histórico de pacientes, processar acordos confidenciais ou qualquer material com restrição regulatória explícita, essa é a opção mais segura. Não é obrigatório para o sistema funcionar, mas é o recurso certo quando a nuvem simplesmente não é uma alternativa.
No estúdio, a divisão de trabalho funciona assim: Claude cuida da produção editorial (roteiros, captions, dossiês, análises estratégicas). Gemini CLI cuida de automações locais (processamento de SRTs em lote, organização de arquivos, operações no sistema operacional). Um modelo local como o Gemma 4 entra quando o dado tem restrição que impede o uso da nuvem: histórico clínico, documentos sob cláusula de confidencialidade, transcrições de audiências sigilosas. Esse terceiro agente é uma expansão do menu, não um requisito base.
Três agentes, cada um no que faz melhor. Mas isso cria um problema: como garantir que um sabe o que o outro fez?
O Problema da Memória Fragmentada
Se cada agente trabalha isolado, o sistema vira uma equipe de três pessoas que não se falam. O Claude produz um roteiro e salva numa pasta. O Gemini CLI processa os SRTs e salva em outra. Ninguém sabe o que o outro fez, quando fez, nem por quê.
O resultado: duplicação de trabalho, conflitos de arquivo, decisões tomadas sem contexto. O sistema que deveria economizar tempo passa a gerar retrabalho.
A solução para isso tem dois pilares: um repositório compartilhado e um changelog.
O Repositório Compartilhado (Git)
Git é um sistema de controle de versão. Originalmente feito para programadores, ele serve para qualquer cenário onde múltiplas entidades (pessoas ou agentes) precisam trabalhar nos mesmos arquivos sem se pisar.
Na prática, o vault do Obsidian (seu Segundo Cérebro) vive dentro de um repositório Git. Quando um agente cria, modifica ou apaga um arquivo, ele registra essa mudança com um commit (uma espécie de carimbo que diz: “às 14h03, eu criei o arquivo roteiro-cliente-reel-47.md”).
Quando o próximo agente abre o repositório, ele puxa as atualizações e vê tudo que mudou desde a última vez. Não precisa perguntar. Não precisa procurar. O Git conta a história.
Para quem nunca usou Git, isso pode parecer técnico. E é. Mas a boa notícia é que a configuração é feita uma vez. Depois que o repositório está funcionando, os agentes fazem commits automaticamente como parte do protocolo de entrega. Você não precisa digitar comandos de Git no dia a dia. O sistema cuida disso.
O Changelog: O Contrato Entre Agentes
O Git registra o que mudou, mas não registra o porquê. Para isso, existe o changelog.
O changelog é um arquivo Markdown na raiz do Segundo Cérebro. Toda vez que um agente faz uma entrega, ele adiciona uma entrada no topo do changelog: data, hora, o que foi feito, para qual cliente, qual arquivo foi criado ou modificado. Uma linha. Às vezes duas.
Parece simples. É. E é exatamente por isso que funciona.
Quando o Claude abre o vault para produzir as entregas de uma cliente, a primeira coisa que ele faz é ler o changelog. Ele vê que às 10h15 o Gemini CLI processou os SRTs do Reel 47 e salvou em tal pasta. Ele vê que ontem o próprio Claude produziu as entregas do Reel 46. Ele sabe o que já foi feito e o que falta.
Sem o changelog, o Claude precisaria vasculhar o vault inteiro para entender o estado atual do trabalho. Com o changelog, ele lê 10 linhas e sabe tudo.
O changelog é o contrato social entre agentes. É a garantia de que nenhum agente trabalha às cegas. E é a peça que faz a coordenação funcionar sem que você precise ser o gerente de três agentes ao mesmo tempo.
O Custo Invisível das Instruções Longas
Até aqui, falamos de como agentes precisam compartilhar repositório e changelog para não trabalhar às cegas. Há um problema mais sutil, que aparece antes mesmo de o agente começar qualquer tarefa: o custo de ler as próprias instruções.
Cada agente tem um arquivo de instruções, o equivalente ao manual de operação da equipe. No sistema do estúdio, esse arquivo existe na raiz do vault (o GEMINI.md ou CLAUDE.md) e define as regras que valem para qualquer sessão: terminologia, protocolo de entrega, onde salvar cada tipo de arquivo.
O problema: esses arquivos crescem. Cada novo cliente que entra, cada nova regra aprendida, cada exceção mapeada vai sendo acrescentada. Em seis meses de operação, o arquivo que tinha 2 páginas passa a ter 20. E toda sessão começa com o agente lendo essas 20 páginas antes de fazer qualquer coisa.
Isso tem um custo real. Modelos de linguagem têm janela de atenção limitada. Quanto mais espaço as instruções ocupam, menos atenção sobra para o trabalho em si. Pior: regras críticas enterradas no meio de texto longo têm maior chance de serem ignoradas do que se estivessem num arquivo enxuto.
A solução é modularizar. Em vez de um arquivo único que cresce sem limite, o sistema usa dois níveis:
Instruções globais (raiz do vault): Só o que vale para qualquer sessão, com qualquer cliente, em qualquer contexto. Terminologia básica. Protocolo de entrega. Onde fica o changelog. Onde ficam os clientes. No máximo uma página de texto.
Instruções por cliente (pasta do cliente): Tudo que é específico daquele contexto. Tom de voz. Histórico de revisões. Regras editoriais particulares. Nomes próprios. O agente carrega esse arquivo só quando está atuando naquela pasta.
No estúdio, fizemos essa auditoria depois de perceber que o arquivo principal de instruções tinha chegado a 15.000 caracteres, o equivalente a umas 20 páginas de texto. Após a limpeza, ficou em 2.700 caracteres. A economia por sessão foi de cerca de 3.000 tokens. Mas o ganho real não foi no preço: foi na qualidade da atenção. Regras que antes ficavam enterradas no meio de texto longo passaram a ser lidas de verdade, porque o arquivo parou de parecer um manual de aviação.
O que infla um arquivo de instrução
Antes de saber como limpar, vale entender o que cresce. Existem cinco culpados típicos:
Listas de clientes inline. O arquivo lista todos os clientes, seus nichos, seus projetos e suas particularidades num único bloco. Com 5 clientes isso parece razoável. Com 10, o arquivo já tem mais contexto de cliente do que contexto de operação.
Exemplos longos de correção. “Quando o agente escrever X, deve escrever Y porque Z.” Isso é útil quando acontece pela primeira vez. Depois de 30 ocorrências, o arquivo virou um glossário de erros antigos, não um manual de trabalho atual.
Histórico de decisões. O registro de por que foi decidido usar tal formato, tal nomenclatura ou tal fluxo em determinada data. Importante para entender o passado, mas o agente não precisa desse histórico para produzir hoje.
Regras redundantes. A mesma instrução escrita de três formas diferentes em partes diferentes do arquivo, porque foi adicionada em momentos diferentes sem revisão do que já existia.
Contexto de projetos concluídos. Instruções específicas de clientes que saíram, projetos que encerraram ou experimentos que foram abandonados.
A auditoria em quatro passos
Passo 1. Imprima (ou leia do início ao fim). Não edite enquanto lê. Só marque cada bloco com uma das três categorias: Global (vale sempre), Cliente (específico de contexto) ou Morto (não vale mais nada).
Passo 2. Mova o que é de cliente. Tudo que foi marcado como Cliente vai para o arquivo de instruções da pasta correspondente. Se o cliente ainda está ativo, a instrução vai para o INSTRUCOES.md ou GEMINI.md da pasta dele. Se o cliente não existe mais, descarte.
Passo 3. Comprima o que ficou. O que restou no arquivo global provavelmente tem redundâncias. Agrupe regras similares. Troque listas longas por referências: em vez de listar os 15 termos que o agente não pode usar, crie um documento separado chamado MANUAL_TERMINOLOGIA.md e no arquivo global escreva apenas “consultar MANUAL_TERMINOLOGIA.md para lista completa”.
Passo 4. Teste com uma sessão real. Abra uma sessão com o arquivo novo, peça ao agente para fazer uma tarefa do dia a dia. Se ele errar algo que estava coberto no arquivo antigo mas não está no novo, você tem a resposta: aquela instrução era necessária e precisa voltar, mas no lugar certo.
Como saber se funcionou
O arquivo global está no tamanho certo quando você consegue ler ele inteiro em menos de 2 minutos. Não é uma métrica exata, mas funciona: se você mesmo precisaria tomar café para chegar no final, o agente também vai perder o fio antes.
O exercício não precisa ser perfeito na primeira vez. Faça o que der, teste, ajuste. O que importa é criar o hábito: toda nova regra que entra já nasce com endereço certo (global ou cliente) em vez de ir parar no final de um arquivo que ninguém lê por completo.
Quando Usar Cada Agente
Uma dúvida razoável: como decidir qual agente chamar para cada tarefa?
A regra prática que uso tem duas dimensões: tipo de tarefa e sensibilidade dos dados.
Se a tarefa envolve escrita, análise, estratégia ou produção editorial com dados que podem ir à nuvem: Claude. Se a tarefa envolve processamento de arquivos, automação local ou operações de sistema: Gemini CLI. Se a tarefa envolve dados que não podem sair do computador por restrição regulatória ou contratual, e você tem um modelo local instalado: use o modelo local. Se não tem, e o dado não é ultra-sensível, o Claude com bom senso editorial já resolve.
Na dúvida, comece com o Claude para testar o raciocínio. Se o dado for sensível demais para a nuvem, mude para o modelo local antes de enviar qualquer coisa. Com o tempo, você desenvolve intuição para essa divisão. Assim como um gestor sabe quem é bom em quê, você vai saber qual agente chamar para cada situação.
O Exercício Deste Módulo
Se você ainda não usa Git, este é o módulo onde vale a pena configurar. Instale o Git no seu computador (git-scm.com) e inicialize um repositório no seu vault do Obsidian. A configuração leva 10 minutos com um tutorial básico.
Crie um arquivo chamado “CHANGELOG DO SISTEMA.md” na raiz do vault. Escreva a primeira entrada: data, hora, “Início do changelog. Sistema de coordenação entre agentes ativado.”
A partir daqui, toda vez que você ou um agente fizer algo relevante no vault, adicione uma linha no topo do changelog. Em duas semanas, esse arquivo vai ser o mapa mais útil do seu sistema.
Se Git parece complicado agora, tudo bem. Use apenas o changelog por enquanto. Mesmo sem Git, o hábito de registrar ações num log central já elimina boa parte do problema de memória fragmentada.
Considerações Finais
Coordenar agentes é o passo que transforma um assistente pessoal num time operacional. Quando três agentes compartilham o mesmo repositório e o mesmo changelog, o sistema ganha uma propriedade poderosa: memória coletiva. O que um faz, todos sabem. O que um decide, fica registrado.
No Módulo 7, vamos consolidar tudo: resultados reais, rotina de manutenção e o ciclo de melhoria contínua que faz o sistema ficar mais inteligente com o uso. Se você chegou até aqui, as três camadas já estão montadas. O Segundo Cérebro dá estrutura. O agente com dossiês dá qualidade. O pipeline dá escala. E a coordenação híbrida que acabamos de montar dá sustentação e privacidade.
Se quiser aprofundar a camada local (IA rodando no seu hardware, custo zero, privacidade absoluta), os Módulos 8 a 12 formam a Fase 2 da trilha. Se preferir implementação acompanhada, o intensivo ao vivo é a opção. Deixe seu e-mail na lista de espera.
A gente se vê no Módulo 7.
Perguntas Frequentes
Git é obrigatório? Para coordenar múltiplos agentes com segurança, sim. Mas se você usa apenas o Claude como agente único, o changelog no Obsidian já resolve a maior parte do problema de memória fragmentada. Git adiciona versionamento (a capacidade de desfazer mudanças), o que se torna essencial à medida que o sistema cresce.
Preciso aprender linha de comando para usar o Gemini CLI? Para tarefas simples (renomear arquivos, processar em lote), não. O Gemini CLI aceita instruções em linguagem natural pelo terminal. A curva de aprendizado é menor do que parece. O investimento real é instalar e fazer a configuração inicial, que leva cerca de 15 minutos.
E se eu não precisar de três agentes? A maioria dos profissionais começa com Claude só e está bem servida. O Módulo 6 existe para quando o volume justifica a expansão. Se você atende 3 clientes com 2 entregas por mês cada, um agente basta. Se atende 9 clientes com 4 entregas por mês cada, a coordenação começa a fazer diferença real.
O sistema funciona no Windows? Sim. Git, Obsidian, Ollama e Gemini CLI têm versões para Windows. Os comandos de terminal variam (PowerShell em vez de Zsh no Mac), mas a arquitetura do sistema é a mesma. Os conceitos de changelog, repositório compartilhado e divisão de agentes funcionam independentemente do sistema operacional.