Como executar infraestrutura agêntica em produção

Infraestrutura de AI agêntica é a camada de execução, orquestração, dados, segurança e observabilidade necessária para rodar agentes de AI de forma confiável em produção. Diferente de aplicações tradicionais baseadas em requisições, agentes precisam de estado persistente, execução durável, acesso controlado a ferramentas, limites de custo de inferência e tracing por etapa.

Este post cobre o lado da execução do stack. Para o modelo completo de camadas e o vocabulário, comece por Entendendo a infraestrutura de AI agêntica.

De que infraestrutura os agentes de AI precisam em produção?

Três propriedades mudam quando um agente sai do protótipo.

Sessões substituem requisições. Um objetivo do usuário vira uma cadeia de chamadas de modelo, chamadas de ferramentas e decisões. A unidade de trabalho é medida em etapas, não em milissegundos.

A memória de trabalho vira infraestrutura. O agente precisa do objetivo, do histórico de etapas e dos resultados intermediários disponíveis ao longo dessas etapas. Em um notebook, isso vive em uma variável Python. Em produção, precisa de um lugar durável.

O volume de inferência é gerado, não recebido. Uma requisição de entrada pode produzir trinta chamadas de modelo. Planejamento de capacidade baseado em taxa de requisições deixa de prever qualquer coisa útil.

Tudo abaixo decorre desses três pontos. Este post cobre as camadas que decidem se um agente sobrevive ao primeiro dia ruim: execução, inferência e observabilidade.

Por que serverless tradicional não basta para agentes de AI de longa duração

Compute com escopo de requisição parte de três premissas que as sessões de agentes violam: o trabalho termina rápido, o trabalho é stateless e o trabalho produz uma resposta.

Pesquisas sobre serverless com estado formalizam a mesma limitação: modelos convencionais de function-as-a-service não persistem o progresso da execução entre invocações (Burckhardt et al., OOPSLA 2021).

Execução durável adiciona workflows, persistência de estado e mecanismos de recuperação, de modo que um processo pode pausar, retomar e sobreviver a falhas de infraestrutura. Essas capacidades se tornam essenciais quando um agente opera ao longo de várias etapas em vez de concluir o trabalho dentro de uma única requisição.

As falhas concretas seguem um padrão:

• Timeout no meio do loop. O limite da função expira na etapa nove. As etapas de um a oito já geraram efeitos colaterais. Não há registro de onde retomar.
• Perda da memória de trabalho no retry. O retry começa do objetivo original sem memória do que já tentou, então repete as mesmas chamadas de ferramentas e o mesmo gasto.
• Nenhum ponto de pausa para aprovação. Um agente que precisa esperar por uma pessoa não tem onde estacionar. Times contornam isso com polling, o que queima inferência em verificações que não mudam nada.

A concorrência piora o quadro. A gestão de estado costuma ser a primeira coisa a degradar conforme a escala aumenta, e logs de comunicação entre agentes frequentemente não existem — o que torna incidentes multiagente os mais difíceis de reconstruir.

Como funciona a execução durável em infraestrutura agêntica

O padrão que resolve isso separa o loop das etapas.

O controlador do loop é dono da sessão: qual é o objetivo, qual etapa vem a seguir, o que já aconteceu e quanto orçamento resta. Ele não guarda lógica de negócio e não faz raciocínio.

As etapas são execuções stateless comuns. Uma etapa recebe entrada explícita, chama um modelo ou uma ferramenta, retorna um resultado e encerra. Ela não sabe nada sobre a sessão.

Entre cada etapa, o controlador escreve um checkpoint. Um checkpoint guarda o objetivo, o histórico ordenado de etapas com resultados, o gasto acumulado de tokens e a próxima ação planejada. A recuperação vira uma leitura: carregue o último checkpoint e retome a partir da próxima etapa.

Isso garante três propriedades:

• Retomada: uma sessão que caiu reinicia na etapa nove, não na etapa um.
• Pausabilidade: esperar por aprovação humana é um checkpoint que não avança, então nada consome compute enquanto espera.
• Idempotência: dê a cada chamada de ferramenta com efeito colateral uma chave derivada do ID da sessão e do índice da etapa, e uma etapa reexecutada reutiliza o resultado original em vez de criar um segundo registro ou enviar um segundo pagamento.

Guarde checkpoints em um key-value store de baixa latência, não em um banco relacional. O padrão de acesso é uma leitura e uma escrita por etapa, com chave no ID da sessão, e a escrita está no caminho crítico de toda etapa que o agente executa.

Isolando código escrito pelo agente

Execução em sandbox se aplica no momento em que um agente gera código, e não apenas chama ferramentas predefinidas. Esse código chega não confiável em dobro: o modelo o escreveu, e uma prompt injection pode ter moldado o que o modelo escreveu.

Trate uma etapa de código gerado como entrada hostil com privilégios de execução. Três fronteiras carregam a maior parte do peso:

• Isolamento de processo por sessão, para que o código gerado por um agente não consiga ler a memória ou os checkpoints de outra sessão.
• Nenhuma credencial ambiente. Passe o token específico de que a etapa precisa como entrada explícita. Uma variável de ambiente herdada por código gerado vira o que o código decidir fazer com ela.
• Controle de egress. Código gerado que alcança hosts arbitrários pode exfiltrar o que recebeu. Restrinja os destinos de saída aos que a tarefa exige.

As mesmas fronteiras valem para chamadas de ferramentas que executam shell ou avaliam expressões. Qualquer etapa que transforma saída do modelo em execução pertence a esse perímetro.

Como controlar os custos de inferência de agentes de AI

A origem mais comum de picos inesperados de custo em produção são loops de raciocínio sem limite. Nada no caminho da requisição limita quantas vezes um agente decide pensar de novo.

Quatro controles resolvem a maior parte.

Tetos rígidos de etapas e tokens. Toda sessão recebe um número máximo de etapas e um orçamento máximo de tokens. Atingir qualquer um dos dois encerra a sessão e escala o caso. Trate-os como limites, não como metas. Uma sessão que vive batendo neles sinaliza uma tarefa que o agente não consegue concluir.

Encerramento por falta de progresso. Acompanhe se cada etapa alterou o estado da sessão. Três etapas consecutivas que não produzem informação nova normalmente significam que o agente está repetindo o mesmo raciocínio. Pare ali, em vez de esperar o teto.

Escalonamento de modelos. Roteamento, classificação e extração raramente precisam do maior modelo disponível. Reserve o modelo caro para as etapas de raciocínio e rode as etapas mecânicas em um menor. Em uma sessão de catorze etapas, isso costuma mover a maioria das chamadas para o tier mais barato.

Cache de retrieval. Agentes buscam o mesmo contexto repetidamente dentro de uma sessão. Faça cache dos resultados de retrieval por sessão e por consulta, e as chamadas redundantes desaparecem.

A economia merece atenção agora, não depois. A McKinsey projeta custos de infraestrutura de TI subindo de duas a três vezes até 2030, com orçamentos ainda restritos. Uma pesquisa da PwC reforça a pressão criada pela adoção de agentes: 88% dos executivos disseram que suas organizações planejavam aumentar os orçamentos relacionados a AI por causa da AI agêntica, e mais de um quarto esperava aumentos de 26% ou mais.

À medida que agentes transformam um único objetivo em múltiplas chamadas de modelo e de ferramentas, controlar o volume de inferência vira um requisito de infraestrutura, não uma otimização posterior.

Observabilidade para caminhos de raciocínio e chamadas de ferramentas

O caminho de decisão de um agente não é inspecionável como uma pilha de chamadas de função. O log mostra a ação; a cadeia que a produziu normalmente não fica registrada. Chamadas de ferramentas que não emitem telemetria viram pontos cegos onde a análise de causa raiz para.

Resolva isso no ponto de emissão. Trate a sessão como um trace e cada etapa como um span, e registre por span:

• ID da sessão, índice da etapa e etapa pai
• Nome do modelo e versão do prompt ou do template
• Contagem de tokens de entrada e de saída
• Nome da ferramenta, um hash dos argumentos e o status do resultado
• Latência, separada entre inferência e execução da ferramenta
• O motivo de encerramento quando a sessão termina

Hashes de argumentos, em vez dos argumentos crus, mantêm valores sensíveis fora da telemetria e ainda permitem identificar uma etapa repetindo uma chamada idêntica.

Dois sinais derivados pertencem a qualquer dashboard. Etapas por sessão mostram desvio de comportamento muito antes do custo — um agente que fazia em média seis etapas na semana passada e faz onze nesta mudou, mesmo que a conta ainda não tenha acompanhado. Tokens por objetivo concluído é a métrica unitária que importa, porque sessões que falham tarde são as caras.

Exporte esses traces para o mesmo fluxo da telemetria da aplicação. Incidentes de agentes raramente ficam contidos no agente.

Benefícios de colocalizar inferência, lógica e dados

A latência dentro de um loop de agente se acumula. Uma etapa que chama retrieval e depois inferência paga as duas idas e voltas, e a sessão paga essa soma uma vez por etapa. Catorze etapas a 700 ms de overhead combinado de rede e inferência dão cerca de dez segundos antes de qualquer trabalho real ser contabilizado.

Colocalizar a chamada de modelo, a lógica de ferramentas e o store de retrieval na mesma plataforma distribuída ataca o multiplicador, não apenas um termo isolado.

• Menor overhead por etapa, que se multiplica ao longo da sessão em vez de somar uma única vez.
• Gasto previsível, porque telemetria de tokens, orçamentos e a execução que os aplica ficam no mesmo lugar.
• Resposta a incidentes mais rápida, já que os traces cobrem raciocínio, chamadas de ferramentas e resultados sem costurar dados entre provedores.
• Menos saltos entre regiões, o que elimina uma classe de falha parcial em sessões de múltiplas etapas.

Infraestrutura agêntica em produção comparada ao serverless tradicional

Dimensão	Serverless tradicional	Camada de execução de agentes
Duração	Milissegundos a segundos	Segundos a horas
Estado	Externalizado, muitas vezes ausente	Checkpoint a cada etapa
Semântica de retry	Reexecuta a invocação inteira	Retoma do último checkpoint
Efeitos colaterais	Normalmente idempotentes por design	Exigem chaves de idempotência explícitas
Driver de custo	Número de invocações	Gasto de tokens por objetivo
Sinal de falha	Taxa de erro e latência	Trace de raciocínio e motivo de encerramento
Gatilho de escala	Taxa de requisições	Sessões concorrentes

São abordagens complementares, não concorrentes. A maioria dos desenhos em produção usa orquestração durável para a sessão e execução rápida com escopo de requisição para as etapas individuais dentro dela. O controlador é de longa duração; as etapas seguem curtas, stateless e baratas.

O erro que vale evitar é rodar o loop inteiro dentro de um único processo de longa duração. Isso reintroduz os problemas que o checkpoint resolveu: uma queda perde a sessão, e nada consegue pausar para aprovação.

Arquiteturas de referência e casos de uso reais

Três formatos cobrem a maior parte das implantações em produção.

Assistente síncrono. Uma pessoa espera pela resposta. A sessão é curta, o orçamento de etapas é apertado e a latência domina cada decisão de design. Colocalizar retrieval e inferência importa mais aqui. Limite as etapas de forma agressiva e degrade para uma resposta parcial em vez de deixar o usuário esperando.

Agente em background. O trabalho é submetido e o resultado chega depois. As sessões duram minutos a horas, o checkpoint carrega o peso e portões de aprovação são práticos porque nada fica bloqueado esperando resposta. A maioria dos agentes operacionais e de processamento de dados se encaixa aqui.

Agente de verificação orientado a eventos. Um fluxo de itens chega, o agente avalia cada um contra um modelo e os casos correspondentes são escalados. Throughput e custo por item dominam; as sessões são curtas, mas contínuas. A Axur, cliente da Azion, roda esse padrão para detecção de abuso de marca. A empresa reduziu o tempo entre detecção e pedido de takedown para cinco minutos, automatizando mais de 30.000 takedowns por mês e adicionando 450 milhões de novos sites à verificação a cada mês.

Como a Azion executa infraestrutura agêntica em produção

A Azion roda execução, inferência e dados em uma única plataforma distribuída. Para cargas de trabalho de agentes, isso significa que o overhead por etapa descrito acima não se acumula entre fronteiras de serviço.

AI Inference roda LLMs, VLMs, embeddings, reranking e modelos multimodais com escala serverless, de modo que a capacidade de inferência acompanha a concorrência de sessões sem provisionar clusters de GPU. A API compatível com OpenAI permite que frameworks de agentes existentes se conectem trocando base URL e credenciais, sem reescrita.

Functions roda a lógica das etapas perto da chamada de inferência, mantendo baixo o overhead por etapa justamente onde ele se multiplica.

KV Store guarda checkpoints de sessão e memória de trabalho, atendendo ao padrão de acesso de uma leitura e uma escrita por etapa que o checkpoint cria.

SQL Database oferece busca vetorial para retrieval, então o contexto de RAG vem da mesma plataforma que serve o modelo.

Object Storage mantém artefatos maiores que um agente produz ou consome, sem empurrá-los pelo checkpoint.

LoRA Fine-Tune adapta um modelo a um domínio sem retreinamento completo, o que reduz o número de etapas de que os agentes precisam para chegar a uma resposta correta em material especializado.

Real-Time Events dá visibilidade em nível de requisição para investigação, e Data Stream exporta traces para a ferramenta de observabilidade que o time já usa.

Conclusão e próximos passos para infraestrutura agêntica em produção

Executar infraestrutura agêntica em produção exige três coisas: fazer checkpoint de cada etapa, para que uma falha custe uma etapa e não uma sessão; limitar o loop, para que o custo continue sendo uma linha previsível; e traçar o raciocínio, para que um agente que se comporte mal deixe evidência.

Times que acertam isso param de tratar cada agente como um sistema sob medida. Os controles vivem na plataforma. Colocar o próximo agente no ar vira uma questão de definir objetivo, ferramentas e orçamento.

O próximo post desta série cobre a segurança da infraestrutura agêntica: identidade por agente, escopos de menor privilégio e a superfície de ataque das chamadas de ferramentas.

Leia a documentação de AI Inference para ver como inferência distribuída e escala serverless se encaixam em uma camada de execução de agentes.