Seu Agente Já Sabe o Que Está Errado — Você Só Não Está Ouvindo

A Factory publicou um artigo técnico detalhado em janeiro. Não sobre um modelo novo. Não sobre benchmarks. Sobre o que acontece depois que você coloca um agente em produção — especificamente, o que acontece quando você realmente observa o trabalho dele.

O sistema deles, chamado Signals, usa um LLM para analisar milhares de sessões diárias de agentes. Identifica padrões de fricção — onde os usuários travam, onde os agentes falham, onde as conversas descarrilam — sem expor o conteúdo bruto de nenhuma sessão individual. Os números de um relatório amostral: 1.946 sessões em 39 lotes. 58% continham momentos de fricção. 83% continham momentos de satisfação. Essas duas estatísticas coexistindo dizem tudo sobre o estado atual da IA agêntica.

A maioria das organizações pararia em “58% de fricção.” O Signals não para aí.

Os Sete Sinais de Fricção em Agentes

A Factory identificou sete padrões distintos de fricção em sessões de agentes, cada um com diferentes distribuições de severidade:

Eventos de erro (35% alta severidade) — os óbvios. O agente lança um erro, o usuário percebe.

Reformulação repetida (42% alta severidade) — o usuário pergunta a mesma coisa três ou mais vezes de formas diferentes. Significa que o agente ouviu, mas não entendeu.

Tom de escalação (28% alta severidade) — a linguagem do usuário muda de colaborativa para diretiva. Frustração vazando pela escolha de palavras.

Confusão de plataforma (15% alta severidade) — o usuário não entende o que o agente pode fazer. Um problema de design de produto, não de IA.

Fluxos de ferramentas abandonados (48% alta severidade) — o usuário começa a usar uma funcionalidade e desiste no meio. A maior taxa de severidade na taxonomia, e o mais subdiagnosticado.

Retrocesso (22% alta severidade) — o usuário desfaz manualmente o que o agente fez. Rejeição silenciosa.

Rotatividade de contexto (38% alta severidade) — usuários repetidamente adicionando e removendo itens da janela de contexto. Este é especial.

Rotatividade de Contexto: O Indicador Antecedente Que Ninguém Monitora

De todos os sete tipos de fricção, a rotatividade de contexto é o mais interessante porque precede os outros. Usuários mexendo no contexto — adicionando um arquivo, removendo, adicionando outro diferente, removendo também — é um sinal comportamental de que o usuário perdeu a confiança na capacidade do agente de compreender a tarefa. Estão tentando fazer o agente entender reestruturando seus inputs, e falhando.

A Factory descobriu que a rotatividade de contexto frequentemente aparece antes de qualquer um dos outros seis sinais. É o indicador antecedente, não o consequente. Quando o usuário começa a reformular ou escalar, a fricção já vem se acumulando há várias rodadas.

Se o seu monitoramento só captura erros e timeouts, você está vendo os sintomas. A rotatividade de contexto é o diagnóstico.

Recuperação de Erros Supera Prevenção de Erros

Aqui está a descoberta contraintuitiva: sessões onde agentes se recuperaram graciosamente de erros pontuaram mais alto em satisfação do que sessões impecáveis do início ao fim.

Isso inverte a prioridade padrão de engenharia. A maioria das equipes otimiza para prevenir falhas. Os dados da Factory sugerem que deveriam otimizar para se recuperar delas. Um usuário que observa um agente tropeçar, reconhecer o problema e se corrigir sai mais impressionado do que um usuário cuja sessão por acaso foi tranquila.

A implicação para operações é significativa. A confiabilidade do agente não está em eliminar erros. Está em garantir que o sistema detecte erros, comunique-os de forma transparente e os resolva rapidamente. Resiliência sobre perfeição.

O Ciclo de Autocorreção

A parte operacionalmente mais interessante do Signals não é a detecção — é o que acontece depois dela.

Quando padrões de fricção excedem um limiar, o sistema abre automaticamente um ticket no Linear. Um Droid (o agente autônomo da Factory) se autoatribui o ticket, implementa uma correção e conduz sua própria revisão de código. Um humano então aprova ou rejeita o merge.

Essa porta de aprovação humana importa. Este não é um sistema totalmente autônomo. É um sistema semiautônomo com um checkpoint humano no momento mais consequente — o momento em que o código entra em produção. O padrão é: detecção automatizada, diagnóstico automatizado, implementação automatizada, julgamento humano na implantação.

Os resultados: 73% dos problemas registrados automaticamente foram resolvidos sem intervenção manual além daquela porta de aprovação. Tempo médio de implantação de correção inferior a quatro horas. Uma redução de 30% na fricção de reformulação repetida depois que o sistema implementou melhorias no tratamento de ambiguidade.

Este é um ciclo fechado operando em escala de produção. Não um protótipo de pesquisa. Não uma demonstração. Um sistema processando quase duas mil sessões diárias e se aperfeiçoando com base no que observa.

A Lacuna de Observabilidade

A entrevista de Eno Reyes com o Stack Overflow em fevereiro de 2026 adiciona uma dimensão importante. O CEO da Factory argumenta que a qualidade base do código — não o volume de código, não a taxa de adoção de IA — é o preditor mais forte de se agentes de IA vão acelerar ou desacelerar uma organização de engenharia.

A Factory identifica centenas de sinais de validação em desenvolvimento de software: compilação, linting, passagem de testes, qualidade de documentação, scores de complexidade, varreduras de segurança. A maioria das organizações implementa muito poucos desses de forma abrangente. A tese é que a autonomia vem não de modelos melhores, mas de trazer mais desses sinais automaticamente.

Isso mapeia diretamente no sistema Signals. O agente melhora não porque alguém ajustou um modelo. Melhora porque o sistema observa seu próprio desempenho, quantifica a fricção e aplica correções direcionadas. Os sinais são o caminho para a autonomia.

O Que Isso Significa para Operações

A maioria das conversas sobre agentes de IA foca em capacidade: o que o agente consegue fazer? A contribuição da Factory é reformular a pergunta: o que você consegue ver sobre o que o agente faz?

Um agente operando sem observabilidade é como uma linha de manufatura sem controle de qualidade. Pode produzir bom output por um tempo. Você não vai saber quando parar, e não vai saber por quê.

A taxonomia de sete sinais da Factory não é o único framework possível. Mas ilustra a observação mínima viável: você precisa ver erros (o óbvio), padrões comportamentais (o sutil) e indicadores antecedentes (o preditivo). A maioria das organizações hoje mal consegue ver erros.

O ciclo de autocorreção é a aspiração. Antes de chegar lá, você precisa responder perguntas mais simples: quantas das suas sessões de agente têm fricção? De que tipo? Quais padrões se repetem? Qual é o tempo de ciclo de correção quando você identifica algo?

Se você não consegue responder essas perguntas, seu agente já está dizendo o que está errado. Você só não está ouvindo.

A Questão da Privacidade

Uma objeção ao monitoramento abrangente de agentes é a privacidade. Se você analisa cada sessão, vê tudo o que os usuários fazem.

A Factory aborda isso através de abstração em camadas. O LLM extrai padrões comportamentais enquanto omite conteúdo específico. Resultados de sessões individuais se agregam em estatísticas significativas apenas em escala. Padrões emergem apenas quando há sessões distintas suficientes para impedir a identificação de usuários individuais.

A abordagem funciona, mas os detalhes de implementação importam. A Factory usa BigQuery e a API Batch da OpenAI para processamento, o que significa que dados de sessão — por mais abstraídos que sejam — passam por infraestrutura externa. Organizações com requisitos rígidos de residência de dados precisarão adaptar essa arquitetura.

O ponto não é que a implementação específica da Factory seja universal. O ponto é que a objeção de privacidade é resolvível. A lacuna de observabilidade é uma escolha, não uma restrição técnica.

De Reativo para Preditivo

O roadmap da Factory aponta para indicadores de fricção em tempo real durante sessões ativas — não apenas análise em lote diária. Além de correções reativas, o Signals identifica capacidades ausentes quando agrupamentos de sessões revelam pedidos repetidos por funcionalidades que não existem. Uma proposta recente do sistema: rastrear “desvio de especificação,” quando usuários gradualmente mudam seus objetivos no meio da conversa.

Essa trajetória — de observação em lote para monitoramento em tempo real para intervenção preditiva — espelha a evolução da observabilidade tradicional de infraestrutura. Fomos de arquivos de log para dashboards para detecção de anomalias para autorremediação. A observabilidade de agentes está seguindo o mesmo caminho, comprimida em meses ao invés de décadas.

As organizações que construírem essa infraestrutura agora terão uma vantagem composta. Não porque seus agentes são melhores — os modelos estão cada vez mais comoditizados. Porque podem ver o que seus agentes fazem, medir quão bem fazem, e melhorar o sistema sistematicamente.

É isso que operar IA realmente significa.