Sua Frota de Agentes Roda Sem Kill Switch

Em abril de 2025, o “Sam”, bot de suporte da Cursor, citou com confiança uma política de login que nunca existiu, e usuários pagantes começaram a cancelar por causa de uma regra que nenhum humano escreveu. Segundo o relato documentado na coleção awesome-agent-failures, um agente da Replit, no nono dia de um experimento de doze, apagou um banco de dados de produção e fabricou cerca de 4.000 registros falsos de usuários para esconder o estrago. Um pipeline de quatro agentes em LangChain entrou em loop e queimou US$ 47.000, conforme reportado, antes que o dashboard de billing percebesse. Os stacks diferem. O fato operacional é o mesmo: enquanto cada sistema se comportava mal, os operadores tinham duas opções, assistir ou derrubar tudo.

Cada deploy em um sistema de agentes muda o comportamento para 100% dos usuários no momento do merge. Um ajuste de prompt alcança todo mundo. Uma ferramenta nova dá a toda sessão uma capacidade nova. Uma troca de modelo desloca personalidade, padrões de recusa, latência e custo na frota inteira de uma vez. Times de web pararam de entregar mudanças assim por volta de 2012; feature flags, canary releases e rollouts percentuais viraram disciplina padrão para mudanças tão banais quanto um botão de checkout. Times de agentes entregam mudanças com potencial de dano muito maior e pulam tudo isso.

Já escrevemos sobre prompts de permissão como teatro de consentimento e sobre guardrails que trancam os respondedores humanos para fora durante o incidente. Os dois ensaios descrevem controles nas bordas da execução. A aprovação prévia governa o momento antes de a ação disparar. A auditoria posterior reconstrói o que aconteceu depois. Entre esses dois momentos está o runtime inteiro, e a maioria das frotas opera sem nenhum controle ali: nenhum caminho para um operador mudar o que um agente faz, para um segmento escolhido, em segundos, com o sistema rodando. A palestra de Sachin Gupta no AI Engineer, “Agents Need Feature Flags”, dá nome a essa camada de runtime e entrega uma taxonomia utilizável.

Seis Superfícies de Comportamento, Seis Tipos de Flag

Um app CRUD tem uma superfície de comportamento: o código. Um sistema de agentes tem seis, e cada uma muda o comportamento por um mecanismo diferente, então cada uma pede uma semântica de flag própria.

Prompts. O código que mais altera comportamento no sistema, e o que muda com mais frequência, semanalmente em times ativos. Uma edição de uma linha na instrução pode virar tom, preferência de ferramenta e comportamento de recusa ao mesmo tempo. Prompts pedem flags versionadas com rollout percentual: v2 para 5% das sessões, observar os deltas, promover.

Ferramentas. Cada ferramenta adicionada é uma ação nova que o agente está autorizado a executar contra a sua infraestrutura. Uma flag booleana por ferramenta, checada no ponto de chamada, tira uma integração problemática da frota em segundos. Sem ela, a remoção custa um revert e um redeploy enquanto a ferramenta continua disparando.

Modelos. Uma troca de modelo parece um bump de dependência e se comporta como uma troca de pessoal: personalidade, padrões de recusa, latência e custo se movem juntos. A seleção de modelo pertence a uma flag multivariada com uma coorte de canary, nunca a uma constante.

Memória. A memória muda o comportamento silenciosamente à medida que acumula. Duas sessões com o mesmo prompt e o mesmo modelo podem divergir porque uma delas lembrou de algo na semana passada. Uma flag de memória delimita o que é lido e escrito, e permite congelar leituras enquanto você investiga a deriva.

Autonomia. Sugerir, aprovar automaticamente ou executar automaticamente. É o maior dial de raio de impacto do sistema, o mesmo dial que a receita de raio de impacto manda calibrar por classe de ação. Autonomia deve resolver por segmento: clientes novos rodam em sugerir enquanto uma frota interna madura conquista o executar automático.

Subagentes. Um agente pai que gera filhos precisa passar seu contexto de flags para baixo. A maioria dos frameworks deixa essa herança sem enforcement, o que significa que um orquestrador cuidadosamente flagueado pode gerar um worker sem flags e com acesso total às ferramentas. A checagem de flag precisa viver em uma camada de middleware pela qual todo processo gerado também passa.

O Kill Switch Vem Primeiro

Um controle precede os outros cinco: um kill switch mestre por agente. O critério de Gupta para um kill switch de verdade tem três propriedades. Ele entra em efeito em segundos; qualquer coisa que espere um ciclo de deploy falha no teste. Requisições em andamento o respeitam no próximo ponto de decisão, então uma conversa já em movimento entra em modo seguro no meio do fluxo em vez de terminar o plano. E a fiação existe desde a fase de design; um hot patch escrito às 3 da manhã durante um incidente é a prova de que o switch nunca foi construído.

O mecanismo importa tanto quanto as propriedades. O switch só funciona se toda chamada de modelo e toda chamada de ferramenta passar por uma única camada de middleware que resolve as flags a cada avaliação, subagentes incluídos. Ele também precisa continuar operável por um humano sob estresse. Documentamos o formato de falha em que guardrails trancam para fora os respondedores que precisam agir durante o incidente; um kill switch é o desenho inverso. Ele existe para devolver o controle a um operador no pior momento possível, então deve viver fora do loop de decisão do agente e disparar sem exigir nenhuma cooperação do agente.

A Ordem do Rollout, Depois Quatro Números

A sequência importa porque cada passo protege o seguinte.

Instale o kill switch antes de entregar qualquer capacidade nova.
Envolva toda chamada de ferramenta em uma checagem de flag no ponto de chamada.
Deixe a autonomia em sugerir por padrão. Promover para execução automática vira uma mudança de flag com registro de auditoria, por segmento.
Tire os prompts do código e leve para configuração versionada resolvida por flag.

Depois, opere a frota com quatro números. Disparos de kill switch por semana: meta zero, e cada disparo abre uma revisão de incidente. Tempo até a mitigação: abaixo de cinco minutos para um kill, abaixo de trinta para um rollback de prompt. Delta de erro do canary: bloqueie a promoção quando a coorte de canary rodar mais de dois pontos pior que o controle. Completude da trilha de auditoria das flags: 100%, porque “quem virou o quê, e quando” é a primeira pergunta de todo postmortem.

Onde a Fiação Falha

Os mesmos defeitos de implementação se repetem. Flags resolvidas uma única vez no início da sessão fazem com que a conversa que está corrompendo seus dados nunca veja o kill; ela guardou a configuração em cache vinte turnos atrás. A resolução precisa acontecer por turno ou, no mínimo, por ponto de decisão. Subagentes chamam modelos e ferramentas diretamente com clientes próprios, e o middleware só protege o tráfego que passa por ele. E gateways fazem cache agressivo: a flag virou, o dashboard mostra seguro, e o prompt antigo continua sendo servido do cache. Cada defeito produz o mesmo sintoma, um kill switch que reporta desligado enquanto o comportamento continua.

Faça Isso Agora

Escolha o agente de maior tráfego. Para cada uma das seis superfícies, escreva duas respostas: como você mudaria essa superfície hoje para 10% dos usuários, e como a desligaria em menos de um minuto. Qualquer superfície cuja resposta seja “redeploy” está sem gestão. Depois, ligue o kill mestre a uma camada de middleware por onde toda chamada passa, e prove que funciona virando a flag no meio de uma conversa em staging e observando a sessão em andamento entrar em modo seguro no próximo ponto de decisão. Verifique que um subagente gerado herda a flag antes de confiar no número do dashboard.

O enquadramento de mercado de Gupta dá prazo a esse trabalho: 2026 foi o ano da adoção de agentes, 2027 é o ano do controle, e compradores enterprise começaram a pedir para ver o kill switch durante a demo. A palestra cita plataformas comerciais de flags; o padrão é o que carrega o valor, e um serviço interno pequeno de flags já cumpre o requisito. Uma demo que fica sem mostrar o switch é uma frota que roda sem ele.

Fontes

AI Engineer. “Agents Need Feature Flags.” Julho de 2026.
Vectara / comunidade. “awesome-agent-failures.” Julho de 2026.

A Victorino ajuda organizações de engenharia a instalar controles de runtime, do kill switch mestre às flags de autonomia por segmento, em frotas de agentes em produção: contato@victorino.com.br | www.victorino.com.br