Seus agentes não vão quebrar a stack de IA primeiro. Vão quebrar os sistemas construídos para o ritmo humano
Controle de código da Anthropic, backtests da Third Moment e agendador de jobs da Databricks: mesmo limite, sistemas para pessoas. Um framework para auditar os seus antes do volume de agentes.
Ouça este artigo · 4 min
Narração completa do artigo, gerada por IA.
A maioria das revisões de risco de IA enterprise olha para o modelo e para o agente: o que ele pode acessar, o que ele pode dizer, o que ele pode fazer. Elas raramente olham para o que o agente fará com todo o resto. Os relatórios de engenharia desta semana sugerem que é aí que os primeiros problemas de produção em escala realmente aparecem.
As mudanças mescladas da Anthropic cresceram de cerca de 2,500 para mais de 30,000 por dia em quatro meses, e as premissas do Git quebraram antes do seu armazenamento. Os agentes de pesquisa da Third Moment queimaram seus orçamentos fazendo polling de um backtest de três horas. Os pesquisadores da Databricks lançaram oito vezes mais jobs de treinamento quando agentes rodaram experimentos, e descobriram que inicializações lentas e erros confusos se tornaram o gargalo. Nenhum desses foi uma falha de modelo. Cada um era um sistema projetado em torno de como as pessoas trabalham, encontrando software que funciona de forma diferente.
Nossa visão, e é uma visão construída a partir desses sinais, não de uma lei medida: os primeiros sistemas a falhar sob a adoção de agentes são os dimensionados para o ritmo humano. Pessoas agem algumas vezes por hora, toleram esperar, leem erros ambíguos com julgamento e são limitadas em número. Agentes agem continuamente, nunca se cansam de tentar de novo, leem erros literalmente e se multiplicam sob demanda.
Uma auditoria de ritmo
A resposta prática é uma auditoria dos sistemas que os agentes vão tocar, feita antes que o volume chegue. Para cada um, anote a premissa que ele faz sobre seus usuários, o que quebra quando essa premissa falha, e o primeiro sinal que você verá.
| Assume | Quebra no ritmo dos agentes como | Primeiro sinal | |
|---|---|---|---|
| Controle de código | Commits ocasionais, cópias locais completas | Carga de clone e fetch, espelhos atrasados | Minutos de CI por mudança mesclada aumentando |
| Revisão de código | Uma pessoa lê cada mudança | Uma fila que ninguém consegue esvaziar, ou aprovações automáticas | Tempo médio de espera para revisão crescendo mais rápido que a produção |
| CI e fila de merge | Merges chegam um de cada vez | Filas serializadas que nunca esvaziam | Tempo de fila excedendo o tempo de build |
| Agendadores de jobs | Usuários pacientes que leem erros | Retentativas, polling e falhas mal interpretadas | Tempo de lançamento e taxa de retentativa por job |
| Workflows de aprovação | Algumas solicitações por dia por aprovador | Fadiga de aprovação; aprovação deixa de significar revisão | Tempo de aprovação caindo para segundos |
| Cotas e licenças | Limites por pessoa ou assento | Throttling, contas surpresa, identidades compartilhadas | Erros de rate-limit e picos de gasto por agente |
Duas linhas merecem atenção especial, porque falham silenciosamente. Um sistema de controle de código sob carga fica lento e alguém percebe. Um processo de revisão sob carga continua funcionando: aprovações ainda acontecem, apenas sem ninguém lendo. Uma aprovação que leva quatro segundos é uma assinatura, não uma revisão. Esse é o custo que descrevemos em verificação como o novo gargalo, visto pelo lado da infraestrutura.
Três movimentos de design que ajudam em todos os lugares
Substitua a espera por sinais. Polling é o equivalente do agente a uma pessoa atualizando uma página, multiplicado por milhares. Callbacks de conclusão, notificações de eventos e esperas duráveis removem isso. A correção da Third Moment foi jobs mais rápidos; a correção mais geral é nunca fazer um agente perguntar “já acabou?”
Fixe o que os agentes executam. Agentes disparam pipelines com muito mais frequência do que pessoas, então qualquer coisa que possa mudar por baixo de um pipeline importa mais. Os novos lockfiles de workflow do GitHub, em preview público desde 14 de outubro, fixam Actions e workflows reutilizáveis, incluindo dependências transitivas, a commits específicos enquanto arquivos de workflow mantêm suas referências existentes, e administradores podem exigi-los por política. Um lockfile não torna um commit fixado seguro, mas impede que uma dependência mude após a revisão sem uma mudança no seu repositório.
Dê aos agentes suas próprias cotas e identidades. Contas de serviço compartilhadas e limites por assento escondem quem está consumindo o quê. Cotas por agente tornam a carga visível e o limite uma decisão, que é o arquivo de agente com orçamento que defendemos anteriormente.
Execute a auditoria antes que o piloto escale
O momento mais barato para encontrar um problema de ritmo é antes que um piloto bem-sucedido seja copiado pela empresa. Uma regra útil: quando um time propõe escalar um agente dez vezes, pergunte qual dos seis sistemas da tabela ele vai carregar, e quem é o dono de cada um. Se ninguém souber responder, o plano de escala é um plano de modelo, não um plano de produção.
O conselho da Anthropic para outras empresas foi trazer as ideias do Scion para o Git em vez de adotar o Scion. O mesmo se aplica aqui. Ninguém precisa reconstruir sua infraestrutura para agentes em 2026. Todos que os implantam precisam saber em quais premissas sobre o ritmo humano seus sistemas estão silenciosamente se apoiando, e quais os agentes estão prestes a aposentar.