O relatório existe. A sala, não.

Recentemente, um agente de IA registrou seis itens em nosso próprio quadro retro.

A primeira dizia: “Comece verificando antes de agir — erros de execução de agentes representam 38% do atrito (o dobro da segunda causa mais comum); o custo recorrente está em atribuir uma causa, fazer o push ou redirecionar antes de verificar o código em produção, os dados ou o estado do branch.” Por trás disso, havia as evidências do padrão: erros de git/estado-do-ramo durante o trabalho com agentes simultâneos em oito sessões e dois repositórios; verificações parciais pré-push que interromperam a CI em quatro sessões, duas vezes em um repositório no mesmo dia; uma lacuna na simulação de testes que uma sessão havia sinalizado no dia anterior, com a observação de que o documento de correção nunca foi escrito.

Há duas coisas nesse quadro que merecem atenção. Primeiro, nenhuma sessão de trabalho isolada teria classificado nada disso como seu principal problema: cada caso era um encolher de ombros, alguns minutos perdidos, um incômodo que alguém contornava. A classificação só existe de forma agregada, entre sessões e pessoas. Segundo, e mais incômodo: os itens mais graves não diziam respeito ao agente nem ao código. Eles diziam respeito a nós — correções que havíamos concordado em implementar, mas não adotamos, o mesmo impasse se repetindo com “nenhuma correção permanente lançada entre elas”.

Um relatório automatizado pode fornecer todas essas informações. O que ele não consegue fazer é reunir as pessoas responsáveis pelo processo, pela documentação, pelo orçamento para ferramentas e pelas prioridades para que se sentem e decidam o que fazer a respeito. O relatório existe. A reunião, não. Este artigo trata dessa reunião.

Todos construíram o circuito

Em meados de 2026, “identificar o que deu errado no trabalho assistido por IA e usar isso como feedback” já é uma prática consensual. Ela existe sob pelo menos seis nomes diferentes, e todos são válidos. O Feedback Flywheel de Rahul Garg aproveita os atritos das sessões para criar documentos de orientação e diretrizes. A Compound Engineering da Every faz com que cada unidade de trabalho ensine a seguinte. A Thoughtworks equipa seus agentes com sensores; Addy Osmani chama essa disciplina de Loop Engineering. Os fornecedores de plataformas fecham o ciclo em escala de frota: a memória “sonhadora” da OpenAI, a curadoria de contexto da Anthropic e o Factory Signals com o preenchimento automático de tickets. O gh-aw de código aberto do GitHub, uma estrutura para fluxos de trabalho autônomos escrita em markdown de linguagem natural, é o que mais se aproxima do nosso tema: seus fluxos de trabalho de insights de sessão já geram relatórios automatizados de análise de sessão. Um exemplo público, a análise automatizada de 50 sessões em um único dia, sinaliza uma taxa de omissão de 24% e uma taxa de sucesso do executor de 33% como “Sinais de Falha”.

Se você usa algum desses: continue usando-os. Este artigo não propõe a substituição de nenhum deles. Mas classifique os loops de acordo com o nível em que são executados e observe o padrão:

Um manual do profissional. Uma configuração de sessão. Uma memória de plataforma. Uma pilha de observabilidade. Uma frota de um fornecedor.

Quase todo ciclo no campo é um ciclo individual: uma pessoa e seu agente, ou um fornecedor e sua frota. O “flywheel” de Garg é o único modelo que busca artefatos compartilhados pela equipe, e sua lista de cadência inclui um item que quase ninguém colocou em prática: “Na retrospectiva: um item da pauta na retrospectiva de sprint atual: o que funcionou com IA neste sprint?” Ele cita o local e segue em frente. O “dogfooding” do GitHub, por sua vez, produz exatamente o relatório de atritos que uma cerimônia de equipe gostaria de ter como insumo, e o posiciona como observabilidade de engenharia, ponto final.

O que mais se aproxima de uma exceção vem do Scrum.org, cuja série sobre equipes híbridas inclui Como conduzir a retrospectiva de sprint quando metade da sua equipe é composta por agentes de IA. Vale a pena ler, pois o artigo leva a sério a questão do local e a aborda de maneira diferente da nossa: a retrospectiva deles se torna uma sessão de depuração baseada em dados sobre as métricas dos agentes (frequência de reescrita de prompts, taxas de desvio, consumo de tokens). Essa é uma perspectiva útil, e uma equipe poderia realizar ambas. Mas ela analisa os agentes; o ciclo abordado neste artigo analisa a colaboração: causas em vez de sintomas, correções direcionadas para o nível a que pertencem (o briefing, a documentação, o processo, o material), com os agentes contribuindo com seu próprio relato do trabalho, em vez de aparecerem como um painel de controle.

A lacuna não está na tecnologia. Todas as etapas (captura, agregação, geração de relatórios) já estão disponíveis hoje. A lacuna está na prática: quase ninguém explicou o que a equipe faz, em conjunto, quando o relatório é gerado.

O que realmente precisa de um cômodo

O instinto aqui é automatizar ainda mais: melhor agrupamento, correções aplicadas automaticamente, um painel de controle. Para uma grande parte das constatações, isso está correto, e os fluxos de trabalho acima fazem isso bem. Mas liste as decisões que o relatório realmente levanta e observe sua estrutura:

• Manter ou eliminar. Qual atrito recorrente é um desperdício e qual é um controle deliberado? A etapa de revisão que retarda o agente pode ser a “coleira” que alguém escolheu (uma recapitulação da palestra de Armin Ronacher na AIE Europe: “o atrito é o que é necessário… para orientar”); O Radar da Thoughtworks agora alerta sobre a dívida cognitiva de remover elementos em excesso. Excluir um ponto de controle altera o risco de todos. Essa é, por definição, uma decisão da equipe.
• Onde a solução se concretiza. Um padrão recorrente de atrito é resolvido em algum nível: uma anotação pessoal, um prompt ou uma habilidade, a configuração do ambiente, a documentação, o próprio material de trabalho, o processo ou na origem, junto a um fornecedor. Esses artefatos têm responsáveis, e os responsáveis são pessoas diferentes.
• Prioridade na agregação. Cinco minutos ignorados por pessoa por sessão passam despercebidos para cada indivíduo, mas representam um custo significativo para a equipe como um todo. Tomar medidas a respeito (reescrever o modelo compartilhado, alterar o processo de admissão, encaminhar o caso ao fornecedor) exige um nível de decisão que nenhum indivíduo possui.
• A verificação de adoção. A correção do ciclo anterior foi realmente adotada, e o atrito cessou? A frase mais valiosa do nosso próprio quadro foi exatamente esta: sinalizado ontem, nunca implementado. Um ciclo sem essa verificação é como um volante girando no ar.

Nenhuma dessas etapas é um cálculo. Todas são negociações entre pessoas responsáveis por diferentes aspectos do funcionamento da equipe. Profissionais que atuam sozinhos incorporam legitimamente essas decisões com base na intuição; os pipelines de fleet geram legitimamente o subconjunto legível por máquina na velocidade da máquina. As versões em escala de equipe exigem que as pessoas estejam reunidas em uma sala, com um vocabulário comum e autoridade para redirecionar a atenção. Isso não é um pipeline. É uma cerimônia.

Por que o estilo retrô — ou uma cerimônia com formato semelhante

Para ser totalmente transparente antes de iniciar a discussão: nós vendemos software retrospectivo. É exatamente por isso que esta seção se baseia nas propriedades, e não na marca: avalie nossa conclusão com essa ressalva e verifique você mesmo essas propriedades.

As propriedades que o conjunto de decisões precisa ter: um espaço que seja recorrente (atritos menores e contínuos nunca desencadeiam uma reunião pontual), isento de culpa por norma, que envolva todos os responsáveis (as pessoas responsáveis pelo processo, pela documentação, pelas ferramentas e pelas prioridades estejam presentes) e baseado em evidências. Para a maioria das equipes, a retrospectiva de sprint é onde essas quatro características já estão presentes: não há uma nova reunião para defender em uma disputa de agenda, e uma convenção de isenção de culpa que é mais importante do que parece, pois o modo de falha tentador aqui é a análise pós-falha com culpa atribuída ao agente, e a escola de engenharia de harness rejeita explicitamente esse padrão: o engenheiro culpa o modelo e arquiva o caso como “aguardar a próxima versão”; em vez disso, corrija o harness (Osmani, Agent Harness Engineering).

Mas a versão honesta dessa afirmação avalia os rivais, em vez de declarar um vencedor:

• O planejamento do sprint é o que tem mais peso na reunião, mas sua pauta é voltada para o futuro e está sempre lotada; a triagem retrospectiva, quando incluída no horário de planejamento, acaba inevitavelmente sendo preterida. O planejamento é onde as ações aprovadas são agendadas, não onde se analisam padrões.
• A análise pós-incidente “sem culpa” tem exatamente as normas certas, mas o gatilho errado: ela é convocada para grandes falhas pontuais, nunca para o padrão de “cinco minutos com oito pessoas a cada sprint”, que é justamente o padrão que só a agregação consegue identificar.
• Assíncrono — um relatório e um rastreador é a opção mais econômica e, para a grande maioria das tarefas rotineiras, é suficiente. O que ela não consegue fazer é lidar com as decisões: a escolha entre manter ou descartar é uma negociação, as divergências de prioridade ultrapassam os limites de responsabilidade e a redefinição de prioridades exige que os responsáveis estejam na mesma conversa.
• A alternativa nula — simplesmente falar sobre IA no modo retro, sem registros, sem rótulos é gratuita, se encaixa na realidade atual e, para uma equipe pequena com uso moderado do agente, pode realmente ser suficiente. Comece por aí. O que ela não consegue oferecer é comparabilidade entre sessões, tendências ou a verificação da adoção: uma conversa que começa do zero todas as vezes. A prática descrita a seguir é o que você adiciona quando essa conversa fica se repetindo.

Portanto, a afirmação, com toda a franqueza: o retro — ou sua cerimônia atual de formato equivalente. A revisão mensal da campanha por uma equipe de mídia e a revisão de triagem por uma equipe de suporte são a mesma cerimônia com nomes diferentes, e nada nessa prática pressupõe código: o registro de atritos de uma conta de anúncios emaranhada ou de uma biblioteca de modelos inconsistente se parece exatamente com o registro de atritos de um repositório legado.

O agente na sala — participante, nunca facilitador

Se as evidências vierem de agentes, o agente deveria analisar o item? Não, e não principalmente pelo motivo que você imagina.

A razão por trás disso: os modelos atuais não são confiáveis exatamente nesse tipo de avaliação: os veredictos dos LLMs variam com entradas idênticas ~13,6% das vezes, e em um estudo de produção de oito semanas ~70% das falhas silenciosas dos agentes foram detectadas inicialmente por uma pessoa, e não por testes ou monitoramento. Isso é verdade hoje; os modelos estão melhorando.

A razão pela qual isso não se desvanece: a facilitação e a tomada de decisões alocam a atenção da equipe e alteram os artefatos pelos quais a equipe é responsável e responde. Essa autoridade não se transfere para o modelo mais competente na sala, assim como não se transfere para o engenheiro mais competente na sala. Trata-se de um fato organizacional, não de uma lacuna de competência.

Assim, o agente participa da mesma forma que o colaborador mais bem informado. Ele apresenta evidências: seus registros de sessão, rotulados e com os custos indicados. Ele responde a perguntas: “o que você realmente tentou antes da solução alternativa?” tem uma resposta respaldada pela transcrição. Ele elabora, mas nunca decide: as correções propostas chegam com sugestões de abordagem; o grupo as altera, redefine suas prioridades ou as descarta. E ele retoma as ações aceitas (a edição do documento, a alteração na configuração), executando-as após a cerimônia, sob revisão normal. A prática de pesquisa tem um nome para essa divisão: na estrutura ACE, o agente é o Refletor e um Curador consolida o que entra no manual de procedimentos. Fazemos uma adaptação deliberada: na ACE, o curador é um componente determinístico; aqui, os curadores são a equipe.

Uma assimetria diz respeito à carga de trabalho. Tudo o que o agente traz para dentro da sala deve ser livre de restrições — um agente que precise de permissão para relatar atritos acaba subnotificando. Tudo o que sai da sala para o que os agentes utilizam posteriormente (memória, arquivos de contexto, configuração) passa por uma revisão padrão, pois esse caminho de gravação é uma superfície reconhecida de contaminação e desvio (OWASP Agentic Top 10, ASI06). O procedimento se situa exatamente nessa fronteira: evidências sem restrições na entrada, gravações restritas na saída.

Os quinze minutos

O que estamos, na verdade, propondo que uma equipe tente, neste sprint, com cada ciclo já funcionando normalmente:

1. A cada sessão, o agente redige uma breve reflexão retrospectiva sobre seu próprio trabalho: o que deu certo, cada ponto de atrito com a indicação da causa raiz e o custo envolvido, uma proposta de correção no formato de ticket e o nível de prioridade almejado. Enviada junto com o trabalho, sem restrições.
2. Antes da retrospectiva, as contribuições recebidas desde a última sessão são sintetizadas em um resumo de uma página: temas recorrentes com maior prevalência, qual grupo de causas-raíz predomina, se as soluções anteriores foram adotadas e as três principais ações recomendadas. O resumo serve de base para a conversa; ele não a substitui.
3. Na retrospectiva (um item da pauta, não uma nova reunião): quinze minutos sobre “o que funcionou com a IA neste ciclo e o que continuou sendo um problema?”. Os humanos fazem a triagem: manter ou descartar, confirmar ou redirecionar as prioridades, designar responsáveis para as três principais.
4. No próximo ciclo, a verificação de adoção do briefing indica se o atrito realmente diminuiu. É essa verificação que transforma o relatório em um ciclo — e foi também nisso que nosso próprio conselho nos flagrou.

Modos de falha, assim chamados para que você possa se proteger contra eles: teatro retrô (a cerimônia que você realiza para o público: leitura breve, acenos de cabeça, nada decidido; a regra dos “três principais com proprietários” existe por causa disso); culpa do agente (tratar “o agente errou” como a explicação, em vez de como o resíduo; a maioria das falhas remonta ao conjunto de testes e às entradas, não ao raciocínio do modelo); proliferação da lista de desejos (vinte ações, nenhum responsável); e o ciclo que nunca se fecha (a lacuna no acompanhamento: as correções são implementadas, mas ninguém verifica a tendência). Escrevemos um guia prático completo sobre como as cerimônias falham; todos os modos nele descritos se aplicam aqui também.

O que não estamos afirmando

Não substitui nenhum ciclo de fornecedores: as saídas deles são as entradas desta cerimônia. Não é uma nova reunião. Não é uma cerimônia conduzida por IA; vinda de uma empresa cujo produto são as retrospectivas, essa restrição é deliberada. Não é necessária para quem trabalha sozinho, cujos ciclos se fecham bem por intuição. E a meta não é a ausência total de atrito: algum atrito serve como superfície de controle, e o item da pauta existe para escolher, não para ser eliminado à primeira vista.

O que nos faria mudar de ideia?

Este é um documento de discussão, portanto, eis a parte falsificável. Se os ciclos dos fornecedores gerarem um julgamento genuíno que abranja diversas ferramentas e pessoas, e não apenas gravações de memória em toda a frota, o escopo se reduzirá a uma função de auditoria. Se as equipes que executam a versão assíncrona “apenas com resumo” apresentarem a mesma tendência de redução de atrito que as equipes que executam o item da pauta, os quinze minutos serão mera encenação e nós o diremos. E nossa própria afirmação sobre o vocabulário rotulado baseia-se em um experimento de confiabilidade entre avaliadores que estamos realizando atualmente com entradas reais, em vez de uma afirmação prévia. Preferimos publicar os números do que a confiança.

Se sua equipe estiver realizando qualquer versão disso (o item da pauta, o briefing assíncrono ou uma cerimônia que ainda não tenhamos pensado), queremos saber o que aconteceu: ai-discussion@TeamRetro.com.

---

Próximo capítulo: Como conduzir a retrospectiva de colaboração com IA — o guia do facilitador para os quinze minutos: o modelo, o formato de contribuição e os cartões de sugestão. Parte do guia de retrospectivas de agentes de IA.