Otimizando agentes em produção com o Amazon Bedrock AgentCore Observability

Da prototipagem à produção: o desafio muda de forma

Quando um agente de Inteligência Artificial (IA) sai do ambiente de prototipagem e vai para produção, o tipo de problema que surge muda completamente. No início, o esforço é fazer o agente funcionar. Em produção, o desafio passa a ser mantê-lo rápido, estável e econômico.

A AWS publicou a segunda parte de sua série sobre depuração e otimização de agentes com o AgentCore Observability, recurso do Amazon Bedrock AgentCore. Enquanto a Parte 1 tratou de agentes quebrados — com loops infinitos e erros de invocação de ferramentas —, esta edição foca em agentes que funcionam corretamente, mas que apresentam problemas de performance: respostas lentas e crescimento descontrolado de memória em sessões longas.

Esses problemas são insidiosos: não disparam alertas de erro, mas corroem a confiança do usuário e aumentam custos ao longo do tempo. O artigo da AWS demonstra como usar o AgentCore Observability em conjunto com o Amazon CloudWatch para diagnosticar e corrigir esses cenários de forma sistemática.

Cenário 3: Gargalos de desempenho

Um agente com gargalo de desempenho é aquele que completa suas tarefas corretamente, mas demora demais para responder. O que é “demais” depende do contexto: 5 segundos podem ser aceitáveis para um processo em lote, mas inviáveis para um chatbot de atendimento ao cliente.

O padrão típico de degradação é gradual: o agente começa com 2 segundos de resposta, mas à medida que novas ferramentas são integradas e mais memória é acumulada, a latência sobe para 5, depois 10 segundos, até se tornar inutilizável. A taxa de erros permanece baixa — o que dificulta a detecção por alertas tradicionais.

Como identificar o gargalo

O primeiro passo é identificar as requisições com alta latência. Para isso, o artigo sugere consultar o CloudWatch buscando invocações do agente que ultrapassem o orçamento de desempenho definido para o seu caso de uso:

fields @timestamp, RequestId, Latency
| filter Operation like /InvokeAgent/
| filter Latency > 3000
| sort Latency desc
| limit 50

Essa consulta retorna as invocações que levaram mais de 3 segundos, ordenadas por latência. A partir de um RequestId representativo, é possível analisar a linha do tempo da requisição para entender onde o tempo está sendo gasto:

fields @timestamp, Operation, Duration, SpanName
| filter RequestId = "<RequestId>"
| sort @timestamp asc

Operações que consomem tempo de forma desproporcional são os principais suspeitos: recuperação de memória, invocação de ferramentas, geração de tokens e operações sequenciais que poderiam rodar em paralelo.

Para verificar especificamente a latência de recuperação de memória:

fields @timestamp, MemoryRetrievalLatency, MemoryNamespace
| filter RequestId = "<RequestId>"
| stats avg(MemoryRetrievalLatency), max(MemoryRetrievalLatency) by MemoryNamespace

A recuperação de memória deve ser concluída em menos de 200 milissegundos. Valores acima disso indicam organização ineficiente da memória. Para identificar ferramentas lentas:

fields @timestamp, ToolName, ToolLatency
| filter RequestId = "<RequestId>"
| sort ToolLatency desc

Causas raiz e como corrigir

O artigo da AWS aponta três causas principais de gargalos de desempenho:

• Execução lenta de ferramentas: ferramentas externas que demoram segundos para responder por conta de falta de otimização, sobrecarga ou latência de rede. O efeito se amplifica com chamadas sequenciais — uma ferramenta de 2 segundos chamada três vezes resulta em 6 segundos de espera.
• Geração excessiva de tokens: Modelos de Fundação (FM — Foundation Models) geram tokens de forma sequencial. Uma resposta de 500 tokens demora 5 vezes mais do que uma de 100 tokens, impactando latência e custo.
• Processamento sequencial: executar operações independentes uma após a outra, em vez de em paralelo, aumenta desnecessariamente o tempo total de resposta.

As correções recomendadas incluem: implementar cache, connection pooling e indexação adequada de banco de dados para ferramentas lentas; substituir grandes namespaces únicos por partições temáticas (preferências, histórico, conhecimento de domínio) para reduzir o espaço de busca na memória; otimizar prompts para respostas mais diretas e concisas; e paralelizar chamadas de ferramentas independentes. Chamadas sequenciais que somam 4,5 segundos (2s + 1,5s + 1s) caem para apenas 2 segundos quando paralelizadas — uma redução de 50% ou mais com esforço mínimo.

A imagem acima ilustra uma linha do tempo de rastreamento OpenTelemetry com 17 spans distribuídos em três operações sequenciais de execute_event_loop_cycle. As ferramentas customer_lookup e order_history são executadas uma após a outra, com cada ciclo aguardando o anterior terminar — padrão que compõe a latência a cada invocação de ferramenta.

Cenário 4: Problemas de memória em sessões longas

Agentes que mantêm sessões prolongadas — como assistentes de atendimento ao cliente, pesquisa ou monitoramento — acumulam contexto ao longo do tempo. Sem uma estratégia de gerenciamento de memória adequada, esse crescimento se torna ilimitado: o agente atinge limites de tokens, perde contexto importante ou esgota a memória disponível, resultando em falhas inesperadas de sessão.

Sintomas a observar

Os sinais de alerta incluem: sessões anormalmente longas, uso de tokens crescendo linearmente com a duração da sessão, latência de recuperação de memória aumentando progressivamente e sessões encerrando com erros de memória esgotada ou janela de contexto excedida.

O exemplo acima mostra os detalhes de sessão do agente memorygrowth_Agent: 6 traces, 15,7 mil tokens consumidos e latência média de 3.757 ms por trace em uma única sessão. O uso de tokens cresce a cada invocação sucessiva, demonstrando acumulação ilimitada de contexto — padrão que em sessões de horas leva ao esgotamento da janela de contexto e falhas inesperadas.

Como diagnosticar

Para identificar sessões longas com alto uso de memória, o artigo sugere a seguinte consulta no CloudWatch:

fields @timestamp, SessionId, SessionDuration, MemorySize, TokenUsage
| filter SessionDuration > 3600
| sort MemorySize desc
| limit 20

Essa consulta retorna sessões com mais de uma hora de duração, ordenadas pelo tamanho da memória. A partir de um SessionId com uso anormalmente alto, é possível examinar os padrões de extração de memória para verificar se a consolidação está ocorrendo:

fields @timestamp, MemoryExtractionStatus, MemoryExtractionLatency, MemoriesExtracted
| filter SessionId = "<SessionId>"
| sort @timestamp asc

A extração de memória deve ocorrer regularmente ao longo da sessão. Lacunas prolongadas sem extração indicam que o agente não está consolidando memórias adequadamente. Para verificar falhas de extração:

fields @timestamp, ErrorMessage, MemoryExtractionStatus
| filter SessionId = "<SessionId>"
| filter MemoryExtractionStatus = "Failed"

Falhas na extração de memória impedem o agente de consolidar contexto, causando crescimento ilimitado. As causas mais comuns incluem: limite de tokens excedido durante a sumarização, formatos de memória inválidos, timeouts de rede ao gravar no armazenamento de memória e erros de permissão que bloqueiam atualizações.

Para analisar a organização dos namespaces de memória:

fields @timestamp, MemoryNamespace, MemoryCount, MemorySize
| filter SessionId = "<SessionId>"
| stats sum(MemoryCount) as TotalMemories, sum(MemorySize) as TotalSize by MemoryNamespace
| sort TotalSize desc

Um único namespace com milhares de memórias é um sinal claro de que o agente precisa de melhor organização de memória.

Como corrigir

Para resolver problemas de memória, a AWS recomenda verificar se as estratégias de memória incluem uma configuração de consolidação, para que o AgentCore Memory mescle e sumarize registros ao longo do tempo em vez de acumulá-los indefinidamente. Também é importante organizar registros usando templates de namespace nas definições de estratégia, garantindo que a recuperação fique restrita ao contexto relevante. O parâmetro eventExpiryDuration controla por quanto tempo os eventos brutos persistem (entre 7 e 365 dias). Para mais detalhes, a AWS disponibiliza documentação sobre como o AgentCore Memory funciona e sobre a implementação do AgentCore Memory.

Boas práticas para produção

Além dos cenários de diagnóstico, o artigo da AWS apresenta um conjunto de boas práticas para evitar esses problemas antes que ocorram.

Instrumentação abrangente

Ative a instrumentação completa para agentes em produção, sistemas de memória e gateways. Configure logs do CloudWatch, métricas do CloudWatch e rastreamentos OpenTelemetry. Não espere que usuários reportem problemas — configure alarmes para métricas críticas com os seguintes limites sugeridos: taxa de erros acima de 5%, latência no percentil 95 (P95) acima de 3 segundos e uso de tokens por sessão.

Dashboards operacionais

A AWS recomenda criar um dashboard principal com: total de invocações nas últimas 24 horas, taxa de erros atual comparada ao baseline, latências P50/P95/P99, tendências de uso de tokens e contagem de sessões ativas. Dashboards por agente devem mostrar padrões de invocação específicos, distribuição de uso de ferramentas, tendências de consumo de memória, distribuição de tipos de erro e custo por sessão. Revisar esses dashboards diariamente ajuda a identificar tendências antes que se tornem problemas.

Avaliação contínua com AgentCore Evaluators e Insights

Para monitorar a precisão das ferramentas em escala, a AWS oferece o AgentCore Evaluators, que inspeciona sessões de agentes em tempo real e as pontua com base em critérios de qualidade predefinidos — sem necessidade de revisão manual de traces após falhas. O AgentCore Insights (preview) complementa os Evaluators com análise de triagem, extração de intenção do usuário e resumo de execução.

Limpeza de recursos

Após testar as técnicas de otimização, a AWS orienta remover os recursos criados para evitar cobranças desnecessárias. Para recursos do CloudWatch, exclua dashboards de teste, remova alarmes criados para fins de teste e considere arquivar ou excluir grupos de logs antigos. Para recursos do AgentCore, exclua agentes de teste pelo console do AgentCore, remova namespaces de memória de teste e delete integrações de ferramentas temporárias.

Para excluir grupos de logs do CloudWatch via CLI:

aws logs delete-log-group --log-group-name /aws/bedrock-agentcore/your-agent-name

Para remover alarmes do CloudWatch:

aws cloudwatch delete-alarms --alarm-names your-alarm-name

Também vale revisar as configurações de retenção de logs do CloudWatch e considerar o uso do CloudWatch Logs Data Protection para reduzir custos de armazenamento de logs mais antigos.

Próximos passos

O artigo da AWS recomenda ativar o AgentCore Observability para agentes em produção como primeiro passo — essa configuração única fornece a base para todo o diagnóstico descrito. Em seguida, configurar alarmes no CloudWatch para métricas críticas, criar runbooks de troubleshooting documentando as consultas utilizadas, os limites que indicam problemas e as correções aplicadas.

A prática deliberada em ambientes não produtivos também é sugerida: introduzir falhas intencionalmente e praticar o diagnóstico usando os fluxos de trabalho apresentados, construindo familiaridade com as ferramentas antes de precisar delas em produção. Para mais informações, a documentação do AgentCore está disponível na documentação oficial do AgentCore e o Guia do Usuário do CloudWatch traz boas práticas adicionais de monitoramento.

Fonte

Optimizing production agents with Amazon Bedrock AgentCore Observability (https://aws.amazon.com/blogs/machine-learning/optimizing-production-agents-with-amazon-bedrock-agentcore-observability/)