Onde a correção deveria ser aplicada?
Identifique cada caso de atrito do agente com sua causa raiz, e isso indicará o nível (memória, documentação, processo ou etapa anterior) em que a solução duradoura deve ser aplicada.
Duas equipes, o mesmo atrito, um quarto diferente
Duas equipes começam a registrar os obstáculos que seus agentes de IA enfrentam: as solicitações ambíguas, os documentos desatualizados, as ferramentas instáveis e as repetições de tarefas.
A primeira equipe resolve tudo no nível mais próximo possível. Cada incômodo recorrente se transforma em um ajuste imediato ou em uma anotação na memória; qualquer coisa mais complexa vira mais um parágrafo no arquivo de contexto. Três meses depois, seus agentes operam com instruções inchadas que ninguém lê do começo ao fim, e o atrito que realmente importava — o modelo de briefing que deixa o escopo indefinido, a conta de publicidade cuja estrutura atrapalha todas as sessões — ainda está lá, porque nenhum ajuste rápido consegue resolvê-lo.
A segunda equipe faz uma pergunta a mais por padrão: onde essa correção realmente se encaixa? O grupo “os agentes ficam tentando adivinhar nosso público-alvo” se transforma em uma mudança na forma como o trabalho é orientado: uma correção no processo, acordada em uma reunião da equipe. O grupo “manual de procedimentos desatualizado” se transforma em uma correção na documentação, com um responsável designado. A peculiaridade pontual se torna uma nota de lembrança e nada mais. Três meses depois, seus arquivos de instruções estão mais curtos do que quando começaram, e as categorias de atrito que eles corrigiram apresentam uma tendência de queda.
A diferença não está na disciplina de registro. Ambas as equipes fizeram os registros. A diferença está em uma questão de roteamento que a primeira equipe nunca levantou.
A jogada principal: pontos de atrito em altitude
Quando uma sessão assistida por IA encontra um obstáculo, a causa raiz aponta para um nível no qual reside a solução duradoura. Chamamos isso de altitude da solução; as altitudes disponíveis vão do efêmero ao estrutural:
memória → habilidade/orientação → ambiente e configuração → documentação → o próprio material de trabalho → processo/fluxo de trabalho → produto ou fornecedor anterior
Identificar o problema transforma uma reclamação em uma correção que pode ser implementada. “O agente errou a estratégia de lance novamente” é uma reclamação. “A decisão sobre a estratégia de lance nunca foi registrada em nenhum lugar onde o agente pudesse encontrá-la: uma correção na documentação, e aqui está o manual de procedimentos onde ela deve constar” é uma tarefa com um destino específico.
Errar na definição da meta traz problemas em dois sentidos. Subestimar a meta — uma anotação pessoal que, na verdade, substitui um documento da equipe que está faltando — significa que o atrito se repete para todos que não são você: um custo de recorrência para o restante da equipe. Excesso de definição de metas (uma nova habilidade para um caso isolado, mais um parágrafo em um arquivo de contexto já inchado) é um custo de manutenção para o artefato; a área de atuação nomeou os antipadrões com precisão: proliferação de habilidades (16→48 habilidades em 15 dias: “Adicionar habilidades é fácil. … A gestão é a parte difícil.”) e inchaço do arquivo de contexto (“um arquivo de memória que deixou de ser lido”, segundo esta nota de campo). Os fornecedores convergiram para o mesmo gradiente vindo do outro extremo — rebaixar a memória efêmera, promover o aprendizado duradouro para o controle de versão: Windsurf/Devin (“escreva como uma Regra ou adicione ao AGENTS.md… em vez de depender de Memórias geradas automaticamente”, documentação), OpenAI Codex (“quando o Codex cometer o mesmo erro duas vezes, peça a ele uma retrospectiva e atualize o AGENTS.md”, melhores práticas), a validade de 28 dias deliberada da memória do Copilot.
Portanto, o setor conhece os dois modos de falha. O que faltava era um instrumento de roteamento.
Um vocabulário fixo que direciona
Nossa proposta de trabalho: atribuir a cada problema de atrito exatamente uma causa raiz a partir de um vocabulário fixo de dez rótulos divididos em cinco grupos: pequeno o suficiente para ser memorizado, focado nas causas em vez de nos sintomas e deliberadamente independente de ferramentas e disciplinas:
- Resumo:
ambiguous-instruction,missing-context,incorrect-context,changed-requirements - Documentação:
missing-documentation,incorrect-documentation - Material de trabalho:
work-material-friction - Ferramentas:
missing-access-or-tool,environment-friction - Agente:
agent-error
O grupo é a chave de roteamento. No momento em que uma descoberta é rotulada, ela já está parcialmente roteada:
| Dominante no grupo | A correção geralmente fica em | Artefatos típicos |
|---|---|---|
| Reunião informativa | processo (como o trabalho é orientado) ou uma memória persistente | modelo de resumo, lista de verificação para o início do projeto, arquivo de registros |
| Documentação | documentos | README, manual de procedimentos/SOP, arquivo de contexto, especificação |
| Material de trabalho | o próprio material | código: a refatoração para a qual o atrito continua apontando; não código: a reestruturação da conta, do painel ou do modelo |
| Ferramentas | environment/config ou upstream | configurações, configuração do MCP, concessão de acesso, ticket do fornecedor |
| Agente | solicitação, habilidade ou proteção | editar habilidade, hook, eval |
Uma observação sincera logo de início: os grupos recebem esse nome devido aos seus destinos de fixação; portanto, a afirmação de que “o rótulo define parcialmente a rota de fixação” é verdadeira por definição — trata-se de uma escolha de projeto, não de uma descoberta empírica. A afirmação empírica subjacente é que as etiquetas no momento da captura são precisas e consistentes, que é exatamente o que ainda não medimos (mais detalhes abaixo).
Observe o quework-material-frictionisso abrange, pois é aí que o vocabulário justifica sua alegação de ser independente de disciplina. No código, trata-se da dívida técnica: o módulo que todas as sessões acabam encontrando. Fora do código, isso é igualmente real. Imagine uma equipe de marketing cujo agente audita uma conta do Google Ads que cresceu por acúmulo: três gerações de convenções de nomenclatura, campanhas pausadas que ninguém ousa excluir, palavras-chave duplicadas em grupos de anúncios sobrepostos. A cada sessão, o agente gasta seu primeiro tempo reconstruindo qual campanha é responsável por quê, e toda recomendação vem acompanhada de uma ressalva. Nenhuma solução rápida resolve isso; nenhuma anotação na memória resolve para a próxima pessoa. O rótulo é work-material-friction, sempre associado ao material concreto denominado (esta conta), e a altitude é o próprio material: a reestruturação para a qual o atrito continua apontando. O mesmo padrão existe em planilhas emaranhadas, bagunças de modelos de CMS e bibliotecas de macros de suporte; um ciclo moldado por um agente de programação não tem para onde colocar tudo isso.
Por que “fixa” em vez de “emergente”? Porque, para uma equipe, a taxonomia é um instrumento de coordenação, não um exercício de classificação. “O mesmo atrito ao longo de oito sessões é um problema de processo” só faz sentido se todas as oito sessões o tiverem rotulado da mesma forma; as afirmações sobre distribuição precisam de um denominador estável; e as linhas de tendência (“o atrito nas reuniões de briefing diminuiu desde que corrigimos o modelo de briefing?”) só se mantêm se um rótulo significar a mesma coisa em março e em julho. Categorias emergentes, em que cada pessoa codifica as suas próprias, são a escolha certa individualmente, mas, em uma equipe, elas variam de pessoa para pessoa, e nada se agrega sem uma etapa de reconciliação pela qual ninguém se responsabiliza. Mantemos o mecanismo emergente em funcionamento em dois lugares: uma nota com evidências citadas abaixo de cada rótulo e uma revisão periódica do vocabulário, na qual as notas acumuladas testam a validade dos rótulos. O vocabulário é versionado; ele foi projetado para mudar com base em evidências, não para ser defendido.
O que já existe, comparado com honestidade
Não fomos nós que inventamos as taxonomias de falhas, e as que já existem cumprem bem o seu propósito.
MAST (arXiv 2503.13657) é a taxonomia fixa de referência: 14 modos de falha em 3 categorias, derivados de 150 traços analisados por especialistas e validados em um corpus de mais de 1.600 casos, com forte concordância entre os anotadores (κ = 0,88). Ela classifica como os sistemas multiagentes falham, tendo sido criada para pesquisa e benchmarking — mais próxima da nossa em termos de disciplina, mas diferente no objeto de estudo: nós classificamos por que ocorreu atrito na colaboração entre humanos e agentes.
A escola da análise de erros, a metodologia de avaliações de Husain & Shankar (Perguntas Frequentes sobre avaliações, janeiro de 2026), defende o oposto de uma lista fixa: as categorias “devem emergir de padrões de falha observados… e não de classificações predeterminadas de consultas”, e a leitura aberta de seus próprios rastros é “a atividade mais importante nas avaliações”.” Acreditamos que eles estejam certos na escala individual e que a situação se inverta na escala de equipe, pelas razões de agregação mencionadas acima. A disciplina de análise deles é fundamental em nossa proposta de qualquer maneira; é isso que são as notas de evidência.
Em torno desses eixos: a Taxonomia de Quatro Camadas (Greyling, maio de 2026) classifica qual camada da pilha falhou, atribuindo apenas cerca de 9,9% das falhas ao raciocínio do modelo: a maioria das falhas são problemas do harness (o harness é a estrutura de suporte ao redor do modelo), e é por isso que nossoagent-errorrótulo é residual, usado apenas quando as entradas eram adequadas (a escola de engenharia de harness rejeita explicitamente a tendência de culpar o agente — conserte o harness, não o agente: Osmani, Agent Harness Engineering). O TraceProbe classifica as ações de tratamento de erros nos rastros. Garg’s Feedback Flywheel coleta quatro tipos de sinais em artefatos da equipe, a estrutura na qual a nossa se insere: o contexto dele ≈ nossos grupos de briefing + documentação; o braço de falhas dele é o que nossa taxonomia decompõe. Factory Signals classifica sintomas de sessão em tickets preenchidos automaticamente; Braintrust Topics é a escola emergente transformada em produto, reagrupando seus rastreamentos diariamente.
Duas interpretações sinceras dessa comparação. Primeiro, a maioria delas classifica sintomas, camadas ou destinos; a nossa classifica causas — é isso que torna o rótulo uma chave de roteamento, e é essa a verdadeira alegação de novidade, por mais que seja. Segundo, e mais importante: o MAST mediu a confiabilidade da rotulagem e nós não. A confiabilidade entre avaliadores em nossos dez rótulos não foi medida, e tratamos isso como um pré-requisito, não como uma nota de rodapé: o experimento (avaliadores independentes rotulando às cegas as mesmas entradas reais, com a concordância relatada independentemente do resultado) está em andamento com entradas de nosso próprio teste ao vivo, tendo o κ = 0,88 do MAST como referência. Até que os resultados sejam divulgados, essa taxonomia é uma proposta em desenvolvimento com rótulos versionados, não um instrumento validado. Preferimos informar isso a vocês do que deixar que descubram por conta própria.
Também apoiamos todos os loops já em execução: Loop Engineering, Compound Engineering, agent-retro, retrospectivas do AGENTS.md, sistemas de memória de fornecedores e relatórios automatizados de sessão. Mantenham todos eles; nada aqui os substitui.
Por que a altitude é uma questão que diz respeito a toda a equipe
Eis a lacuna comum a esses ciclos existentes: quase todos são individuais (um desenvolvedor e seu agente, ou um fornecedor e sua frota). E os próprios números do setor indicam que a etapa mais cara não é o monitoramento: cerca de 90% das equipes implementam rastreamentos de agentes, mas apenas cerca de 37–52% os avaliam sistematicamente (LangChain State of Agent Engineering, junho de 2026). A camada ainda não explorada é a síntese no nível da equipe, e é exatamente aí que a visão de conjunto começa a fazer diferença, por dois motivos.
A agregação reajusta as prioridades. O incômodo de dez minutos para uma pessoa é apenas ruído; ninguém, racionalmente, resolve isso. O mesmo rótulo em oito sessões e cinco pessoas representa um dos maiores custos da equipe, e somente a visão agregada permite perceber isso. A agregação também é o que o vocabulário padronizado proporciona: as contagens só fazem sentido se todos usarem os mesmos rótulos.
Os níveis mais altos são de responsabilidade da equipe. Um indivíduo pode definir sua própria memória, orientações e configuração. Mas mudanças nos processos, decisões que envolvem várias ferramentas, orçamento para ferramentas e escalações para os níveis superiores — os níveis em que geralmente se concentram os maiores atritos recorrentes — são decisões que nenhum indivíduo pode tomar sozinho. É também por isso que acreditamos que a participação humana na síntese persiste, por melhores que sejam os modelos: as correções recaiem sobre artefatos pelos quais os humanos são responsáveis e pelos quais prestam contas: briefings, processos, orçamentos, acordos da equipe. Essa é uma afirmação sobre autoridade organizacional, não sobre a capacidade do modelo. E é uma participação no ciclo, não um bloqueio no fluxo: os agentes devem detectar, registrar, agrupar e elaborar rascunhos livremente; os humanos acrescentam o julgamento sobre o encaminhamento e assumem a responsabilidade.
Se sua equipe já realiza uma cerimônia de melhoria contínua, isso se encaixa nela: o panorama geral do atrito é apresentado, a equipe pergunta “onde cada correção se encaixa?”, e cada padrão sai com uma prioridade e um responsável. Não é um ritual novo — é uma retrospectiva com contribuições melhores. Os engenheiros de ML chamam isso de análise de erros de leitura; as equipes chamam o encontro de “retro”.
O que nos faria mudar de ideia?
Este é um documento para discussão; portanto, eis o que realmente nos deixa em dúvida:
- Confiabilidade. Se o experimento de interavaliadores indicar baixa concordância, as regras de delimitação (ou os próprios rótulos) estão incorretas, e nós as revisaremos sob o controle de versão, em vez de defendê-las.
- Tamanho. O número de rótulos é herdado, não derivado. O MAST tem 14; o Four-Layer, 4. Nossa distribuição de rótulos após um quarto das entradas reais é a evidência que a mantém ou a reestrutura.
- Modos ausentes. Atrito entre agentes (perda na transferência entre subagentes, falhas de orquestração) está atualmente classificado em
environment-friction; ocorrências reais podem exigir uma classificação própria. - Escopo das revisões que não envolvem código. Definimos o escopo das revisões com base no local onde as correções seriam implementadas: o repositório, para a maior parte do trabalho de desenvolvimento; e “conta”, “espaço de trabalho” ou “engajamento”, fora dele. Esses limites que não envolvem código são propostas que queremos testar com equipes reais.
- Viabilidade no momento da captura. As equipes ocupadas conseguem classificar as causas na hora, ou a classificação precisa ser feita durante a revisão? As equipes que experimentarem isso resolverão essa questão mais rapidamente do que nossas teorias.
Se você executar qualquer versão desse ciclo (categorias emergentes, um pipeline de fornecedores, uma planilha simples), gostaríamos de saber onde a tabela de roteamento apresenta falhas. Especialmente se você puder nos mostrar um padrão de atrito que não aponte para nenhuma altitude: ai-discussion@teamretro.com.
Próximo capítulo: O relatório existe. A sala, não. — por que o encaminhamento das correções é uma decisão da equipe e o que a equipe faz quando o relatório de atritos chega. Parte do guia de retrospectivas de agentes de IA.