Adicionar mais subagentes Claude tornou meu pipeline mais lento — aqui está o motivo específico
Escalar de 4 para 8 subagentes Claude Code aumentou minha taxa de erro de 0,8% para 4,3%. O gargalo não era o modelo.
O culpado foi uma ferramenta MCP com estado chamada analytics_query que mantinha cursores de paginação, valores de agregação intermediários e cadeias de filtro na memória da instância entre chamadas. O Cloudflare Workers roteia cada solicitação para a instância PoP que estiver disponível — sem garantias de que você cairá na mesma duas vezes. Com 4 subagentes, colisões eram raras o suficiente para que as sessões acidentalmente permanecessem fixas. Com 8, a distribuição se espalhou e as faltas de contexto se tornaram não lineares. O erro parecia assim:
Erro: Chamada de ferramenta falhou — contexto da sessão não encontrado
session_id: "sess_7f3a9b"
worker_instance: "worker-11"
expected_instance: "worker-04"
O ID da sessão existia. O trabalhador não correspondia. O estado havia desaparecido.
Eu executei duas correções lado a lado. O armazenamento de sessão baseado em KV (serializar todo o contexto, ler no início da chamada, escrever no final da chamada) resolveu o problema de roteamento, mas criou um novo: com 8 subagentes concorrentes, as gravações de KV multiplicaram para ~16x minha estimativa. Sob carga, a latência p99 saltou de 180ms para 620ms por chamada de ferramenta, e o custo de gravação sozinho ultrapassou $150/mês no meu volume.
Objetos Duráveis resolveram isso de forma limpa. Roteie pelo ID da sessão e você sempre atinge a mesma instância DO — a afinidade da sessão é tratada no nível da plataforma, não no meu código. Com a mesma carga, o p99 caiu para 38ms. O custo mensal se estabilizou em torno de $40–60.
A troca que ninguém menciona de antemão: instâncias DO são despejadas quando inativas, e quando isso acontece, o estado em memória desaparece silenciosamente. O agente não tem ideia e continua. Esse modo de falha é mais silencioso e assustador do que os picos de latência de KV, que pelo menos aparecem nos painéis imediatamente.
O que eu cheguei após seis meses: memória DO para sessões ativas, pontos de verificação de DO Storage no final de cada chamada de ferramenta (~$10/mês a mais), e KV apenas como um índice de roteamento — leitura pesada, quase gratuita. Três camadas, mas cada uma tem um modo de falha distinto que você pode realmente isolar.
O marco de 6 subagentes foi meu ponto de inflexão. Abaixo dele, você pode não ver esse problema de forma alguma. Acima dele, a matemática de colisão de sessão se torna feia rapidamente.
Eu escrevi a análise completa — incluindo o problema de tempo de verificação (a evacuação inativa de DO é menos previsível do que os documentos sugerem) e o que acontece quando múltiplos subagentes atingem a mesma sessão simultaneamente — em riversealab.com.
O artigo discute como a escalabilidade de subagentes pode impactar a performance de sistemas baseados em MCP. Empresas brasileiras que utilizam agentes de IA devem considerar a gestão de estado e a latência em suas implementações para evitar problemas semelhantes.
