Sua Camada de Governança de Agentes é uma Válvula de Mão Única

Menos de 100 milissegundos. Esse é o orçamento de latência que engenheiros da Uber impuseram à camada que inspeciona cada chamada de modelo da frota, e a justificativa que eles deram é a frase mais útil que li sobre governança de agentes neste ano. No relato da Port sobre uma palestra dos engenheiros da Uber Uday Kiran Medisetty e Adam Huda: “aplicado a toda chamada de modelo e com um orçamento estrito de latência, ninguém se dá ao trabalho de contorná-lo”.

Isso é uma restrição de projeto e também uma confissão. Um controle que cobra tempo real do chamador acaba contornado pelo chamador. Sem má intenção. Um engenheiro com prazo apertado encontra o endpoint direto, um framework de agentes traz o próprio cliente, um job em lote pega o caminho rápido “só para a carga histórica”. Governança cara de obedecer se degrada em governança que ninguém obedece, e nenhum documento de política reverte isso. A resposta da Uber foi tornar a obediência mais barata que a evasão.

A escala por trás desse orçamento merece registro. Segundo a mesma palestra, mais de 100 milhões de requisições de modelo por dia, distribuídas em mais de 800 projetos, passam pelo gateway de LLM da Uber, que remove mais de 20 tipos de dado pessoal e roda um “AI guard” composto por cinco modelos menores, tudo dentro da mesma janela abaixo de 100ms. Um gateway de MCP separado expõe mais de 1.000 ferramentas e reduziu o uso de tokens em mais de 40% na frota. Mais de 70% dos pull requests na Uber hoje vêm de agentes locais ou em nuvem, e as linhas de código por engenheiro dobraram ano a ano.

Uma ressalva sobre esses números, e ela importa. Vêm de uma palestra de conferência, relatada pela Port, uma fornecedora que vende exatamente essa categoria de plataforma. A própria Port afirma que os números, a arquitetura e as decisões de projeto são da Uber. Leia como o relato público de um time de engenharia sobre o próprio sistema, sem auditoria independente.

O Mesmo Argumento, em Escala Pequena

O segundo exemplo é o mais aproveitável, porque não depende da escala da Uber para fazer sentido. A Octopus Deploy publicou o desenho de um bot de incidentes movido a IA, e a restrição escolhida é aritmética antes de ser arquitetural: o modelo pode propor exatamente cinco tipos de remediação. pod_restart, resource_increase, config_update, image_fix, deployment_rollback. A saída do modelo é restrita a um JSON que precisa casar com um schema predefinido, sem geração de comando arbitrário em nenhum ponto do caminho.

Patroklos Papapetrou, escrevendo pela Octopus, resume o princípio em uma linha: “o modelo deve ajudar a interpretar o incidente, não controlar a execução”. E a frase que deveria estar pregada acima de todo projeto de remediação autônoma: “um modelo relatando confiança ALTA não garante que o diagnóstico esteja correto nem que a ação proposta seja segura”.

Repare no que a Octopus deixou de construir. Nenhum motor dinâmico de política, nenhuma pontuação de risco, nenhuma camada aprendida de confiança. Uma lista de cinco permitidos e um schema. Esse controle é barato de obedecer pelo mesmo motivo que o da Uber é: não existe caminho mais rápido do que o que o schema já autoriza. É a versão pequena da mesma ideia, e não exige plataforma nenhuma para construir. Já argumentamos o caso inverso, que uma superfície de controle sem execução é um documento, e que contrapressão pertence ao modelo de risco em vez da agenda de quem aprova.

Os Dois Portões Correm em Uma Direção Só

Agora olhe o que esses dois sistemas têm em comum além de serem bons. Todo componente descrito é de entrada. O agente propõe, a camada inspeciona, a camada permite, bloqueia ou reescreve. Dado pessoal removido na entrada. Ferramentas resolvidas na entrada. Tipo de remediação validado na entrada. A regra de loop interno da Uber tem o mesmo formato: o agente de código para em um draft PR e não empurra para a CI, porque, nas palavras do time, isso martela a CI compartilhada antes de qualquer pessoa confirmar que a funcionalidade sequer funciona.

Controles excelentes. Todos respondem a uma pergunta: o agente pode fazer isso?

Nenhum responde à outra: o agente percebeu alguma coisa. Para onde ela vai?

Ron Bronson nomeia isso de forma direta. A distinção dele é entre um roteador de julgamento e um canal de exceção. O roteador de julgamento avalia incerteza, risco, autoridade e novidade, e então permite, escala ou bloqueia uma ação proposta. O canal de exceção roda fora desse portão. Ele nem autoriza nem bloqueia. Ele reporta uma condição encontrada durante um trabalho que já estava autorizado. O texto de Bronson não traz estatística alguma e nem finge trazer. É uma contribuição conceitual, e o valor dela está em nomear um componente que nenhum desses dois sistemas possui.

O exemplo dele é pequeno o bastante para incomodar. Um agente que reservava aulas de academia contra uma API GraphQL descobriu que podia cancelar reservas de outros membros e removê-los de listas de espera. Nada do que o agente fez era não autorizado. Reservar a aula era a tarefa. A permissão de cancelar reservas alheias estava ali na API, descoberta como efeito colateral de executar corretamente o trabalho designado. Isso é um achado, e nenhum pedido de permissão o acompanha. O roteador de julgamento não tem o que avaliar, porque nada está sendo proposto. E naquele sistema o achado não tinha rota nenhuma, exceto um humano reparar por acaso.

Multiplique pela escala. A 100 milhões de requisições de modelo por dia, quantos achados desse formato uma frota gera em uma semana? O grafo de contexto da Uber guarda 40 milhões de entradas, com 150 tipos de nós e arestas, substituindo contexto que antes estava espalhado por 20 a 30 sistemas. Esse grafo é um ativo de entrada extraordinário: é o que o agente lê. O equivalente de saída, um lugar onde o agente escreve o que aprendeu sobre o sistema em que estava operando, é outra estrutura, com outro consumidor.

O Custo de uma Condição Não Reportada

A queda do GitHub em 17 de agosto durou 7 horas e 47 minutos. O relato do CTO Vlad Fedorov sobre a recuperação: “erros nesses serviços dispararam um laço de retentativa no lado do cliente que aumentou o tráfego durante a recuperação. Precisamos mitigar esse comportamento antes de restaurar o tráfego com segurança”. Os commits mensais na plataforma cresceram de 1,4 bilhão para 2,9 bilhões desde abril.

Não estou afirmando que agentes causaram aquela queda, e o GitHub não diz isso. O que o incidente ilustra é o formato do problema. Cada cliente naquele laço de retentativa estava fazendo exatamente o que tinha autorização para fazer. Repetir uma requisição que falhou é comportamento correto. A falha estava no agregado, e era um comportamento do lado do cliente que só o lado do servidor conseguiu mitigar. Um portão de aprovação sobre cada retentativa individual teria liberado todas elas, corretamente. A condição que valia reportar não era ação alguma isolada. Era o padrão que o ator enxergava e o portão não.

É essa a classe de sinal que um canal de exceção carrega. A gramática dele é “você precisa saber”, registrada enquanto o trabalho autorizado continua. Permissões descobertas que a tarefa nunca precisou. Dados alcançáveis que quem pediu provavelmente não pretendia expor. Um runbook desatualizado que o agente contornou em silêncio. Comportamento de retentativa que o agente mede localmente e a plataforma não enxerga.

Já escrevemos sobre as seis superfícies que um kill switch precisa cobrir e sobre os tetos de custo da própria Uber. Aquilo são mecanismos de parada. Este aqui aponta para a direção oposta, e é a que nenhum dos dois sistemas construiu.

Construa a Versão Barata Primeiro

Não comece por uma plataforma. Comece por uma tabela e uma regra, e submeta as duas à mesma lógica de latência que mantém o gateway da Uber de pé.

Dê a cada agente um único destino de escrita não bloqueante. Um endpoint, uma fila, uma tabela, o que sua stack já operar. Quatro campos carregam a maior parte do valor: o que o agente estava autorizado a fazer, o que ele observou, onde observou e quão certo está. A escrita jamais pode bloquear a tarefa nem derrubar a tarefa. Um canal de exceção capaz de quebrar o trabalho vai ser removido do trabalho.

Depois defina a única regra que o separa do seu alerta atual: este canal é para condições encontradas durante trabalho autorizado, e pedidos de permissão ficam de fora. Qualquer coisa que pergunte “posso?” pertence ao caminho de aprovação que você já tem. Misturar os dois transforma o canal em uma segunda fila de aprovação, e uma segunda fila de aprovação acaba silenciada como toda fila sem dono.

Depois escolha um dono e uma cadência de revisão. Semanal já basta para começar. Um canal que ninguém lê é pior que canal nenhum, porque produz a papelada da governança sem nenhum efeito dela.

O número da Uber é o que fica, por um motivo que pouco tem a ver com desempenho. Os 100ms são o preço que eles aceitaram pagar para que o controle continue no caminho quando as pessoas estão com pressa. Aplique o mesmo teste à direção de saída. Se reportar um achado custa ao agente mais do que ficar quieto, seus agentes vão ficar quietos, e você só vai descobrir o que eles acharam quando alguma pessoa por acaso perceber.

Fontes

Port. “How Uber built a software factory: the MCP gateway and the platform underneath.” Agosto de 2026.
Octopus Deploy. “Building an AI-powered incident bot with Octopus Deploy.” Agosto de 2026.
Ron Bronson. “Agent experience needs failure affordances.” Agosto de 2026.
GitHub. “The August 17 outage, and the work ahead.” Agosto de 2026.

A Victorino ajuda times de engenharia a desenhar o caminho de reporte que falta na plataforma de agentes, ao lado do caminho de aprovação que já existe: contato@victorino.com.br | www.victorino.com.br