Seu agente está lento, e talvez não seja o modelo. Agentes colocam um novo tipo de carga no caminho do dado

Quando um agente parece lento, o time costuma culpar o modelo e sair atrás de um mais rápido. Muitas vezes o modelo é um terço do problema. O resto está no caminho entre o agente e os dados de que ele precisa: buscas vetoriais, consultas a banco, chamadas de API, cada uma repetida várias vezes por tarefa. O Google tocou nesse ponto, quase de passagem, no anúncio de infraestrutura de 5 de outubro, e ele merece mais atenção do que as especificações de instância que vieram junto.

O que o Google disse

No post do Google Cloud Modernize, de Souvik Choudhury e Tom Nikl, o Google escreveu que, “com o avanço de agentes de IA em tempo real consultando sistemas de backend”, as cargas passam a exigir infraestrutura de alto throughput que elimine gargalos de I/O. E posicionou duas famílias de máquinas com muito armazenamento local para esse tráfego: a Z4D, já em GA, com até 84.000 GiB de SSD NVMe local e rede de 400 Gbps, e a Z4M, em Preview, com até 168.000 GiB de NVMe local, 400 Gbps e suporte a RDMA. O objetivo declarado é reduzir espera de I/O e evitar timeouts quando agentes consultam vector stores, bancos operacionais e pipelines de dados.

Você não precisa dessas máquinas para aproveitar a lição. Agentes criam um padrão de acesso diferente daquele para o qual suas plataformas de dados foram desenhadas.

Anatomia de uma tarefa de agente

1. Modelo planeja as etapas
2. Busca vetorial por contexto
3. Consulta ao banco operacional
4. Modelo raciocina sobre o resultado
5. Chamada de API para agir ou checar
6. Modelo escreve a resposta

Tempo de modeloTempo no caminho do dado

Uma pessoa usando um sistema faz uma consulta, lê o resultado e decide o próximo passo. Um agente pode fazer dezenas de leituras para concluir uma tarefa, muitas em paralelo, sem pausa entre elas. Daí vêm três efeitos:

• A latência se acumula. Seis etapas em sequência a 300 milissegundos cada dão quase dois segundos antes de qualquer tempo de modelo. Uma etapa lenta em 1% das vezes deixa a tarefa inteira lenta com muito mais frequência, porque cada tarefa passa por muitas etapas.
• A concorrência se multiplica. Mil colaboradores com um agente cada podem gerar a carga de consultas de uma base de usuários muito maior. Pools de conexão, capacidade de leitura e rate limits dimensionados para tráfego humano são os primeiros a acabar.
• Timeout vira resposta errada. Quando uma busca estoura o tempo, muitos agentes não falham; seguem com menos contexto e respondem mesmo assim. Um problema no caminho do dado aparece como problema de qualidade.

O custo de cada salto entre regiões

No Brasil, há um agravante. Muitos modelos de fronteira e serviços de agentes ainda não estão disponíveis nas regiões de São Paulo, enquanto os dados, por LGPD e por contrato, ficam aqui. Resultado comum: o modelo responde nos Estados Unidos, o banco e o índice vetorial estão em São Paulo, e cada etapa da tarefa atravessa o continente. Uma ida e volta entre São Paulo e a costa leste americana costuma passar de 100 milissegundos; numa tarefa com dez etapas de dados, isso vira mais de um segundo só de distância. Quando a custódia exige os dados no Brasil, leve para cá o que for possível (o índice, os caches, o estado do agente) e reduza o número de idas e vindas por tarefa.

Desenhe para o tráfego de agentes

Rastreie cada etapa. Instrumente o agente para que cada chamada de modelo, busca, consulta e API apareça como um span com latência própria. Sem isso, você otimiza o modelo enquanto o banco espera. Defendemos o mesmo para qualidade ao falar de medir a busca como um sistema à parte.

Dê aos agentes uma pista própria. Mande as leituras de agentes para réplicas, caches ou bases de leitura específicas, e não para o banco transacional principal. Dê às identidades de agentes rate limits e pools de conexão próprios, para que uma frota ocupada não derrube o checkout.

Orce latência por etapa. Defina uma meta para cada tipo de etapa e alerte quando ela estourar, como num SLO. Decida o que o agente faz quando uma etapa não cumpre o orçamento: tentar de novo, degradar, ou parar e dizer isso. Nunca seguir calado com contexto faltando.

Trate o estado do agente como dado quente. Memória e estado de sessão são lidos a cada turno. Como descrevemos no guia sobre memória de agente como armazenamento de dados, esse armazenamento precisa de governança; precisa também de planejamento de desempenho.

O que fazer agora

1. Rastreie um agente de produção de ponta a ponta e compare tempo de modelo com tempo no caminho do dado.
2. Separe as leituras de agentes do tráfego transacional, com réplicas, caches ou bases de leitura.
3. Dê às identidades de agentes rate limits e pools próprios.
4. Conte os saltos entre regiões por tarefa e traga para São Paulo o que a custódia já exige que fique aqui.
5. Defina o comportamento em timeout, para que falta de contexto vire falha explícita, não resposta pior.
6. Confira a disponibilidade regional antes de planejar com instâncias novas como a Z4M, que está em Preview.

Para fechar

Modelos mais rápidos vão continuar chegando, e não vão resolver um agente que espera um banco congestionado. Trate o caminho do dado como parte da arquitetura do agente: meça por etapa, dê ao tráfego de agentes uma pista própria e torne os timeouts visíveis, em vez de deixá-los baixar a qualidade das respostas em silêncio.