Uma chamada de LLM tem uma carga operacional relativamente pequena. A aplicação envia um prompt, aguarda a resposta e usa o resultado ou tenta novamente. A maior parte do estado e do tratamento de falhas ainda fica no código ao redor do modelo, não na chamada em si.
Em um workflow agêntico, a dinâmica muda. Em vez de uma única requisição e resposta, o modelo avalia o que fazer, chama uma ferramenta, lê o resultado e decide o próximo passo. Às vezes repete esse processo várias vezes antes de chegar a uma resposta final. Cada etapa pode falhar de forma independente e precisa registrar o que já aconteceu.
Muitas equipes não se preparam para essa transição. Criam um protótipo baseado em uma API, tudo funciona, até alguém perguntar: ele também pode consultar o banco de dados, chamar outras duas APIs e lembrar o que aconteceu na última interação? É nesse momento que um chatbot deixa de ser apenas uma demonstração e se torna um problema de sistemas distribuídos.
Este guia explica o que muda na infraestrutura ao passar de chamadas isoladas de LLM para workflows agênticos e como projetar essa arquitetura para produção.
O que muda quando um workflow se torna agêntico
Um workflow agêntico geralmente adiciona requisitos que uma chamada isolada não tem:
- Estado entre etapas: o agente precisa saber o que já fez e quais resultados recebeu antes de decidir a próxima ação.
- Orquestração em múltiplas etapas: em vez de uma única requisição e resposta, há um loop que avalia, age, observa e repete até atingir uma condição de parada.
- Chamadas de ferramentas e acesso a dados: o agente consulta APIs, bancos de dados ou vector stores durante a execução, e cada chamada é um novo ponto de falha.
- Execuções mais longas: um workflow pode durar segundos ou minutos e atravessar várias requisições, em vez de terminar após uma única chamada.
Aplicações distribuídas lidam com esses problemas há anos, independentemente de AI: onde manter o estado, como reduzir a latência entre serviços e como responder quando uma etapa falha. A AI agêntica adiciona um LLM como mais um componente dessa cadeia.
Por que protótipos de agentes falham em produção
Um protótipo que chama apenas um endpoint de modelo pode parecer rápido. Mas a latência começa a se acumular quando o agente chama o modelo, depois uma ferramenta, volta ao modelo e consulta um banco de dados, especialmente se cada etapa precisar acessar uma região centralizada.
O contexto da sessão, o histórico da conversa e os resultados intermediários frequentemente acabam espalhados entre variáveis globais, caches locais ou componentes improvisados. Em alguns casos, nem chegam a ser persistidos, fazendo o agente perder o contexto entre chamadas.
Executar inferência de forma confiável e em escala também exige provisionar, escalar e monitorar capacidade de GPU, criando um segundo projeto para equipes que deveriam estar concentradas na aplicação. Ao mesmo tempo, consultas de RAG, recuperação de memória e dados da aplicação costumam ficar em serviços diferentes, com perfis de latência distintos. No fim, todo o workflow opera na velocidade de sua etapa mais lenta.
Esses problemas raramente aparecem em uma demonstração com um único usuário e sem carga. Eles surgem quando o workflow começa a receber tráfego real.
As cinco camadas de infraestrutura de um workflow agêntico
Um agente em produção normalmente depende de cinco camadas:
- Orquestração: o fluxo de controle que decide o próximo passo, como chamar o modelo, executar uma ferramenta, consultar a memória ou encerrar o workflow.
- Inferência: as chamadas aos modelos, incluindo chat completions, embeddings e reranking.
- Estado de trabalho: dados temporários usados entre as etapas, como o turno atual da conversa, contadores, flags e resultados intermediários.
- Memória persistente e semântica: dados estruturados de maior duração e contexto pesquisável por vetores, usados em recuperação de informações e RAG.
- Políticas e controle de acesso: regras que determinam o que o agente pode fazer, quais ferramentas pode chamar e com quais permissões.
Problemas em produção costumam surgir nas fronteiras entre essas camadas: estado desatualizado, recuperação lenta, falhas em tool calls, permissões ausentes ou loops de orquestração que nunca atingem uma condição de parada.
Como essas camadas funcionam na Azion
Na Azion Platform, essas camadas podem operar no mesmo modelo distribuído, sem exigir cinco sistemas gerenciados separadamente.
Azion Functions executa a orquestração: o loop que determina o próximo passo do agente. As etapas são processadas dentro de uma única invocação, sem cold start, e a chamada seguinte também não precisa pagar um novo custo de inicialização.
Azion AI Inference executa a camada de modelos. O serviço oferece suporte a LLMs, VLMs, embeddings, reranking e workflows agênticos por meio de uma API compatível com OpenAI, com escalabilidade automática desde a primeira requisição até os picos de tráfego, sem que a equipe precise provisionar clusters de GPU.
Azion KV Store mantém o estado de trabalho, incluindo contexto da sessão, contadores, flags e resultados intermediários que o loop precisa acessar entre etapas, com baixa latência perto da execução das Functions.
Azion SQL Database armazena a memória persistente e semântica. Com busca vetorial baseada em SQLite e libSQL, consultas de RAG e memória de longo prazo podem usar a mesma camada de dados da aplicação. Réplicas globais de leitura mantêm essas consultas mais próximas dos usuários.
Políticas e controle de acesso ficam na camada de orquestração. A próxima seção detalha como isso funciona na prática. Manter orquestração, inferência e estado na mesma plataforma distribuída reduz a latência adicional e o esforço operacional de coordenar serviços gerenciados separadamente.
Exemplo de loop para um agente de AI
O pseudocódigo abaixo representa um loop simplificado em uma Azion Function. O endpoint, o ID do modelo e os métodos do KV Store são ilustrativos; consulte a documentação atual da Azion antes de usar o exemplo em produção.
Detalhes de carregamento de secrets, novas tentativas e tratamento completo de erros foram omitidos para deixar o fluxo de controle mais claro.
// Pseudocódigo ilustrativo. O endpoint, o ID do modelo e os métodos do// KV Store são placeholders. Consulte a documentação para a sintaxe atual.export default async function handler(request) { const { sessionId, message } = await request.json();
// Histórico da conversa: persiste entre interações. const history = JSON.parse((await KV.get(`session:${sessionId}`)) || "[]"); history.push({ role: "user", content: message });
// Memória semântica: recuperada a cada interação por busca vetorial. const memory = await queryVectorMemory(message);
// Mensagens de trabalho: histórico e contexto recuperado para esta execução. // As tool calls ficam em `messages`, mas não são salvas em `history`, evitando // que a memória persistente cresça com cada etapa intermediária. const messages = [{ role: "system", content: memory }, ...history];
const MAX_STEPS = 4; let finalMessage = null;
for (let step = 0; step < MAX_STEPS; step++) { const completion = await fetch( "https://<seu-endpoint-de-ai-inference>/v1/chat/completions", { method: "POST", headers: { "Content-Type": "application/json", Authorization: `Bearer ${AI_INFERENCE_TOKEN}`, }, body: JSON.stringify({ model: "<id-do-seu-modelo>", messages, tools: [checkOrderStatusTool, searchDocsTool], }), } ).then((response) => response.json());
const assistantMessage = completion.choices[0].message; messages.push(assistantMessage);
if (!assistantMessage.tool_calls?.length) { finalMessage = assistantMessage; break; }
// Tool calls retornadas na mesma mensagem podem ser executadas em paralelo. const results = await Promise.all( assistantMessage.tool_calls.map((call) => runAuthorizedTool(call, sessionId) ) );
assistantMessage.tool_calls.forEach((call, index) => { messages.push({ role: "tool", tool_call_id: call.id, content: typeof results[index] === "string" ? results[index] : JSON.stringify(results[index]), }); }); }
// Se o agente atingir o limite de etapas, encerra com segurança. if (!finalMessage) { finalMessage = { role: "assistant", content: "Não foi possível concluir a solicitação. Tente novamente.", }; }
history.push(finalMessage); await KV.put(`session:${sessionId}`, JSON.stringify(history), { ttl: 3600 });
return new Response(JSON.stringify(finalMessage));}O loop continua chamando o modelo até receber uma mensagem sem novas tool calls ou atingir o limite de etapas, evitando que o agente execute indefinidamente. A função runAuthorizedTool não serve apenas para encaminhar a chamada: é nela que as permissões devem ser verificadas antes da execução.
Manter o histórico da sessão, a memória recuperada e os resultados das ferramentas na mesma arquitetura distribuída reduz o overhead de rede e I/O entre as etapas. Isso não torna quatro chamadas ao modelo tão rápidas quanto uma, mas evita que o acesso ao estado se torne outro gargalo do workflow.
Permissões de ferramentas e controles em tempo de requisição
Proteção de entrada e autorização de tool calls resolvem problemas diferentes. Azion Firewall e seu Rules Engine, junto com o módulo Web Application Firewall (WAF), inspecionam as requisições antes que elas cheguem ao agente, mas não controlam automaticamente as ferramentas que ele chama durante a execução.
Esses controles pertencem à camada de orquestração. Os argumentos, as permissões do usuário e os limites de execução devem ser validados antes de cada ação, como representado por runAuthorizedTool no exemplo. Uma decisão incorreta dentro de um workflow pode acionar uma ação real, por isso cada tool call precisa de limites explícitos.
Próximo passo: veja como Azion Functions, AI Inference, KV Store e SQL Database funcionam em conjunto em workflows agênticos na documentação da Azion ou fale com um especialista sobre como levar um agente do protótipo à produção.
Perguntas frequentes
Qual é a diferença entre uma chamada de LLM e um workflow agêntico? Uma chamada de LLM envia um prompt e recebe uma resposta em uma única interação. Um workflow agêntico executa um loop no qual o modelo decide uma ação, chama uma ferramenta ou consulta dados, analisa o resultado e decide novamente até atingir uma condição de parada. Esse loop exige estado, orquestração em múltiplas etapas e tratamento de diferentes pontos de falha.
Quais tipos de estado um workflow agêntico precisa gerenciar? No mínimo, histórico da conversa, memória de trabalho, resultados de tool calls, estado persistente da aplicação e memória semântica. Histórico e memória de trabalho normalmente podem usar um armazenamento key-value; estado persistente e memória semântica costumam exigir um banco de dados com busca vetorial.
Por que um agente de AI precisa de uma camada de dados dedicada para memória? Cada acesso adicional pela rede acrescenta latência, e um agente pode realizar várias dessas operações durante uma única interação. Manter o estado de trabalho e a memória persistente próximos da orquestração evita acumular round trips até um serviço centralizado em cada etapa.
É necessário gerenciar infraestrutura de GPU para executar workflows agênticos? Não quando a camada de inferência oferece escalabilidade gerenciada. Azion AI Inference executa LLMs, VLMs, embeddings, reranking e workflows agênticos por meio de uma API compatível com OpenAI, sem exigir que a equipe provisione ou monitore clusters de GPU diretamente.
Um firewall impede que um agente execute ações inseguras? Um WAF e um rules engine protegem a requisição de entrada que aciona a aplicação. Eles não controlam automaticamente as tool calls executadas pelo agente. A validação dos argumentos e das permissões deve ser aplicada no código de orquestração antes de cada ação.
Posso usar essa arquitetura com um cliente compatível com a API da OpenAI? Sim. Azion AI Inference oferece uma API compatível com OpenAI. Em geral, um cliente existente precisa apenas da alteração da URL base e das credenciais, sem exigir que toda a integração seja reescrita.
