Até aqui, o sistema pode funcionar com um agente. Para muitos profissionais, isso já basta. Quando mais de um agente participa, o problema principal deixa de ser escolher o modelo mais forte. Passa a ser coordenar papéis, fontes, permissões e estados sem duplicar trabalho.
Este é o módulo mais técnico da trilha, mas o exercício não exige código. Você precisa entender por que dois ou mais agentes necessitam de um contrato de tarefa e por que a classificação do dado vem antes da escolha entre serviço em nuvem, ambiente local ou sistema determinístico.
Por Que Uma Equipe Híbrida
Cada agente pode ocupar uma função diferente. A divisão mais durável não é por marca. É por responsabilidade e limite.
Um agente editorial prepara textos e análises a partir de fontes delimitadas. Um agente de automação executa rotinas testadas sobre arquivos ou sistemas. Um agente operador atravessa ferramentas e registra a execução. Uma camada local pode ser útil quando a política permite processamento no equipamento e a configuração foi validada.
Esses papéis podem ser exercidos pela mesma ferramenta ou por ferramentas diferentes. A escolha depende da tarefa, do acesso necessário, da sensibilidade do material, da possibilidade de reversão e da pessoa que revisará a saída.
Executar um modelo no próprio computador não torna o fluxo automaticamente seguro. Arquivos temporários, telemetria, extensões, conectores, backups e permissões também precisam ser avaliados. Dados clínicos, jurídicos, contratuais ou pessoais só entram num teste depois da classificação e da autorização adequadas.
No nosso estúdio, a composição muda conforme a frente. O ponto transferível é registrar o papel de cada participante, as fontes permitidas, a saída esperada, a revisão humana e a condição de parada.
Mais agentes criam uma pergunta operacional: como cada participante encontra o estado correto sem presumir o que os outros fizeram?
O agente operador e a segunda opinião
Com o sistema mais maduro, a divisão fica um pouco mais fina.
Além do agente de escrita e do agente de automação, existe um papel que chamo de agente operador.
O agente operador atravessa a operação dentro das permissões recebidas: lê arquivos, usa ferramentas, confere resultados e registra mudanças. Acesso técnico não equivale a autorização para enviar, publicar, apagar ou conceder acesso.
É uma função diferente. Um agente editorial pode propor uma direção. O agente operador executa uma rotina delimitada e reversível, com checkpoints definidos.
Também existe a camada de segunda opinião. Ela recebe um pacote mínimo, sem detalhe sensível desnecessário, procura lacunas observáveis e devolve crítica para a pessoa responsável.
Isso não cria uma hierarquia onde um agente manda no outro. Cria um protocolo simples: cada agente tem papel, limite e fonte de verdade.
Criador, auditor e pessoa responsável
Um segundo agente pode funcionar como auditor, mas não como aprovador automático. O agente criador prepara a entrega. O agente auditor compara a saída com as fontes, o briefing e uma lista clara de verificações. A pessoa responsável decide o que segue, corrige ou para.
Peça ao auditor que procure itens observáveis: afirmação sem fonte, instrução ignorada, omissão relevante, contradição, dado sensível exposto ou próximo passo sem responsável. “Revise isso” é amplo demais para produzir uma segunda opinião confiável.
O problema da memória fragmentada
Se cada agente trabalha isolado, o sistema vira uma equipe de pessoas que não se falam. Um agente produz um roteiro e salva numa pasta. Outro 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 precisa de duas capacidades: versionamento recuperável e registro do estado operacional. Git e um changelog são uma combinação possível, não uma obrigação universal.
O Repositório Compartilhado (Git)
Git é um sistema de controle de versão. Ele registra versões de arquivos e permite comparar mudanças. A documentação oficial está em git-scm.com/doc.
Num fluxo configurado para isso, uma pasta de trabalho pode ser versionada por Git. As mudanças só entram no histórico quando alguém ou uma automação autorizada seleciona os arquivos e cria um commit. Horário, autoria e descrição dependem dos metadados e da mensagem registrada.
Sincronização entre máquinas ou pessoas também precisa ser configurada. Git não puxa atualizações, resolve conflitos ou explica decisões sozinho. Ele preserva diferenças e versões para que o procedimento possa compará-las e recuperá-las.
Para quem nunca usou Git, a configuração pode exigir apoio técnico. Antes de colocar um acervo real sob versionamento, teste numa pasta descartável, confirme a estratégia de backup e defina quem pode registrar, sincronizar ou reverter mudanças.
O Changelog: O Contrato Entre Agentes
Sistema Determinístico, Agente e Decisão Humana
O sistema determinístico registra, calcula, integra e preserva previsibilidade. O agente localiza padrões, compara, classifica, resume e propõe. A pessoa responsável confere a fonte, interpreta a consequência e decide.
Um agente pode acionar uma ferramenta determinística dentro de um fluxo testado. Isso não transfere para o agente a autoridade do sistema nem da pessoa responsável. ERP, prontuário, sistema jurídico, banco de dados e registro oficial continuam cumprindo funções que uma resposta probabilística não substitui.
Antes de coordenar agentes, registre para cada função: objetivo, fonte permitida, ferramenta, permissão, saída, responsável pela revisão, exceção e condição de parada.
O Git registra diferenças e metadados de versão. A explicação operacional pode ser complementada por um changelog.
O changelog pode ser um arquivo Markdown que aponta mudanças relevantes: data, fato, fonte, estado anterior, estado atual, responsável e próximo passo verificável. Ele ajuda na navegação, mas não substitui a fonte canônica nem o histórico de versão.
O formato é simples, mas sua utilidade depende de manutenção consistente e ligação com a fonte correta.
Um agente só consulta o changelog se o procedimento mandar e se o arquivo estiver acessível. A entrada pode indicar onde procurar, mas a confirmação do estado continua na nota, no arquivo ou no sistema que governa aquela frente.
Sem uma superfície de estado, o agente pode gastar tempo localizando mudanças ou usar um registro antigo. Com um changelog bem mantido, ele encontra as frentes recentes e segue para as fontes corretas.
O changelog é parte do contrato entre agentes. A coordenação ainda depende de instruções, permissões, isolamento de tarefas, revisão e atualização consistente dos registros.
Instruções longas e custo de manutenção
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.
O agente pode receber um arquivo de instruções, equivalente ao manual de operação da frente. No sistema do estúdio, o arquivo global define regras universais, como terminologia, permissões, protocolo de entrega e localização das fontes.
O problema aparece quando esses arquivos crescem sem arquitetura. Cada nova regra e exceção é acrescentada ao mesmo lugar, mesmo quando vale apenas para uma frente.
Instruções longas, redundantes ou contraditórias podem dificultar a recuperação da regra relevante. O problema combina volume, mistura de escopos, conflito e ausência de prioridade.
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 frente e contexto. Terminologia básica, permissões, protocolo de entrega e localização das fontes.
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, a separação entre regras globais e regras de cada frente facilitou manutenção e revisão. Esse resultado é operacional, não uma promessa de economia fixa de tokens ou melhora automática de qualidade.
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, nomenclatura ou fluxo em determinada data. O histórico deve permanecer recuperável, mas o recorte da tarefa recebe apenas o que governa a execução atual.
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 a frente está ativa, a instrução entra na fonte própria. Se a frente terminou, preserve o histórico e retire a regra do escopo ativo depois da revisão.
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 adequado quando contém apenas regras universais, não repete instruções e permite localizar rapidamente permissões, fontes e definição de pronto. O teste real é executar uma tarefa concluída, observar falhas e recolocar cada regra necessária no escopo correto.
O primeiro teste pode revelar regras mal posicionadas ou repetidas. Corrija o endereço de cada uma, global ou por frente, e repita a tarefa conhecida antes de ampliar o sistema.
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 autorizados para a nuvem, considere o agente editorial. Se envolve processamento de arquivos, automação local ou operações de sistema, considere o agente de automação. Se atravessa terminal, arquivos, aplicativos, navegador, integrações e versionamento no mesmo fluxo, considere o agente operador. Se o dado não pode sair do computador, só use uma camada local depois de validar ambiente, permissões e política aplicável.
Essa escolha também tem uma dimensão de custo e continuidade. Nem toda tarefa precisa do modelo mais caro ou do agente com mais acessos. Uma classificação simples pode usar uma camada leve. Uma entrega pública pede revisão editorial mais rigorosa. Uma auditoria de arquivos pode pedir um agente operador. A competência real não é decorar nomes de ferramentas. É rotear a tarefa para o menor agente que resolve sem aumentar risco, retrabalho ou custo cognitivo.
Se a decisão está muito confortável, peça segunda opinião. Mas peça com pergunta clara. “Revise isso” é vago demais. “Este argumento está fraco?”, “este texto expõe demais?”, “isso parece hype de ferramenta?” são perguntas melhores.
Na dúvida, classifique o dado e delimite a tarefa antes de escolher a ferramenta. Se o uso em nuvem não estiver autorizado, não envie o material. Um ambiente local só entra depois de validar configuração, permissões e rastros de saída.
Capacidade na fase de construção
Existe uma diferença importante entre usar um sistema pronto e construir o sistema.
Na fase inicial do Segundo Cérebro, você pode abrir muitos arquivos, converter documentos, definir nomes, criar índices, escrever instruções, testar agentes e corrigir a arquitetura. Essa fase pode consumir mais capacidade do que uma rotina já estabilizada.
Limites de uso, custo, tamanho de arquivos e disponibilidade dos serviços são restrições de implantação. Registre esses limites no piloto e defina como retomar uma tarefa interrompida. Uma assinatura maior não corrige arquitetura ruim. A capacidade necessária só pode ser estimada depois de observar o fluxo real.
Redundância entre provedores
Redundância não exige duas assinaturas desde o início. Ela exige fontes exportáveis, formatos recuperáveis, backup independente e um procedimento de continuidade testado. Um segundo provedor pode fazer parte desse plano, mas só é útil se encontrar a fonte de verdade, as instruções, o estado da tarefa, os arquivos permitidos e a definição de pronto.
Quando a decisão pede contraponto
Quando uma decisão pede perspectivas diferentes, você pode montar um conselho de agentes.
Esse conselho não funciona como votação.
Um agente produz a primeira proposta. Outro faz contraponto e procura premissas frágeis, riscos ou consequências ignoradas. Um terceiro verifica fontes, execução ou impacto operacional.
A decisão continua humana.
Use o conselho quando a escolha muda posicionamento público, envolve risco relevante, define uma arquitetura difícil de desfazer ou parece confortável demais na primeira leitura.
Não use três agentes para renomear um arquivo ou repetir uma rotina já validada. Isso só multiplica consumo e ruído.
O fluxo pode ser resumido assim:
- Defina a tarefa real.
- Escolha o agente mais adequado.
- Pergunte se a decisão pede contraponto.
- Se pedir, acione o conselho com papéis diferentes.
- Registre a decisão humana e o motivo.
- Execute.
- Deixe rastro no sistema.
O percurso pode ser desenhado como uma sequência simples: pergunta delimitada, pareceres independentes, comparação das divergências, decisão do responsável e registro do que foi aceito ou recusado.
Continuidade pelo celular
Algumas ferramentas permitem acompanhar tarefas por mais de uma interface. Essa disponibilidade muda conforme produto, plano e configuração.
O celular é interface de continuidade, não ambiente para qualquer aprovação.
Uma checagem de status, um registro de ideia ou uma autorização já delimitada podem acontecer ali. Mudanças sensíveis, publicação, revisão de arquivos e decisões com impacto externo devem voltar para o ambiente adequado.
O ganho está em consultar estado e responder uma dúvida delimitada sem confundir mobilidade com autorização ampla.
Uma Skill externa não recebe autoridade junto com o download
Componentes prontos de terceiros, Skills, agentes publicados e configurações compartilhadas resolvem parte do trabalho. Eles também chegam com decisões embutidas que ninguém no seu repositório revisou.
Baixar não concede autoridade para agir. Uma Skill pode trazer uma ideia útil, e a execução só entra no sistema depois de leitura crítica, adaptação às suas regras internas e descarte do que for arriscado.
Trate um componente externo como trata uma fonte: origem conhecida, permissão delimitada, saída verificável e uma pessoa responsável por ele. Um agente que você não leu é um colaborador que você não entrevistou.
O Exercício Deste Módulo
Antes de instalar uma ferramenta nova, escolha uma tarefa já concluída e monte um fluxo coordenado em modo de teste.
- Dê ao primeiro agente a tarefa de localizar as fontes e preparar uma proposta com limites.
- Dê ao segundo agente a função de procurar premissas frágeis, omissões, conflitos e riscos.
- Dê ao terceiro agente uma cópia preservada para executar apenas a parte reversível e registrar o resultado.
- Compare as saídas com o resultado que você já conhece.
- Registre onde a coordenação ajudou e onde apenas produziu ruído.
A decisão continua com uma pessoa responsável. Defina uma janela de revisão proporcional à frequência da tarefa para verificar uso, travas e instruções que precisam mudar.
Se você ainda não usa versionamento, teste primeiro uma estratégia numa pasta descartável. Git é uma opção. Outra rotina de versões pode servir para um fluxo simples, desde que permita comparar, recuperar e identificar a versão correta.
Crie um registro de teste fora do acervo canônico. Anote data, tarefa, fonte, estado anterior, estado atual, responsável, próxima ação e condição de parada.
O output verificável do módulo é um registro que liga cada papel à sua fonte, permissão, saída, revisor e estado. O sinal observado é a redução de conflito, duplicação ou perda de contexto numa tarefa delimitada. Um teste não prova que mais agentes melhoram qualquer operação.
Se Git não fizer sentido agora, use versões nomeadas, backup e um registro central. Não aplique o teste diretamente ao único exemplar de um arquivo importante.
Considerações Finais
Coordenar agentes pode ampliar uma operação quando os papéis são realmente distintos. Repositório e changelog ajudam, mas nenhum agente conhece automaticamente tudo que os outros fizeram. O estado só é confiável quando cada etapa registra evidência na fonte correta e uma pessoa revisa a consequência.
No Módulo 7, vamos consolidar resultados, rotina de manutenção e melhoria contínua. O Segundo Cérebro organiza fontes. O agente com dossiês delimita contexto. O pipeline organiza transformação e revisão. A coordenação deste módulo adiciona papéis, versionamento e registro, sem prometer privacidade por escolha de ferramenta.
Se quiser aprofundar processamento local, classificação de dados e recuperação de conhecimento, os Módulos 8 a 12 formam a Fase 2 da trilha. Se quiser aprender essa lógica em conversa individual, conheça a Mentoria em IA para Negócios. No formato atual, são quatro sessões online de duas horas. A Mentoria discute possibilidades e casos de uso, sem prometer implementação ou execução.
A gente se vê no Módulo 7.
Perguntas Frequentes
Git é obrigatório? Não. O requisito é ter uma estratégia proporcional de versionamento, recuperação, isolamento e registro. Git é uma opção forte para arquivos textuais, mas precisa ser configurado e operado de modo consciente.
Preciso aprender linha de comando para coordenar agentes? Não. Você pode aprender a lógica de papéis e passagens de tarefa sem linha de comando. Ferramentas de terminal entram apenas quando a tarefa, o ambiente e sua capacidade de revisão justificarem.
E se eu não precisar de três agentes? Use o menor número de agentes que crie papéis realmente distintos. Volume, risco, frequência, acesso a ferramentas e custo de coordenação importam mais do que uma quantidade fixa de clientes ou entregas.
O sistema funciona no Windows? Os conceitos de fonte, papel, permissão, revisão, versionamento e registro independem do sistema operacional. Ferramentas, comandos e disponibilidade mudam. Confirme os requisitos atuais antes de implantar.
Glossário deste módulo
Os termos que este módulo coloca em uso. Definições completas no glossário da trilha.
Termos centrais deste módulo
- Handoff entre Agentes : o protocolo que impede um agente de desfazer o trabalho do outro.
Termos de apoio (definidos em outros módulos, usados aqui)
- Segundo Cérebro : o repositório comum onde o estado do trabalho fica registrado, Módulo 2.
- Fonte da Verdade : a regra que mantém os agentes alinhados, Módulo 2.
- Revisão de Diff : a aprovação humana que sustenta a coordenação, Módulo 12.5.