O Agente Nunca Se Torna Confiável. O Sistema Se Torna Legível.

Mallory Haigh, Head of Platform Education and Advocacy na Platform Engineering Consulting, publicou neste mês um texto com três perguntas que, segundo ela, uma organização precisa saber responder antes de deixar agentes operarem: “Quem é esse agente danado? O que foi pedido a ele? Por qual definição de pronto isso foi considerado aceitável?”

A maioria das organizações de engenharia responde a primeira. Algumas respondem a segunda. Quase nenhuma responde a terceira, porque a definição de pronto nunca foi escrita em lugar nenhum. Ela morava na cabeça de quatro ou cinco pessoas que revisavam tudo o que importava.

O enquadramento que ela dá à mudança é a frase que vale discutir: “O engenheiro era a instituição da confiança, e a assinatura digital dele no fim da revisão era a procuração de um sistema cultural inteiro de valores.” Aquela assinatura nunca foi uma declaração sobre o código. Era a declaração de que uma pessoa carregando os padrões não escritos da organização olhou a mudança e deu o aval.

Duas ressalvas sobre a fonte antes de seguir. O artigo está marcado como patrocinado no platformengineering.org e aponta repetidamente para o produto da própria autora. E não traz nenhum dado medido: nenhum benchmark, nenhuma pesquisa, nenhuma contagem de incidentes. A “revisão manual de 45 minutos” que ele descreve é ilustração. Leia como argumento bem construído, não como evidência.

A assinatura fazia um trabalho invisível

Quando um engenheiro sênior aprovava um pull request, várias verificações rodavam sem aparecer em lugar algum do diff. Esse padrão bate com a forma como tratamos retentativas neste código? Esse é o tipo de mudança que precisa avisar o time de dados? A última pessoa que mexeu neste módulo deixou uma mina que combinamos não pisar? O jurídico se importaria com o fato de isso logar o e-mail do cliente?

Nada disso estava em um linter. Parte estava em uma página de wiki que ninguém lia. A maior parte estava no revisor.

O arranjo funcionava porque o volume de mudanças era limitado pela vazão humana e porque os revisores permaneciam. As duas condições estão falhando. O volume deixou de ser limitado, e os revisores que carregavam os padrões estão sendo chamados a revisar código que não escreveram, em um ritmo que não deixa espaço para o reconhecimento de padrões que dava sentido à aprovação deles.

Já argumentamos que conhecimento tácito é dívida de governança e que padrões de time precisam virar forma executável. Haigh acrescenta algo que nenhum dos dois textos resolveu: quem deveria fazer essa escrita, e em que ordem.

A prestação de contas migra do social para o arquitetural

O modelo antigo era social. Você confiava no revisor porque conhecia a pessoa, porque ela tinha se queimado na mesma indisponibilidade que você, porque o nome dela na aprovação tinha custo profissional se desse errado. A prestação de contas fluía por uma relação.

Um agente não tem relação para oferecer como garantia. Falta a ele carreira a proteger, memória do chamado das duas da manhã, reputação em um time que queira manter. A prestação de contas que existir precisa estar construída na estrutura ao redor: o prompt que delimitou o trabalho, a política que o restringiu, a avaliação que o julgou, o rastro que registrou os três. A formulação de Haigh é que agentes precisam que “o implícito se torne explícito, na linguagem deles, em escala”.

Essa última parte é a que sustenta o peso. Muitas organizações escreveram documentos de padrões. Pouquíssimas os escreveram em um formato que um agente consuma no momento da decisão, e menos ainda têm como testar se o agente honrou o que estava escrito. Uma página de Confluence descrevendo sua filosofia de tratamento de erros é explícita para humanos e invisível para todo o resto.

A escavação tem dono, e é a engenharia de plataforma

Essa é a parte que a indústria insiste em deixar sem atribuição. Todo mundo concorda que os padrões tácitos precisam ser extraídos. Quase ninguém diz de quem é a tarefa, então ela vira aspiração compartilhada e, portanto, entrega de ninguém.

Haigh coloca isso no time de plataforma, e o argumento se sustenta. Engenharia de plataforma já é dona da estrada pavimentada. Já decide o que o pipeline padrão exige, quais imagens base são abençoadas, o que um serviço precisa passar antes de receber tráfego de produção. Cada um desses itens é um padrão codificado que um dia foi conhecimento tribal. Extrair a definição de pronto é a mesma categoria de trabalho, aplicada a um domínio mais difícil.

A descrição que ela faz desse trabalho é incomum pela honestidade: times de plataforma que entendem isso “estão fazendo algo que parece terapia e age como arqueologia: trazendo à superfície as premissas que a organização nunca soube que carregava, tornando-as legíveis e as codificando em algo versionável e rastreável”.

A parte de terapia é real. Pergunte a dois engenheiros seniores o que significa “pronto” para uma migração de banco e você costuma receber duas respostas, ambas confiantes, ambas parcialmente não documentadas, e uma discussão curta que nenhum dos dois esperava ter. Essa discussão é a entrega. Ela sempre existiu, resolvida em silêncio toda vez por quem calhava de revisar.

Versionável e rastreável é a metade mais difícil. Um padrão que vive em documento se degrada em silêncio. Um padrão que vive em arquivo de política, com histórico de commits e suíte de testes, se degrada fazendo barulho. O segundo pode ser apontado durante uma análise de incidente.

Infraestrutura de avaliação vem antes, não junto

A regra de sequenciamento de Haigh é a afirmação operacional do texto, e é a que a maioria dos times está violando agora: “a infraestrutura de avaliação precisa existir antes de você conceder o próximo nível de autonomia”.

Não em paralelo. Não como ajuste rápido depois que o piloto for bem. Antes.

O modo de falha que isso evita é familiar para quem já viu uma capacidade correr na frente da própria instrumentação. Um time deixa agentes abrirem pull requests, vê bons resultados por três semanas, estende o mandato para um segundo repositório, depois para migrações, depois para configuração de produção. Em nenhum momento alguém construiu como medir se a saída atendia ao padrão, porque em cada momento a etapa anterior tinha parecido boa. Quando algo quebra, a organização descobre que lhe falta linha de base, suíte de regressão para comportamento de agente e qualquer forma de saber se aquilo foi anomalia ou a quarta ocorrência de um padrão.

A regra funciona como catraca. Cada nível de autonomia é destravado pela existência de um jeito de julgar o nível abaixo dele. Isso inverte a forma como pilotos são conduzidos hoje, em que avaliação é aquilo que se constrói depois que o valor foi provado.

O artigo também oferece uma escada de quatro níveis para autolocalização: executor, validador, orquestrador, definidor de restrições. A progressão serve como espelho útil, e vem do produto comercial da própria autora, então trate como vocabulário e não como avaliação de maturidade contra a qual você deva ser pontuado. O que ela faz bem é forçar uma pergunta específica. Se seus engenheiros ainda estão executando e validando mudanças individuais, conceder autonomia de nível de orquestração a agentes significa que os humanos pularam um degrau também.

Faça isto agora

Escolha a revisão mais consequente que seu time executa. Aprovação de deploy, mudança de schema, qualquer coisa que toque dado de cliente. Reúna as duas ou três pessoas que de fato a executam por 45 minutos e faça uma pergunta: o que faz você rejeitar isso?

Anote toda resposta. Você vai obter regras já documentadas, regras documentadas e erradas, e regras que nunca foram escritas em lugar nenhum e com as quais todos na sala mesmo assim concordam. Essa terceira categoria é a escavação. É também a razão pela qual seus agentes ainda não podem ser confiáveis, e nenhuma ferramenta comprada vai produzi-la.

Depois, verifique o sequenciamento antes de expandir qualquer coisa. Para cada concessão de autonomia em andamento, pergunte se existe uma avaliação capaz de pegar a falha que preocupa você. Se a resposta for não, a concessão é prematura por melhor que o piloto tenha ido.

O agente nunca vai construir reputação. O sistema ao redor dele pode se tornar inspecionável, e era só isso que estava sendo confiado desde o começo.

---

Fontes

• platformengineering.org. “Platforms are sitting on buried knowledge. Your agents are forcing you to dig it up.” Julho de 2026.

A Victorino ajuda times de plataforma a extrair padrões tácitos de revisão para política versionada e testável antes de conceder autonomia: contato@victorino.com.br | www.victorino.com.br