Quem faz e quem confere: o exercício mais simples para começar
Um exercício de quatro passos para ver um ciclo de execução e conferência funcionar com duas sessões nomeadas que trocam mensagens. A lição central: quem confere, e como, decide o resultado.

Uma desenvolvedora júnior recebeu a tarefa de "montar uma rotina de conferência" para a página de lançamento de um produto. Leu sobre assistentes especializados, orquestradores, pastas de configuração, automações. Entendeu a lógica, mas não sabia por onde pegar. O que ela precisava não era mais teoria. Era um exercício de quinze minutos em que pudesse ver o ciclo acontecer na frente dela, com o que já sabia usar.
Esta peça é esse exercício. Ferramentas de desenvolvimento assistido por inteligência artificial passaram a permitir que sessões independentes se nomeiem e troquem mensagens entre si. Com esse recurso, o ciclo em que um assistente executa e outro confere, descrito em Conferir antes de entregar, deixa de ser uma arquitetura invisível e vira algo que se observa em duas janelas lado a lado. É a porta de entrada mais didática que conhecemos.
O recurso em uma frase
Cada sessão pode receber um nome. Uma sessão pode enviar uma mensagem para outra pelo nome, e a sessão que recebe começa a trabalhar sem que ninguém digite nada nela. A documentação oficial da Claude descreve isso como troca de mensagens entre sessões, e o mesmo mecanismo permite que um assistente retome ou instrua outro.
Só isso. Não é uma capacidade nova de raciocínio, é uma forma de ligar duas conversas. O valor está no que se constrói com a ligação.
O exercício, em quatro passos
Passo 1. Duas sessões, dois nomes. Abra duas sessões na mesma pasta, de preferência lado a lado. Nomeie a primeira de executor e a segunda de supervisor. Liste as sessões ativas para confirmar que uma enxerga a outra.
Passo 2. Divisão de trabalho. Peça ao executor um primeiro rascunho de uma página simples de apresentação para um produto inventado. Peça ao supervisor que pesquise referências de layout de páginas do mesmo tipo. As duas trabalham ao mesmo tempo, cada uma no seu contexto.
Passo 3. Primeira troca. Quando a pesquisa terminar, peça ao supervisor que envie as referências ao executor para melhorar a página. Observe: o executor começa a trabalhar sozinho. Nada foi digitado nele. É a primeira vez que se vê o mecanismo funcionar.
Passo 4. O ciclo. Agora dê papéis. Diga ao supervisor que ele é responsável por manter as páginas em padrão comercial, e que deve ser exigente. Diga ao executor que crie um ciclo: enviar cada versão ao supervisor, que dá nota de zero a cem; abaixo de noventa e cinco, o supervisor sugere mudanças e o executor aplica, gerando nova versão. Comece.
O que acontece a seguir é o ciclo inteiro visível: o supervisor lê, pontua, devolve, o executor corrige, envia de novo. Ninguém intervém.
O que o exercício ensina, e ninguém conta antes
Na primeira rodada, o supervisor tende a aprovar. Ele lê o código, vê que está tudo ali, funcionando, e dá nota alta a uma página que qualquer pessoa reconheceria como genérica. Isso não é defeito do exercício. É a lição principal dele.
O supervisor aprovou porque a conferência foi feita por leitura, não por uso. Ele leu o código. Não viu a página. E leitura de código aprova o que parece certo, não o que funciona bem.
A correção cabe em duas instruções ao supervisor. Primeira: sempre capture a tela da página e avalie a imagem, não apenas o código. Segunda: só aprove o que considerar impressionante para o padrão do mercado. Ao rodar o ciclo de novo com essa mudança, a mesma página que tinha sido aprovada recebe uma nota baixa, e o executor passa por rodadas de melhoria até cruzar o limiar. Nos testes em que observamos esse comportamento, a diferença entre a primeira conferência e a segunda não foi de alguns pontos. Foi de aprovado para reprovado com folga.
A mudança de qualidade do resultado final não veio de uma ferramenta melhor, nem de um pedido melhor. Veio de trocar a metodologia de conferência. É o mesmo princípio que orienta os testes de aceitação de qualquer projeto: quem valida precisa experimentar o entregável como o usuário final, não conferir a especificação. A documentação da Claude traz o exemplo de um assistente com acesso a automação de navegador exatamente para isso: navegar, capturar tela e interagir com a página.
Modelo caro onde importa
Um detalhe do arranjo economiza dinheiro. O executor pode rodar em um modelo econômico e rápido, porque a tarefa dele é produzir versões. O supervisor merece o modelo mais capaz disponível, porque a tarefa dele é julgar, e um julgamento fraco desperdiça todas as rodadas seguintes. O custo total fica menor do que rodar tudo no modelo premium, e o resultado fica melhor do que rodar tudo no econômico.
É a lógica de escolher o modelo por tarefa, com o gasto concentrado onde a criticidade está, aplicada a um par de sessões ("Inteligência" [1]).
Três usos além do exercício
Passagem de bastão. Quando uma sessão está prestes a esgotar a memória de trabalho, transfira o essencial para outra sessão nomeada e continue de lá. O trabalho não recomeça do zero.
Pesquisa e execução separadas. Uma sessão levanta referências, dados ou requisitos. Outra constrói. A primeira nunca se mistura com o código, a segunda nunca se enche de resultados de pesquisa.
Supervisor permanente. Uma sessão nomeada como supervisor, com critérios escritos, que qualquer outra sessão consulta antes de considerar algo pronto. É a versão artesanal do conferente dedicado descrito em A rotina de conferência que roda toda vez.
Quando sair do exercício
Duas sessões que conversam são o ciclo com as luzes acesas: tudo visível, tudo controlável, tudo interrompível. Para aprender, é o formato ideal. Para operar, é limitado. Quem já domina a lógica tende a migrar para ciclos embutidos na estrutura do projeto, que rodam a cada execução sem depender de instruções digitadas na hora. A conveniência visual diminui, a repetibilidade aumenta. A construção desse arranjo permanente é o tema de A rotina de conferência que roda toda vez, a escalada para dezenas de pares em paralelo é o tema de Muitas entregas ao mesmo tempo, e o conjunto completo de capacidades que uma equipe mantém por meses está em Do diagnóstico ao sistema que a equipe mantém.
Para quem chega de um diagnóstico, este exercício é o primeiro dia da primeira entrega rápida, aquela que prova o conceito em semanas com o que já existe ("Plano de Ação Inicial" [2]). A ficha da iniciativa fornece a meta e os critérios; o exercício mostra como um par de sessões os aplica.
O entregável
O que esta peça deixa: um exercício de quatro passos para ver um ciclo de conferência funcionar, a lição sobre conferência por uso versus por leitura, a regra de alocação de modelos e três usos práticos do recurso. É o mínimo que um desenvolvedor iniciante, ou um gestor curioso, precisa para entender na prática o que os artigos conceituais desta série descrevem.
Na série
Esta é a peça 3 da série Da decisão à entrega, em sete peças. O artigo estruturante, Do diagnóstico à entrega, é a porta de entrada. As peças anteriores são A estrutura vale mais do que a ferramenta e Conferir antes de entregar, e a sequência segue com A rotina de conferência que roda toda vez, Muitas entregas ao mesmo tempo, O critério de sucesso vale mais do que o pedido e Do diagnóstico ao sistema que a equipe mantém.
Termos citados neste artigo
[1] "Inteligência": camada técnica do Impulso Framework que escolhe o modelo certo para cada tarefa, com estratégia híbrida de custo: a maior parte do volume em modelos econômicos, os casos críticos em modelos capazes. Detalhada em Inteligência: o modelo certo para cada tarefa.
[2] "Plano de Ação Inicial": roteiro em três fases (Quick Win, Estruturação e Escala) que encerra o diagnóstico. A primeira fase prova o conceito em semanas com o que já existe. Detalhado em Resultado: o relatório executivo que produz segunda-feira.
Referências
Documentação oficial da Claude (Anthropic), consultada em setembro de 2026:
Cross-session messaging, sobre sessões nomeadas que trocam mensagens. https://code.claude.com/docs/en/cross-session-messaging
Create custom subagents, sobre conferência com automação de navegador e escolha de modelo por assistente. https://code.claude.com/docs/en/sub-agents
Develop test cases, sobre avaliação por modelo com rubrica e escala. https://platform.claude.com/docs/en/test-and-evaluate/develop-tests
Comece com duas janelas abertas. O resto da arquitetura é esse mesmo ciclo, com mais peças e menos luz.
Tool | Frente: Consulting | Série Da decisão à entrega, peça 3 de 7 | Proposições ancoradas: IA como amplificador, jornada progressiva | 1.260 palavras | Leitura: 7 minutos
✦ Próximo passo
Sua organização está pronta para isso?
Faça o diagnóstico Impulso e descubra em qual dimensão está o maior gargalo — e por onde começar.
Começar diagnóstico gratuitoArtigos relacionados
A rotina de conferência que roda toda vez
Guia prático para estruturar uma rotina em que um assistente executa e outro confere, a cada execução: seis componentes, um modelo de critérios de aceitação em três blocos e o mapa de aplicação em desenvolvimento, testes, documentação, dados e avaliações.
Torre de controle de IA: governar o que já entrou na operação
Uma operação de alto volume descobre que não sabe quanta inteligência artificial já tem rodando, incluindo a que entrou embutida em ferramentas contratadas. O caminho não começa por comprar plataforma, começa por enxergar o que existe e separar controle de construção de controle de execução.
Estratégia de IA: governar é decidir o que entra, o que fica e o que sai
Governança de IA costuma ser só uma porta de entrada. Ciclo de vida tem quatro: entrada, operação, revisão e saída, e a última é a que ninguém constrói. A ISO 42001 dá a estrutura, o Radar do Impulso dá o instrumento, e a proporcionalidade evita fabricar IA paralela.