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

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 material de referência complementar a este 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 da nossa prática, dos nossos rótulos ou do 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 definem 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 seja resolvido no nível adequado. 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 · programado	—
1 · Detecção	Como se percebe o atrito?	autoverificação · revisão por agente secundário · correção humana · telemetria	revisão de rastreamento, análise de erros
2 · Instrumentação	Como o agente sabe que deve rastreá-lo?	habilidade · gancho · convenção · comando	—
3 · Gravação	Como isso é capturado e onde?	memória · armazenamento MCP · logs/rastreamentos · tickets · commits marcados	codificação aberta, memória episódica
4 · Colheita	Como vocês se reúnem para mais de uma sessão?	mineração de rastreamentos x agregação de artefatos · varredura x evento · deduplicação	—
5 · Síntese e direcionamento	Registros brutos → padrões → qual o nível de correção?	agrupar + pontuar e, em seguida, rotear 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 quê. As configurações mais eficazes fazem uma triangulação: a telemetria sinaliza 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), utiliza um rótulo 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 fica, cada opção apresenta uma verdadeira contradição: 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/rastros (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, umwork-material-frictionrótulo que vincula o atrito à alteração exata, embora apenas quando o trabalho é incorporado ao controle de versão. Nada disso é específico ao 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 posteriormente: 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 no 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 aparece, porque a agregação é o que reavalia as prioridades: um incômodo de cinco minutos que ninguém resolveria individualmente representa um dos principais custos da equipe quando somado.

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 no nível certo: direcionar cada padrão para o nível adequado 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 de nível superior). Se ficar abaixo do alvo (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 ficar acima do alvo (uma nova habilidade para um caso isolado), você incha um artefato até que ele deixe de ser lido. O campo convergiu para o mesmo gradiente de forma independente: reduza a importância da memória efêmera, promova o aprendizado duradouro para o controle de versão — os documentos do Windsurf/Devin recomendam 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; as orientações do Codex da OpenAI afirmam 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” (uma recapitulação da palestra de Ronacher na AIE Europe), portanto, a triagem inclui decidir entre 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, é pura encenação. 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. O único critério de classificação que esta tabela aplica é o nível em que cada ciclo opera — e o que se deve observar depois que a tabela for classificada:

Loop	Funciona em	Fechar o ciclo ao
Engenharia de Ciclos / Engenharia de Compostos	um profissional	regras pessoais, orientações, manuais de estratégias
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 com portas de acesso, 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 registro automático 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 preparação, comandos, manuais de procedimentos e diretrizes de segurança

Leia a coluna do meio novamente: um profissional, uma sessão, uma plataforma, uma pilha. Quase todos os ciclos na área são executados 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, não um conjunto fixo; a análise dos seus traços é “a atividade mais importante nas avaliações”
Quatro Camadas (Greyling)	qual camada da pilha apresentou falha	4 camadas	síntese dos 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 ocorreu 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 é versionado e passível de revisão

agent-errorDuas observações sobre a leitura. Primeiro, os eixos são realmente distintos: os esquemas de sintomas (os 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 (umawork-material-frictionconstatação aponta para o próprio material — dívida técnica no código, ou uma conta, tabela ou 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 já aprendeu: rótulos do tipo -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á tem:

• Você possui 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 da 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, 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 propõe soluçõ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 correçõ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, é essa ú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 em onde as correções seriam aplicadas, 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 camadas uma a uma: o 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 em nível de equipe se apresenta na prática. Comece por onde estiver sua linha em branco.

Próximo capítulo: Como é um bom registro de atrito — capturar o momento, as classificações das causas-raíz e as regras de “nunca registrar”.