O panorama: ciclos de retroalimentação, ferramentas e abordagens dos agentes

A TeamRetro se interessa por todos os ciclos de melhoria contínua realizados pelas equipes; o trabalho assistido por IA é uma nova área que estamos analisando sob a ótica da retrospectiva. Esta página é o complemento de referência deste guia: todo o conteúdo apresentado de forma sistemática. Se você preferir começar pela história, vá até a introdução do guia e depois volte.

O que é esta página

Três coisas, em ordem: o ciclo de vida que um único problema de atrito percorre, desde que ocorre até ser resolvido; os ciclos nomeados que a área criou para executar esse ciclo de vida, classificados pelo nível em que cada um opera; e os esquemas de classificação em uso para nomear o que deu errado. Leia de cima para baixo para identificar a posição da sua equipe: quais etapas suas ferramentas já cobrem, qual ciclo você já está executando com outro nome e qual vocabulário você usaria para classificar as descobertas. Tudo aqui é independente: nada disso exige a adoção de nossa prática, nossos rótulos ou nosso produto.

O ciclo de vida: sete etapas, do atrito à solução

Quando um agente que está realizando um trabalho concreto se depara com um obstáculo (um documento que falta, uma instrução ambígua, uma ferramenta instável), esse sinal é efêmero: o agente contorna o problema, a sessão termina e, na sessão seguinte, ele se depara com o mesmo obstáculo. Os padrões de atrito de Rahul Garg enquadram o custo de primeira ordem (o Ciclo de Frustração: gerar → revisar → não se encaixa → regenerar); o ciclo de vida abaixo mapeia o problema de segunda ordem: o que precisa acontecer para que o atrito se torne uma solução no nível correto. A lacuna é mensurável: cerca de 90% das equipes monitoram os rastros dos agentes, mas apenas cerca de 37–52% os avaliam sistematicamente (LangChain, junho de 2026). A maioria das equipes consegue observar o atrito; muito menos conseguem transformá-lo em soluções.

Palco	A pergunta a que ela responde	Opções	Termo de profissional
0 · Hospedagem	Onde o agente é executado?	CLI local · web · IDE · CI/sem interface gráfica · agendado	n/a
1 · Detecção	Como se percebe o atrito?	autoverificação · revisão por agente secundário · correção humana · telemetria	revisão de traço, análise de erros
2 · Instrumentação	Como o agente sabe que deve rastreá-lo?	habilidade · gancho · convenção · comando	n/a
3 · Gravação	Como isso é capturado e onde?	memória · armazenamento MCP · logs/traços · tickets · commits marcados	codificação aberta, memória episódica
4 · Colheita	Como vocês se reúnem para atividades que vão além de uma única sessão?	mineração de rastreamentos x agregação de artefatos · varredura x evento · deduplicação	n/a
5 · Síntese e direcionamento	Registros brutos → padrões → qual nível de correção?	agrupar + pontuar e, em seguida, classificar por altitude	codificação axial, taxonomia de falhas
6 · Fechar o ciclo	A correção reduziu o atrito futuro?	avaliar a tendência	Volante de retroalimentação, engenharia de efeito cumulativo

Etapa 0: Hospedagem

Tudo o que vem a seguir depende de onde o agente é executado. Um agente CLI local deixa um registro no disco e pode gravar arquivos na memória; um agente de CI ou headless pode ser efêmero, sendo seu único rastro o que foi registrado antes do contêiner ser encerrado; um agente web ou IDE mantém um histórico no lado do servidor que você pode consultar, mas não filtrar com o grep; um agente agendado é executado sem supervisão humana. A hospedagem define as opções para todas as etapas posteriores: o que é observável, onde o estado pode persistir e quem (ou o que) pode analisá-lo. A contrapartida: observabilidade local mais rica versus a reprodutibilidade e o armazenamento centralizado das execuções hospedadas.

Etapa 1: Detecção

Quatro canais, raramente exclusivos. Autodetecção (o agente reconhece suas próprias tentativas repetidas e retrocessos) é a opção mais econômica, mas a mais tendenciosa: o agente não sabe o que não sabe. A revisão por um agente secundário, em que um novo agente lê a transcrição posteriormente, é mais objetiva, mas exige uma segunda análise. A correção humana é o sinal de maior qualidade e ainda o dominante: um estudo de produção de oito semanas constatou que cerca de 70% das falhas silenciosas foram detectadas inicialmente por um ser humano que percebeu que algo estava errado (arXiv 2606.14589). A telemetria (taxas de erro de ferramentas, recusas de permissão, contagem de loops) é automática, mas superficial: ela sabe o que aconteceu, não por que. As configurações mais eficazes fazem uma triangulação: a telemetria indica onde procurar, e uma revisão explica o motivo.

Etapa 2: Instrumentação

Um agente não registrará atrito a menos que algo o provoque. As opções, dependendo do quanto dependem da memória do modelo: uma habilidade (um procedimento explícito e portátil invocado em um ponto de parada: claro, mas precisa realmente ser acionado), um gancho (disparado automaticamente no início ou no fim da sessão: confiável, mas genérico), uma convenção (uma instrução no arquivo de contexto: infraestrutura mínima, baseada na boa-fé) ou um comando (acionado por humanos: deliberado, mas dependente da intervenção humana). Essa é a etapa mais frequentemente ignorada, e é por isso que tantos atritos passam despercebidos: ninguém disse ao agente para verificar.

Etapa 3: Gravação

Duas perguntas: o que um bom registro contém e onde ele fica armazenado. Um registro útil cita evidências (o que aconteceu, quanto custou), possui um rótulo proveniente de um vocabulário fixo para que os registros possam ser comparados posteriormente e termina com uma proposta de próximo passo. Quanto ao local onde ele fica, cada opção apresenta uma verdadeira dilema: arquivos de memória (duráveis e de baixo atrito, mas privados e com estrutura flexível), um armazenamento MCP (compartilhado e pesquisável, mas que requer um servidor), logs/traços (automáticos e completos, mas o sinal fica enterrado no ruído), tickets (passíveis de ação e visíveis para a equipe, mas pesados por item) ou commits e PRs marcados, por exemplo, uma work-material-frictionetiqueta que vincula o atrito à alteração exata, embora apenas quando o trabalho é incorporado ao controle de versão. Nada disso é específico de código: o registro de uma conta de equipe de mídia ou o histórico anotado de uma fila de suporte também são substratos de registro. Uma advertência que se aplica a qualquer substrato no qual os agentes venham a se basear: a memória gravada por agentes é uma superfície identificada de ataque e desvio (OWASP Agentic Top 10, ASI06), um argumento a favor de gravações revisadas e respaldadas por evidências.

Etapa 4: Colheita

O atrito em uma sessão é ruído; o mesmo atrito ao longo de oito sessões é um problema de processo. A escolha estratégica é entre mineração de rastros (reler transcrições brutas: completo, mas caro e com grande impacto na privacidade) e agregação de artefatos (analisar os registros deliberadamente escritos: barato, mas cuja qualidade depende da disciplina da Etapa 3); os pipelines reais combinam ambos. Depois, a cadência (uma varredura programada versus coleta ao final da sessão) e o trabalho pouco glamoroso da deduplicação: o mesmo atrito expresso de cinco maneiras diferentes por cinco pessoas precisa ser reduzido a um único padrão com uma contagem precisa. É na coleta que o valor surge, pois a agregação é o que repondera as prioridades: um incômodo de cinco minutos que ninguém resolveria individualmente se torna um dos principais custos da equipe quando agregado.

Etapa 5: Síntese e direcionamento

Duas etapas. Agrupar e pontuar: agrupar os resultados em padrões, classificados por frequência × custo; é para isso que servem os esquemas de classificação abaixo. Focar na prioridade: direcionar cada padrão para o nível correto de correção, do efêmero ao estrutural (memória → habilidade/sugestão → ambiente e configuração → documentação → o próprio material de trabalho → processo → ferramenta ou fornecedor a montante). Se você ficar aquém da meta (uma nota de memória particular para o que, na verdade, é um documento da equipe que está faltando), o atrito se repete para todos os outros; se você ultrapassar a meta (uma nova habilidade para um caso isolado), você incha um artefato até que ele deixe de ser lido. A área de atuação convergiu para o mesmo gradiente de forma independente: reduzir a importância da memória efêmera, promover o aprendizado duradouro para o controle de versão. Documentação do Windsurf/Devin recomenda promover lições recorrentes para regras ou para o AGENTS.md (o arquivo de instruções permanentes que os agentes leem), em vez de depender de memórias automáticas; a orientação do Codex da OpenAI afirma que o caso de “cometer o mesmo erro duas vezes” justifica uma atualização do AGENTS.md, e a memória do Copilot expira em 28 dias por padrão: a memória não promovida deve ser eliminada. Uma conclusão sintética é fácil de passar despercebida: nem todo atrito é desperdício. Parte dela é a superfície de controle: “o atrito é o que é necessário… para dirigir” (um resumo da palestra de Ronacher na AIE Europe), portanto, a triagem inclui manter ou eliminar, não apenas corrigir.

Etapa 6: Fechar o ciclo

O verdadeiro teste de todo o ciclo de vida: esse tipo de atrito tende a diminuir nas sessões subsequentes? Uma correção que é registrada, mas nunca é implementada, ou que é implementada, mas não muda nada, é apenas teatro. Essa é a condição do Feedback Flywheel de Garg e a premissa da engenharia composta: cada correção facilita a próxima unidade de trabalho, se o ciclo realmente se fechar.

Os loops nomeados, por nível operacional

A área de conhecimento tem se alinhado a esse ciclo de vida sob pelo menos meia dúzia de nomes. Todos eles são válidos; nada nesta página substitui nenhum deles. A única forma de classificação aplicada nesta tabela é o nível em que cada ciclo opera, e o que deve ser observado após a classificação:

Loop	Funciona em	Fechar o ciclo ao
Engenharia de Ciclos / Engenharia de Compostos	um profissional	regras pessoais, orientações, guias de ação
agent-retro	uma sessão	alterações de habilidades/configurações por sessão a partir da transcrição
Sensores de engenharia de chicotes elétricos (Thoughtworks)	a estrutura de uma base de código (a estrutura que envolve o modelo)	integrar instrumentos de feedback nativos (testes, linters, CI) no ciclo do agente
Sonhando (Anthropic, OpenAI)	a memória de uma plataforma	mineração em tempo ocioso do histórico de sessões para gerar diferenças de memória controladas, em toda a frota
Motor LangSmith / Tópicos do Braintrust	uma pilha de observabilidade	agrupar falhas de produção em problemas, elaborar PRs e avaliações
Sinais de fábrica	uma plataforma única para agentes	detecção de padrões de atrito nas sessões e criação automática de tickets
Informações sobre a sessão do gh-aw (GitHub)	sessões de uma plataforma	relatórios automatizados de análise de sessões ao longo das execuções do fluxo de trabalho dos agentes (exemplo de 50 sessões)
Feedback Flywheel (Garg)	os artefatos de uma equipe	transformar os aprendizados em documentos de orientação, comandos, guias de procedimentos e diretrizes de segurança

Leia a coluna do meio novamente: um profissional, uma sessão, uma plataforma, uma pilha. Quase todo ciclo na área é executado individualmente ou no nível da frota: uma pessoa e seu agente, ou um fornecedor e toda a sua base instalada. Apenas o “flywheel” de Garg abrange a equipe, e sua lista de cadência menciona o local (um item da pauta na retrospectiva de sprint existente) sem colocá-lo em prática. Essa é a nossa interpretação do tipo, e é o único ponto em que a perspectiva deste guia se destaca: o nível da equipe é a camada aberta (muitas pessoas, muitos agentes, mais de uma ferramenta, com os responsáveis pelas correções na mesma conversa). Se você estiver executando qualquer ciclo acima, continue executando-o; a camada da equipe consome a saída deles, não compete com eles.

Os esquemas de classificação

Para agrupar os pontos de atrito, são necessárias categorias, e os esquemas do campo classificam coisas diferentes; eles não são tanto rivais, mas sim instrumentos voltados para questões distintas:

Esquema	O que ele classifica	Forma	Confiabilidade / origem
MAST	como os sistemas multiagentes falham	14 modos / 3 categorias	150 traços analisados por especialistas, validados em mais de 1.600; κ entre anotadores = 0,88
Escola de análise de erros (Husain/Shankar)	seja lá o que for que seus próprios rastros revelem	aberto; as categorias surgem a partir dos seus dados	metodologia, e não um conjunto fixo; a análise dos seus rastros é “a atividade mais importante nas avaliações”
Quatro Camadas (Greyling)	qual camada da pilha apresentou falha	4 camadas	síntese de relatórios de falhas em campo; cerca de 9,9% das falhas atribuídas ao raciocínio do modelo
TraceProbe	ações de tratamento de erros em rastreamentos	9 ações	análise automatizada de traços
Sinais de fábrica	qual sintoma de atrito uma sessão apresenta	7 tipos de sinal	sessões de codificação de produção do agente
Nosso vocabulário sobre causas fundamentais	por que surgiu o atrito na colaboração	10 etiquetas / 5 grupos; o grupo codifica a altitude fixa	sessões de trabalho, com desenvolvedores e sem desenvolvedores; a confiabilidade entre avaliadores ainda não foi medida: o experimento está em andamento, e o vocabulário está versionado e sujeito a revisões

Duas observações sobre a leitura. Primeiro, os eixos realmente diferem: os esquemas de sintomas (sinais da Factory) indicam que uma sessão deu errado; os esquemas de camadas (Quatro Camadas) indicam em que parte da pilha; um vocabulário de causas explica o motivo, e é isso que permite que um rótulo encaminhe parcialmente sua própria solução (uma work-material-frictionconstatação aponta para o próprio material: dívida técnica no código, ou uma conta, um quadro ou um modelo confuso fora dele; um rótulo de briefing aponta para o processo). Segundo, a tensão entre o universal e o emergente é real: taxonomias fixas garantem comparabilidade e confiabilidade mensurável na rotulagem (o κ = 0,88 do MAST é o padrão), enquanto categorias emergentes se adaptam à sua distribuição real de falhas. Um meio-termo viável mantém um pequeno vocabulário fixo para agregação, com notas de evidência em código aberto abaixo de cada rótulo. E uma advertência que todo o campo mereceu: rótulos do tipo agent-error-style devem ser o residual, não o padrão. A escola de engenharia de harness rejeita explicitamente esse reflexo, em que o engenheiro culpa o modelo e o arquiva na categoria “aguardar a próxima versão”; em vez disso, corrija o harness (Osmani, Agent Harness Engineering). A análise de quatro camadas atribui apenas cerca de 9,9% das falhas ao raciocínio do modelo.

Localize-se

Um breve diagnóstico. Percorra as etapas e marque o que você já possui:

• Você tem registros ou logs de sessão (ferramentas de observabilidade, JSONL no disco, histórico do lado do servidor) → A detecção e o registro estão garantidos. Os números do LangChain sugerem que é nesse ponto que a maioria das equipes para.
• Algo lembra o agente de registrar o atrito (uma habilidade, um gancho de interrupção, uma convenção de arquivo de contexto) → A instrumentação está garantida; se nada fizer isso, essa costuma ser a primeira solução mais econômica.
• Você atualiza o AGENTS.md / CLAUDE.md quando algo se repete → você está fazendo a Síntese no nível individual, seguindo o padrão do Codex de “cometer o mesmo erro duas vezes”.
• Sua plataforma organiza suas memórias para você (consolidação no estilo “Dreaming”, memória do Copilot) → coleta e síntese em nível de frota, dentro dessa plataforma.
• Sua pilha de observabilidade agrupa falhas e rascunhos de correções (Engine, Topics, Signals) → síntese no nível da pilha, para o tráfego que a pilha monitora.
• Alguém analisa periodicamente as sessões, as pessoas e as ferramentas, e os responsáveis pelas soluções decidem em conjunto → Coleta e síntese em nível de equipe. Essa é a linha que a maioria das equipes deixa em branco.

A lacuna comum, segundo nossa observação, está na última linha: a visão agregada que abrange ferramentas e pessoas, e as decisões que ela suscita: manter ou descartar, em que nível, qual a prioridade. Observe a questão do escopo da revisão que vem junto com isso: qual trabalho deve ser incluído em um grupo para uma discussão? O repositório, o produto, a conta de anúncios, a caixa de entrada de suporte, o engajamento com o cliente? Defina o escopo com base no destino das correções, e os casos que não envolvem código sejam encaminhados de forma tão natural quanto os que envolvem código.

O restante deste guia aborda as etapas uma a uma: a introdução conta a história de forma narrativa; os capítulos seguintes tratam de captar o atrito no momento, da coleta de informações ao longo das sessões, da decisão de altitude e de como um espaço de trabalho em equipe se apresenta na prática. Comece por onde estiver sua linha em branco.

Próximo capítulo: Como é um bom registro de atrito aborda a captura no momento, os rótulos de causa raiz e as regras de “nunca registrar”.