Até recentemente, o tráfego na web aberta vinha em duas formas amplas. Navegação humana, episódica, limitada pela atenção, com um teto rígido definido por quantas páginas uma pessoa consegue ler em uma sessão. E scraping programático, de alto volume, em leque, majoritariamente sem estado, majoritariamente invisível para o usuário.
Uma terceira forma está emergindo rapidamente. Agentes de IA que usam navegador, Computer Use da Anthropic, Operator da OpenAI, os diversos agentes autônomos open-source, conduzem um navegador real através de uma sequência de páginas em nome de um usuário. O tráfego que eles geram não se parece com nenhuma das duas formas anteriores. Sites que se defenderam com sucesso contra scraping ainda não sabem o que fazer a respeito disso. Provedores de infraestrutura por baixo desses agentes ainda estão descobrindo as primitivas corretas.
Este post é um retrato de como o tráfego de agentes de IA realmente se parece em produção hoje e como isso moldou a pilha de infraestrutura que o sustenta.
Como o tráfego se parece na transmissão
Um fluxo canônico de agente de IA hoje: o usuário pede ao agente para “encontrar o voo direto mais barato de Nova York para Tóquio no final de agosto.” O agente inicia um Chromium headless, navega até o Google Flights, preenche o formulário, envia, analisa os resultados, segue para o mais barato no site da companhia aérea, navega até a página de reserva, confirma disponibilidade, retorna a resposta.
Isso equivale a 8-15 requisições HTTP ao longo de 30-90 segundos, com as seguintes propriedades:
Em rajadas. Ou zero requisições ou uma sequência sustentada, sem estado estável intermediário. O agente fica ocioso até o usuário perguntar, depois roda intensamente por um minuto.
Com estado dentro da rajada. O fluxo do agente tem cookies, uma sessão, um User-Agent. A requisição N+1 precisa parecer uma continuação da requisição N do ponto de vista do site alvo. Uma mudança de IP no meio do fluxo quebra a sessão.
Endpoints heterogêneos. Cada execução do agente visita múltiplos sites distintos, mecanismo de busca, companhia aérea 1, companhia aérea 2, possivelmente um agregador de comparação. Cada site tem sua própria postura anti-bot.
Geografia ancorada no usuário. O usuário quer voos a partir de JFK, não de um datacenter aleatório. O tráfego do agente deve geolocalizar de forma plausível para onde o usuário está fazendo o pedido, ou pelo menos para onde ele quer parecer estar reservando.
Sensível à latência. O usuário está esperando ali. Uma latência por requisição de 800ms em vez de 200ms se multiplica ao longo de 12 requisições até fazer a diferença entre “o agente respondeu em 30 segundos” e “o agente respondeu em 1,5 minutos.”
Essa forma não corresponde nem ao modelo de navegação humana (rápido demais, com estado demais em velocidade de máquina) nem ao modelo de scraping (poucas requisições demais por sessão, vinculado demais à sessão, ancorado demais ao usuário).
Por que a infraestrutura ingênua falha
Alguns padrões que equipes de dados experientes usam com sucesso não se transferem:
Rotação por requisição de um grande pool residencial. O padrão padrão de scraping. Errado para agentes porque a sessão precisa de coerência de IP, cookies de login, estado de busca, vinculação de fingerprint. A rotação por requisição quebra a sessão já na requisição 2.
Proxies de datacenter para velocidade. Tentador por causa do perfil de latência. Errado porque os alvos upstream que o agente visita (Google, companhias aéreas, e-commerce, bancos) se defendem agressivamente contra tráfego de datacenter. Metade das execuções do agente falha com CAPTCHAs.
IP residencial estático único. Tentador porque é coerente. Errado porque o IP se queima rápido entre agentes, um IP servindo milhares de fluxos de agente parece um scraper depois das primeiras 100 execuções.
A forma que funciona é mais próxima de sessões persistentes (sticky) em residencial, com uma sessão nova por execução do agente, com direcionamento geográfico que corresponde à intenção do usuário, com a sessão limitada ao ciclo de vida natural da execução.
O padrão que funciona
A arquitetura para a qual a maioria das implantações de agentes em produção converge:
user_request → agent.spawn( proxy_session_id=hash(user_id, request_id), # único por par usuário-execução proxy_country=user_geo_or_intent, proxy_ttl=longer_than_expected_run, # não expirar no meio do fluxo ) → browser navigates target sites through that session → agent returns result → proxy session expires naturallyA abstração de proxy é por execução, não por requisição. Dentro de uma execução, o agente tem um IP residencial consistente. Entre execuções, cada fluxo de agente recebe um IP novo de um ISP novo de (geralmente) uma cidade nova. A diversidade do pool protege contra qualquer IP único ser queimado por tráfego repetido de agentes; a coerência da sessão protege contra o site alvo sinalizar o agente como suspeito no meio do fluxo.
Isso é funcionalmente o mesmo padrão que um bot de comparação de compras usaria, sessão residencial persistente (sticky) por sessão, atribuição por cliente a um sid estável. A peculiaridade para agentes de IA é que o volume é dramaticamente maior (cada consulta do usuário que dispara uma execução de agente é uma sessão) e a duração é mais curta (a maioria dos fluxos de agente dura menos de 2 minutos).
A infraestrutura residencial precificada por banda se encaixa naturalmente nisso: execuções de agente são transações limitadas por banda, não por concorrência. Paga-se por GB que os agentes movem; a concorrência é problema do runtime do agente, não do proxy.
O que os sites alvo estão fazendo
Muito pouco, por enquanto. A maioria dos grandes sites ainda trata o tráfego de agentes de IA da mesma forma que o tráfego de scraping, mesmas regras anti-bot, mesmo bloqueio. Isso vai mudar rapidamente, em duas direções:
Sites que se beneficiam do tráfego de agentes vão acomodá-lo. Fluxos de reserva, checkout de e-commerce, compras comparativas. O agente é um usuário real sendo servido por uma camada de automação; a conversão ainda é real. Sites inteligentes estão começando a publicar endpoints amigáveis a agentes, declarações no estilo robots que dizem “trate o tráfego com este user-agent e este cabeçalho como um agente mediado por humano, não bloqueie, mas limite a taxa.”
Sites que perdem com tráfego de agentes vão se fortalecer. Qualquer coisa sustentada por anúncios tem um problema real, agentes não veem anúncios, não clicam em anúncios, não convertem anunciantes. Sites de notícias, sites de conteúdo gratuito, qualquer coisa monetizada por impressões tem incentivo para detectar e bloquear especificamente o tráfego de agentes. Essa vai ser a próxima etapa da corrida armamentista anti-bot, e será mais disputada do que o scraping foi porque a camada de agentes tem apoiadores corporativos poderosos que perdem se seus agentes forem bloqueados.
A camada de infraestrutura no meio, que somos nós e nossos pares em redes de proxies residenciais, ocupa uma posição interessante. Somos a camada de acesso que permite que agentes alcancem sites que ainda não os recebem de braços abertos. À medida que a negociação entre sites e provedores de agentes se desenrola (provavelmente por meio de uma mistura de contratos, relações de pagamento e protocolos revisados no estilo robots.txt), o papel dos provedores de infraestrutura pura vai se estreitar no caminho “permitido” e se ampliar no caminho que “precisa de diversidade em nível de IP.”
O que observar em 2026
Alguns sinais que valem a pena acompanhar se você está construindo sobre agentes:
A fração de execuções de agente que precisam de reautenticação no meio do fluxo. Hoje está próxima de zero com sessões persistentes adequadas. Se começar a subir, os sites alvo aprenderam a detectar fingerprints de agentes e estão desafiando no meio da sessão. A mitigação exige ou melhor fingerprinting de navegador do lado do agente ou estratégias de proxy diferentes.
Latência p99 em fluxos de agente de múltiplas etapas. Hoje é majoritariamente rede e tempo de resposta do site alvo. Se os gateways de proxy se tornarem um gargalo sob carga concorrente de agentes, a camada de infraestrutura precisa escalar.
Distribuição geográfica do tráfego de agentes. Hoje a maior parte do tráfego de agentes geolocaliza para onde quer que o runtime do agente esteja hospedado (majoritariamente US-East). À medida que os agentes começam a mediar transações reais de usuários (compras, reservas, operações bancárias), o tráfego precisa geolocalizar para a localização do usuário para que a lógica do site funcione corretamente. Esse é o caso otimista para a infraestrutura residencial precisa por cidade/ASN se tornar o padrão.
Declarações de sites amigáveis a agentes. Fique de olho no surgimento de um análogo de agents.txt ou de uma declaração estruturada do tipo “eu aceito tráfego de agentes com estas restrições.” Se isso acontecer, o papel da camada de proxy se estreita; se não acontecer, a camada de proxy permanece como a mediadora de acesso.
A conclusão
Agentes de IA são uma forma de tráfego nova e real. Não são scraping, não são navegação, não são recuperação RAG, compartilham características com cada um deles mas não correspondem exatamente a nenhum. A infraestrutura por baixo precisa se flexibilizar para suportar sessões persistentes por execução em uma concorrência no volume de scraping, com geografia ancorada no usuário e metas de latência que são um terço do que o scraping tolera.
A boa notícia para os provedores de infraestrutura: redes de proxies residenciais construídas corretamente já suportam exatamente essa forma. Sessões persistentes por execução de agente, IPs novos por sessão, precisão geográfica, precificação por banda que escala com o uso. As primitivas que amadureceram servindo scrapers e bots de comparação são as mesmas primitivas de que os agentes precisam.
A questão de produto para os próximos dois anos não é se o tráfego de agentes vai ser uma categoria real, ele já é. É quão bem a pilha de infraestrutura e o ecossistema de sites alvo vão convergir para termos com os quais ambos consigam conviver. Teremos um retrato mais nítido até o post de lançamento do ano que vem.