Um agente autônomo pode saber exatamente o que fazer e ainda assim ser lento demais para alguém esperar. O problema não está apenas na velocidade com que um modelo de linguagem gera tokens. Está no número de vezes que ele precisa pensar, consultar uma ferramenta, observar o resultado e decidir o próximo passo.

Esse é o custo oculto da latência em agentes autônomos: uma tarefa teoricamente possível se transforma em uma sequência de esperas. Quando cada etapa leva pouco tempo, o atraso parece aceitável. Quando há muitas etapas dependentes, a soma muda a experiência inteira.

Em geral, em fluxos sequenciais, a latência de parede, o tempo que uma pessoa realmente espera, tende a crescer com as dependências entre etapas, embora cache, sobreposição e variações de execução possam alterar o resultado. A velocidade por token importa, mas não conta a história toda.

O agente já está pagando por cada decisão

Imagine um sistema encarregado de analisar uma solicitação, buscar informações, consultar um banco de dados, comparar resultados, executar uma ação e verificar se tudo funcionou. Mesmo que cada operação seja rápida, o agente não consegue iniciar algumas delas antes de conhecer a resposta da anterior.

Várias etapas com latência semelhante podem produzir uma espera longa quando executadas em sequência. Se uma etapa falha e exige uma tentativa adicional, o relógio continua correndo. Se a decisão final depende de uma ferramenta lenta, toda a cadeia herda esse atraso.

Essa diferença separa duas métricas que costumam ser misturadas. A latência de token mede quanto tempo o sistema leva para produzir cada fragmento de saída. A latência de parede mede o intervalo entre o pedido e uma resposta utilizável. Um modelo pode gerar tokens rapidamente e, ainda assim, entregar uma tarefa devagar porque passa mais tempo esperando ferramentas, redes, bancos de dados ou novas chamadas de inferência.

Há também um detalhe menos visível. O agente frequentemente produz texto que não será mostrado ao usuário. São instruções intermediárias, argumentos para ferramentas, interpretações de resultados e verificações. Esse trabalho pode ser necessário, mas cada rodada acrescenta custo computacional e tempo.

O que já acontece hoje é uma tensão entre autonomia e espera. Quanto mais passos o sistema executa sozinho, maior a chance de concluir tarefas complexas sem intervenção humana. Mas também cresce a superfície onde uma falha ou uma demora pode se acumular.

A cadeia sequencial é o verdadeiro gargalo

O erro de projeto mais comum é tratar uma tarefa de vários passos como se custasse apenas proporcionalmente mais do que uma única resposta. Em custo, essa aproximação pode ser útil. Em tempo, ela é incompleta, porque algumas etapas são sequenciais e outras poderiam ocorrer em paralelo.

Considere várias buscas independentes. Se o agente espera o resultado de uma para iniciar a seguinte, depois outra e então mais uma, o tempo total se aproxima da soma das latências. Se as buscas realmente não dependem umas das outras, elas podem ser disparadas juntas. O tempo passa a se aproximar da operação mais lenta, acrescida do custo de coordenação.

Essa mudança parece pequena no diagrama e enorme na prática. O sistema deixa de pensar como uma fila e passa a pensar como um grafo de dependências. A pergunta deixa de ser apenas “quantas etapas existem?” e passa a ser “quais etapas precisam esperar umas pelas outras?”.

O princípio arquitetural geral é que o paralelismo reduz latência quando as tarefas são independentes. Ele não elimina o custo. Disparar operações simultâneas aumenta consumo de recursos, pode sobrecarregar serviços externos e torna a coordenação mais delicada. Uma resposta mais rápida pode custar mais e exigir mecanismos melhores de cancelamento, limite e recuperação.

Os atalhos que quebram a espera

A primeira estratégia é paralelizar tudo o que puder ser separado com segurança. A segunda é reduzir o número de decisões intermediárias. Em vez de pedir ao agente que escolha uma ferramenta, aguarde, interprete e escolha outra em cada movimento, o sistema pode oferecer operações mais completas, capazes de executar uma parte maior do trabalho de uma vez.

Esse desenho é conhecido como aumento da granularidade das ferramentas. Uma função que retorna um resultado final costuma exigir menos idas e vindas do que várias funções minúsculas. O trade-off é importante: ferramentas grandes são mais rápidas em alguns fluxos, mas menos flexíveis e potencialmente mais difíceis de validar.

Outra opção é trocar raciocínio em tempo de execução por preparação anterior. Rotas comuns, consultas frequentes e decisões previsíveis podem ser pré-calculadas ou armazenadas em cache. O agente deixa de descobrir o caminho do zero a cada pedido.

Também é possível usar modelos diferentes para funções diferentes. Um modelo menor pode classificar a solicitação ou escolher entre ferramentas, enquanto um modelo mais capaz entra apenas quando há ambiguidade. Essa arquitetura pode reduzir custo e latência, mas cria outro problema: o roteador precisa saber quando sua própria confiança é insuficiente.

A técnica de streaming melhora a percepção sem necessariamente diminuir o tempo total. Mostrar progresso, resultados parciais ou uma explicação inicial faz a espera parecer menor. Isso é útil, mas não deve ser confundido com aceleração real. Um sistema que começa a falar cedo pode continuar sem resposta confiável por vários segundos.

O que provavelmente acontece a seguir

Uma possibilidade é que a autonomia passe a ser delimitada por orçamentos, em vez de ser maximizada em qualquer tarefa. É possível que muitos agentes adotem limites explícitos de tempo, número de chamadas, custo e risco. Ao atingir um desses limites, eles poderão simplificar, pedir confirmação ou devolver um resultado parcial.

Essa direção parece plausível porque transforma uma propriedade difícil de controlar, o tempo total, em uma regra de produto mensurável. Em vez de perguntar se o agente “consegue” realizar uma tarefa, será necessário perguntar se ele consegue realizá-la dentro de um orçamento aceitável.

Um cenário favorável seria uma combinação de planejamento curto, execução paralela, ferramentas de maior granularidade e modelos especializados por etapa. Nesse cenário hipotético, agentes funcionariam bem em tarefas com estrutura conhecida e grau de risco controlado.

Há um segundo cenário, menos confortável. Os sistemas podem continuar tecnicamente capazes, mas serem usados apenas quando a espera for barata. Uma pessoa tolera uma análise demorada quando ela acontece em segundo plano, mas não para uma ação que interrompe o trabalho. A latência passaria a selecionar os casos de uso, não apenas a influenciar a experiência.

Minha especulação é que a consequência de segunda ordem será uma nova divisão entre tarefas síncronas e assíncronas. Algumas atividades seriam entregues imediatamente, com agentes pequenos e rotas previsíveis. Outras seriam delegadas como processos de fundo, acompanhados por notificações e checkpoints humanos. O agente não pareceria sempre um assistente conversando. Em muitos casos, pareceria mais com uma fila de trabalho que sabe quando pedir ajuda.

O número que vale medir antes do entusiasmo

Para projetar um agente realista, não basta medir tokens por segundo. Registre o tempo total, o número de rodadas de inferência, as chamadas de ferramenta, as etapas bloqueantes, as operações paralelas e a taxa de repetição após falhas.

Depois, defina um orçamento por tarefa. Quanto tempo o usuário aceita esperar? Quanto custa uma execução? Em que ponto uma resposta parcial é melhor do que continuar tentando? Essas perguntas obrigam a arquitetura a lidar com o mundo real, onde latência, custo e confiabilidade competem pelo mesmo recurso.

O teste mais honesto não é perguntar se o agente consegue terminar. É observar quantas vezes ele termina dentro do tempo em que alguém ainda se importa com a resposta. A autonomia útil começa exatamente nesse limite: não quando a máquina pode fazer tudo, mas quando ela sabe quanto tempo pode gastar.