Rascunho Compartilhado

Como reconhecer

Uma migração de código usa três agentes: um refatora, um escreve testes e um revisa. Os três escrevem e leem o mesmo histórico de conversa (anonimizado):

[refatorador] Vou extrair a lógica de desconto para uma função pura,
              usando um dicionário de regras em vez de ifs aninhados...
[refatorador] Pronto. Agora apply_discount recebe rules: dict.
[testador]    Vou escrever os testes. Seguindo a mesma abordagem,
              vou extrair as fixtures para um dicionário de regras...
[revisor]     O testador mudou a estrutura das fixtures sem necessidade.
[refatorador] Concordo com o revisor, vou ajustar também os testes...

O testador passou a imitar as decisões de estilo do refatorador. O refatorador começou a mexer nos testes porque leu a crítica do revisor sobre eles. Ninguém sabe mais qual agente é responsável por qual arquivo.

O mesmo aparece quando o time cria um memory.md ou um canal em que todo agente anexa parágrafos. Cada um relê o raciocínio dos outros e trata esse texto como instrução. A “colaboração” vira contaminação.

Sinais de Rascunho Compartilhado:

• Vários agentes leem e escrevem no mesmo histórico ou arquivo de anotações, em texto livre.
• O raciocínio de um agente influencia o estilo ou as decisões de outro.
• Agentes passam a fazer o trabalho uns dos outros.
• O contexto compartilhado cresce rápido, com mensagens de todos.
• Não há formato nem dono para o que cada um escreve.

flowchart TD
  A(["1. Agente A"]):::llm --> S[("2. Histórico compartilhado em texto livre")]:::store
  B(["1. Agente B"]):::llm --> S
  C(["1. Agente C"]):::llm --> S
  S --> A
  S --> B
  S --> C

1. Cada agente tem uma função diferente.
2. Todos escrevem e leem o mesmo texto, sem formato e sem dono.
3. O raciocínio de um vira instrução implícita para os outros, e as funções se misturam.

Checagem +20 XP de primeiraNo trace da migração, o testador decide 'extrair as fixtures para um dicionário de regras' logo depois de ler o raciocínio do refatorador. Qual é o mecanismo?

O prompt do testador está fraco; um few-shot de testes independentes resolveria

O raciocínio em texto livre no histórico compartilhado virou instrução implícita para o testador

Falta um quarto agente, o Arquiteto, para decidir o estilo antes dos outros falarem

Por que acontece

• É o padrão de vários frameworks. Agentes num “grupo de conversa” compartilham o histórico por default. Você sobe três papéis, o framework entrega um chat único, e parece que a equipe nasceu pronta.
• Parece colaboração. Ver o trabalho dos outros parece útil, como numa equipe humana. Em time humano, a pessoa escolhe o que ler. O modelo lê tudo o que está no contexto e dá peso a tudo.
• Não há contrato entre agentes. Sem formato definido, texto livre é o único meio. O refatorador “conta” o que fez em prosa; o testador “entende”. Isso é o smell vizinho Passagem em Texto Livre no meio de um grupo.
• Um arquivo só parece simples. scratchpad.md que todo mundo appenda evita desenhar uma API. Em uma tarde funciona. Em uma semana o arquivo tem o raciocínio de todo mundo e ninguém consegue resumir quem decidiu o quê.

Quanto custa ignorar

• Funções contaminadas. Agentes imitam ou corrigem uns aos outros fora do seu escopo. O revisor deixa de achar bug porque comprou a justificativa de quem escreveu.
• Contexto inchado. Cada agente lê tudo de todos, e o custo cresce com o produto (agentes × mensagens), não com o trabalho de cada um.
• Revisão sem independência. O revisor leu o raciocínio de quem fez e tende a concordar. Em code review humano, você às vezes esconde a intenção de propósito para o revisor julgar o diff. Aqui o diff chega com um ensaio defendendo cada linha.
• Responsabilidade difusa. Quando algo dá errado, não dá para saber de quem foi a decisão. Os três traces contam a mesma história misturada.

Uma conta para o histórico único

Os números abaixo são ilustrativos. Suponha três agentes, cada um escreve cerca de 800 tokens por turno, e a tarefa tem quatro turnos.

Desenho	O que cada agente lê por turno	Tokens de leitura no total (aprox.)
Histórico compartilhado	Tudo o que os três já escreveram	cresce 800 × 3 a cada turno, pago três vezes
Contextos isolados, passagem estruturada	Só a instrução e um registro (files, diff_stat)	quase constante por agente

No rascunho compartilhado, o terceiro turno já manda dezenas de milhares de tokens para cada um. No isolado, o testador recebe apply_discount(rules: dict) e a lista de arquivos, uns poucos tokens, e trabalha no contexto dele.

Tratamento

Refatoração	Escolha quando
Extrair Subagente	Cada função precisa do seu próprio contexto. Os agentes passam a receber só a instrução e o material de que precisam. Destinos: Delegação a Subagentes e Isolamento de Contexto.
Trocar Texto Livre por Saída Estruturada	Os agentes precisam mesmo compartilhar informação. Troque o texto livre por registros com dono e formato. Destino: Saída Estruturada.

Na migração, o refatorador devolve algo como schema Change { files: list[string], summary: string, public_api: string }. O testador recebe só isso, num contexto vazio de raciocínio alheio, e escreve testes. O revisor recebe o diff e a rubrica, sem o ensaio do refatorador. O orquestrador é quem lê os três registros e decide o próximo passo.

Não confunda com Multi-Agente Decorativo. Lá os agentes nem deveriam existir separados. Aqui a separação pode ser certa, e o que está errado é o meio: um bloco de prosa que todos editam.

Checagem +20 XP de primeiraVocê precisa que o refatorador avise o testador o que mudou. Qual desenho evita o Rascunho Compartilhado sem esconder o fato útil?

Deixar os dois no mesmo chat, mas pedir no prompt 'não imitem o estilo um do outro'

Gravar um memory.md que só o orquestrador resume de vez em quando

O refatorador devolve um registro com arquivos, resumo e API pública; o testador recebe só esse registro no contexto dele

O que você ganha

• Cada agente faz o seu trabalho, com o seu contexto.
• Informação compartilhada em formato definido, com dono.
• Revisão independente de verdade.
• Custo que não cresce com o quadrado do número de agentes.

Quando ignorar

• Debate com juiz e critério. Quando o objetivo é os agentes lerem o argumento uns dos outros, o compartilhamento é o ponto. Mesmo ali, o juiz decide por critério escrito, e o raciocínio de quem gerou a resposta não entra no julgamento se você quer independência.
• Dois agentes com uma interface pequena. Uma troca curta de mensagens entre dois agentes pode funcionar sem estrutura. Se a terceira mensagem já mistura funções, estruture.
• Um humano no meio. Se uma pessoa lê o rascunho e cola no próximo agente só o trecho que importa, o humano é o filtro. Isso não escala, e funciona em protótipo.

É esse smell?

Checagem +20 XP de primeiraTrês subagentes pesquisam em paralelo e escrevem afirmações num quadro com campos nomeados: afirmação, fonte, autor. O orquestrador lê o quadro. Os subagentes não leem o quadro uns dos outros. É Rascunho Compartilhado?

Sim, há um quadro compartilhado

Não

Sim, porque o orquestrador mistura as afirmações num texto só

Checagem +20 XP de primeiraUm revisor recebe o código produzido e também todo o histórico de raciocínio de quem o escreveu. Ele aprova quase tudo. Qual é o problema?

Falta independência: o revisor está sendo convencido pelo ensaio de quem fez

O revisor é um modelo fraco e precisa ser trocado

Falta um segundo revisor para revisar o primeiro

Checagem +20 XP de primeiraCinco agentes com cargos passam o mesmo texto adiante, cada um reescrevendo um pouco, sem ferramentas. Qual smell é o principal?

Rascunho Compartilhado

Multi-Agente Decorativo

Passagem em Texto Livre, e o quadro estruturado resolve os cinco

Checagem +20 XP de primeiraDois agentes: A devolve Change com arquivos e resumo, B recebe só esse objeto e escreve testes no contexto dele. Não há chat compartilhado. É Rascunho Compartilhado?

Sim, eles compartilham informação

Sim, porque B depende do que A produziu

Não