# Amazon Bedrock AgentCore: Otimização Contínua de Agentes em Produção

O Amazon Bedrock AgentCore introduz um loop de melhoria contínua que transforma traces de produção em diagnósticos acionáveis, recomendações fundamentadas em dados e validação estatística via testes A/B. Para arquitetos de sistemas financeiros e plataformas de alto risco, isso representa a primeira tentativa séria da AWS de fechar o gap entre observabilidade de agentes e operação confiável em produção.

- URL: https://fernando.moretes.com/blog/amazon-bedrock-agentcore-otimizacao-continua-de-agentes-em-producao-amazon-bedro

- Markdown: https://fernando.moretes.com/blog/amazon-bedrock-agentcore-otimizacao-continua-de-agentes-em-producao-amazon-bedro/article.md?lang=pt

- Published: 2026-06-23T12:00:00.000Z

- Category: IA & Agentes

- Tags: bedrock, agentcore, agentic-ai, observability, mlops, aws, financial-grade, a-b-testing

- Reading time: 11 min

- Source: [Amazon Bedrock AgentCore introduces new optimization capabilities to continuously improve agents in production](https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-bedrock-agentcore-new-optimization-capabilities)

---

O problema mais perigoso em sistemas agênticos não é o agente que falha com um stack trace visível — é o agente que responde com confiança, parece funcionar nos dashboards, e silenciosamente entrega respostas erradas para centenas de usuários durante semanas. O Amazon Bedrock AgentCore, com suas novas capacidades de otimização contínua anunciadas em junho de 2026, ataca diretamente esse ponto cego. Como arquiteto que passou anos desenhando sistemas financeiros onde um comportamento silenciosamente incorreto pode resultar em perdas regulatórias ou danos ao cliente, eu olho para essa feature com ceticismo técnico produtivo — e com interesse genuíno.

## O Problema em Números

- **13** — Regiões AWS com insights em preview. Failure, intent e trajectory insights disponíveis em preview em 13 regiões desde junho de 2026
- **14** — Regiões com GA para avaliação e A/B. Batch evaluations, recommendations e A/B testing em disponibilidade geral em 14 regiões
- **∞** — Runtimes suportados. Funciona com AgentCore Runtime, Lambda, EKS e ambientes não-AWS — sem lock-in de execução

## O Que é o Loop de Otimização Contínua do AgentCore

O AgentCore não é simplesmente uma camada de logging mais sofisticada. É uma tentativa de fechar o ciclo completo de MLOps para agentes: observar → diagnosticar → recomendar → validar → promover. Cada etapa tem uma contraparte técnica concreta.

**Observe** começa com a coleta de traces de produção em escala — não trace-by-trace, mas análise agregada de centenas de sessões simultaneamente. Os **Failure Insights** identificam padrões de falha recorrentes, incluindo as chamadas *silent behavioral failures*: casos onde o agente completa a tarefa aparentemente, mas o resultado está errado, incompleto ou fora do escopo esperado. Os **Intent Insights** clusterizam requisições por intenção do usuário, e os **Trajectory Insights** agrupam os caminhos que o agente percorre — revelando desvios de trajetória que nenhum dashboard de p99 latência capturaria.

**Diagnostique e Recomende** é onde o sistema vai além do observável. As recomendações geradas analisam traces e outputs de avaliação para sugerir mudanças específicas em system prompts e descrições de ferramentas. Isso é significativamente diferente de uma sugestão genérica: cada recomendação vem com uma rationale rastreável a falhas observadas em produção.

**Valide** via batch evaluation contra um dataset definido pelo time, com scores agregados de múltiplos avaliadores — e depois **confirme** via A/B testing com tráfego real dividido estatisticamente. Esse é o ponto onde a engenharia de confiança encontra a operação de agentes.

## Loop de Otimização Contínua do AgentCore

Fluxo completo desde a execução do agente em produção até a promoção validada de uma nova versão, passando por insights, recomendações e validação estatística.

### 🏃 Execution Layer — Agent Runtimes

- AgentCore Runtime managed execution (compute)
- AWS Lambda custom agent logic (compute)
- Amazon EKS containerized agents (compute)

### 📡 Observe — Trace Collection

- Production Traces sessions at scale (data)

### 🔍 Diagnose — Insights Engine

- Failure Insights silent + error patterns (ai)
- Intent Insights user intent clusters (ai)
- Trajectory Insights path grouping + outliers (ai)

### 🛠️ Recommend — Prompt & Tool Fixes

- Recommendations system prompt + tool desc (ai)

### ✅ Validate — Pre-Production Gates

- Batch Evaluation multi-evaluator scoring (ai)
- A/B Testing statistical traffic split (ai)

### 🚀 Promote — Fleet Rollout

- New Agent Version validated + promoted (compute)

### Fluxos

- runtime-agentcore -> trace-store: emite traces
- runtime-lambda -> trace-store: emite traces
- runtime-eks -> trace-store: emite traces
- trace-store -> failure-insights: análise agregada
- trace-store -> intent-insights: clustering de sessões
- trace-store -> trajectory-insights: agrupamento de caminhos
- failure-insights -> recommendations: falhas ranqueadas
- intent-insights -> recommendations: intenções observadas
- recommendations -> batch-eval: candidato a mudança
- batch-eval -> ab-test: aprovado no dataset
- ab-test -> new-version: evidência estatística

## Onde o AgentCore Realmente Brilha: O Problema das Falhas Silenciosas

Em sistemas financeiros, o conceito de *silent failure* não é novo — é o pesadelo de qualquer time de SRE. Um serviço que retorna HTTP 200 com um payload semanticamente incorreto é infinitamente mais perigoso que um que retorna 500. Com agentes de IA, esse problema se amplifica: o agente pode completar todas as tool calls, retornar uma resposta bem formatada, e ainda assim ter interpretado mal a intenção do usuário, omitido uma etapa crítica de compliance, ou gerado uma recomendação financeira fora do escopo autorizado.

O que os **Failure Insights** do AgentCore fazem de diferente é analisar padrões comportamentais em escala — centenas de sessões simultaneamente — para identificar onde o agente sistematicamente desvia do comportamento esperado, mesmo sem erros explícitos. Isso é análogo ao que fazemos com distributed tracing quando buscamos anomalias de latência em caudas de distribuição: você não encontra o problema olhando um trace de cada vez.

O ranqueamento de falhas por impacto (quantos usuários são afetados) é uma decisão de produto inteligente. Em um ambiente financeiro com SLOs definidos por segmento de cliente, isso mapeia diretamente para priorização de incidentes. Um bug que afeta 0,1% das transações de alto valor é mais crítico que um que afeta 5% das consultas de baixo risco — e o sistema precisa saber disso.

A capacidade de **Intent Insights** também merece atenção: ao clusterizar o que os usuários realmente tentam fazer versus o que o sistema foi projetado para suportar, você obtém um gap analysis contínuo do seu product-market fit agêntico. Isso é observabilidade de produto, não apenas observabilidade técnica.

## Pontos Fortes da Abordagem

- Loop fechado de MLOps para agentes: observe → diagnostique → recomende → valide → promova, tudo dentro de um único serviço gerenciado
- Detecção de falhas silenciosas comportamentais em escala de sessões — o problema mais crítico em produção que dashboards convencionais não capturam
- Recomendações rastreáveis a falhas observadas, não sugestões genéricas — cada mudança proposta tem uma rationale derivada de dados de produção reais
- A/B testing com evidência estatística antes do rollout fleet-wide — o mesmo rigor que aplicamos a feature flags em sistemas de pagamento
- Runtime-agnóstico: funciona com AgentCore Runtime, Lambda, EKS e ambientes não-AWS, o que elimina o risco de lock-in na camada de execução
- Disponibilidade geral (GA) para batch evaluation, recommendations e A/B testing em 14 regiões — não apenas preview, pronto para workloads de produção

## A/B Testing de Agentes: Engenharia de Confiança Aplicada

O A/B testing de agentes é conceitualmente mais complexo que o A/B testing de features de software tradicional, e é importante entender por quê. Em um teste A/B de UI, você mede uma métrica discreta — taxa de clique, conversão, tempo na página. Em um agente, você está medindo a qualidade de uma resposta gerada, que é inerentemente subjetiva e multidimensional: precisão factual, aderência ao escopo, qualidade de raciocínio, conformidade com políticas.

O AgentCore resolve isso com um sistema de **múltiplos avaliadores** que definem coletivamente o que "bom" significa para aquele agente específico. Isso é análogo ao que fazemos com SLOs compostos em sistemas financeiros: você não tem um único SLO de disponibilidade, você tem SLOs por tipo de transação, por segmento de cliente, por canal. A composição desses indicadores é o que define a saúde real do sistema.

O split de tráfego em produção para agentes levanta questões de engenharia que merecem atenção. Diferentemente de um split de UI, onde o estado do usuário é relativamente isolado, um agente pode manter contexto de sessão, acessar ferramentas externas com side effects, e operar em workflows multi-step. Isso significa que o design do A/B test precisa considerar: idempotência das tool calls, isolamento de contexto entre versões, e o impacto de side effects em sistemas downstream.

Para ambientes financeiros, há uma camada adicional: qualquer mudança em um agente que toma decisões de crédito, gera recomendações de investimento, ou processa transações pode ter implicações regulatórias. O A/B testing precisa ser documentado como parte do processo de change management, com rastreabilidade completa de qual versão tomou qual decisão para qual usuário — algo que o trace store do AgentCore deve suportar nativamente.

> **Limites Reais e Riscos Arquiteturais:** **1. Insights ainda em preview:** Failure, intent e trajectory insights estão em preview em 13 regiões — não em GA. Para workloads financeiros regulados, preview significa sem SLA, sem suporte de produção e sem garantias de estabilidade de API. Não construa pipelines de compliance em cima de features em preview.

**2. O loop de otimização é tão bom quanto seus avaliadores:** Batch evaluation mede candidatos contra um dataset e critérios definidos pelo time. Se seus avaliadores não cobrirem edge cases de compliance financeiro, o sistema vai aprovar mudanças que parecem boas nos testes mas falham em produção em cenários regulatórios. Garbage in, garbage out — mas agora com confiança estatística.

**3. A/B testing com side effects é perigoso sem isolamento:** Se seu agente executa tool calls com side effects reais (escreve em DynamoDB, chama APIs de pagamento, envia notificações), o split de tráfego pode criar estados inconsistentes entre versões. Você precisa de tool call idempotency keys e isolamento de contexto explícito antes de habilitar A/B testing.

**4. Recomendações automáticas de system prompt requerem revisão humana em ambientes regulados:** A rationale é derivada de dados de produção, mas a mudança proposta ainda é gerada por um modelo. Em sistemas financeiros sob BACEN, CVM ou equivalentes internacionais, mudanças em prompts que afetam decisões de crédito ou recomendações de investimento precisam de aprovação humana documentada — o AgentCore não substitui esse processo.

**5. Custo de traces em escala:** Armazenar e analisar centenas de sessões continuamente tem custo. Sem uma estratégia de sampling (ex: tail-based sampling com OpenTelemetry), o custo de observabilidade pode superar o custo de execução do agente em workloads de alto volume.

## Integração com Arquiteturas Financeiras Existentes: O Que Realmente Importa

A decisão de tornar o AgentCore runtime-agnóstico é estrategicamente correta e arquiteturalmente importante. A maioria das organizações financeiras que estão experimentando com agentes de IA não vai migrar toda a lógica de execução para um novo runtime gerenciado — elas têm agentes rodando em Lambda com lógica de negócio legada, em EKS com orquestradores customizados, ou em ambientes híbridos com restrições de soberania de dados.

Isso significa que a camada de valor do AgentCore é a de **observabilidade e otimização**, não de execução. E essa é uma posição de produto muito mais defensável a longo prazo. Você instrumenta o trace collection no seu runtime existente, e o loop de otimização funciona independentemente de onde o agente roda.

Para integração com pipelines de dados financeiros existentes, o ponto de atenção é o **modelo de dados dos traces**. Se você já tem distributed tracing com OpenTelemetry e Datadog, precisa entender como os traces do AgentCore se relacionam com seus spans existentes. A recomendação é manter o trace context propagation (W3C TraceContext) entre o AgentCore e seus sistemas downstream, para que um trace de agente possa ser correlacionado com a transação de banco de dados, a chamada de API de mercado, ou o evento de MSK que ele gerou.

Do ponto de vista de IAM, as permissões para o AgentCore acessar traces de produção e executar análises precisam seguir o princípio de least privilege com condições específicas: `bedrock:GetAgentTrace` e `bedrock:AnalyzeAgentBehavior` devem ser escopadas por `aws:ResourceTag/Environment` para garantir que o pipeline de otimização de staging não acesse traces de produção. KMS customer-managed keys para traces que contêm dados de clientes são obrigatórias em qualquer ambiente financeiro regulado.

## Como Adotar em Ambientes Financeiros: Sequência Recomendada

1. **1. Audite seu modelo de trace atual** — Antes de habilitar qualquer feature do AgentCore, mapeie o que está nos seus traces de agente hoje: eles contêm PII? Dados de transação? Conteúdo de prompts com informações sensíveis? Defina uma política de redação (redaction) e implemente-a no trace emitter antes de conectar ao AgentCore. Use KMS CMK com key policy que restrinja o acesso ao role do AgentCore via `kms:ViaService` condition.

2. **2. Comece com batch evaluation em staging** — Batch evaluation está em GA e é o bloco de construção mais seguro. Construa um dataset de avaliação representativo com casos de uso reais, incluindo edge cases de compliance (ex: tentativas de obter recomendações fora do escopo autorizado). Defina seus avaliadores com critérios explícitos e mensuráveis. Isso estabelece a baseline antes de qualquer otimização.

3. **3. Habilite Failure Insights em preview com escopo limitado** — Como está em preview, habilite apenas para um subconjunto de agentes não-críticos primeiro. Configure monitoramento de custo com AWS Budgets para o namespace de observabilidade do AgentCore. Valide que os padrões de falha identificados correspondem ao que seu time já conhece — isso calibra a confiança no sistema antes de usá-lo para descoberta.

4. **4. Implemente A/B testing com isolamento de side effects** — Antes de habilitar o split de tráfego, implemente idempotency keys em todas as tool calls que têm side effects externos. Use DynamoDB conditional writes com `attribute_not_exists(idempotency_key)` para garantir que uma ação não seja executada duas vezes se o mesmo request cair em versões diferentes durante o split. Documente o período e critérios do teste como um ADR para fins de auditoria.

5. **5. Formalize o processo de aprovação de recomendações** — Crie um processo documentado (pode ser um GitHub PR com template específico) para revisão humana de cada recomendação gerada pelo AgentCore antes de aplicá-la. Para agentes que afetam decisões financeiras, exija aprovação de um arquiteto sênior e do time de compliance. Registre a rationale original do AgentCore e a decisão humana no mesmo ADR.

## Análise pelos Pilares Well-Architected

- **security**: Traces de agente podem conter PII, dados de transação e conteúdo de prompts sensíveis. Exija KMS CMK com key policy restrita, implemente redaction no trace emitter, e escopie permissões IAM por tag de ambiente. O A/B testing com acesso a dados de produção requer controles de acesso equivalentes aos do sistema principal.
- **reliability**: O loop de otimização é um sistema auxiliar — sua falha não deve impactar a execução do agente principal. Implemente circuit breakers entre o runtime do agente e o AgentCore trace collector. O A/B testing com side effects requer idempotency keys em todas as tool calls externas para evitar ações duplicadas durante splits de tráfego.

## O Que Ainda Falta: Lacunas que Importam para Produção Séria

Apesar do progresso significativo, há lacunas que precisam ser endereçadas antes que eu recomende o AgentCore como a espinha dorsal de observabilidade de agentes em ambientes financeiros de alta criticidade.

**Ausência de integração nativa com OpenTelemetry:** O ecossistema de observabilidade moderno converge em OTel. Se o AgentCore emite traces em um formato proprietário sem exporters OTel nativos, você cria um silo de observabilidade — traces de agentes separados dos traces de infraestrutura, sem correlação automática. Para ambientes que já têm Datadog ou Grafana como plano de controle de observabilidade, isso é um problema real de operações.

**Modelo de custo ainda não totalmente documentado:** A AWS não publicou pricing detalhado para análise de insights em escala. Para um time de arquitetura tomando decisões de adoção, a ausência de números concretos de custo por sessão analisada, por recomendação gerada, ou por hora de A/B testing ativo é uma barreira para business case.

**Governança de recomendações automáticas:** O sistema gera recomendações de mudança em system prompts derivadas de dados de produção. Para organizações com processos formais de change management (ITIL, ISO 27001, SOX), não está claro como essas recomendações se encaixam no workflow de aprovação existente. Precisamos de integração com sistemas de ticketing (Jira, ServiceNow) e suporte a approval workflows antes de isso ser viável em enterprises reguladas.

**Limites de volume para análise de insights:** A documentação atual não especifica limites de sessões por análise, latência de processamento de insights, ou comportamento sob alta concorrência. Para plataformas financeiras com picos de tráfego previsíveis (abertura de mercado, vencimento de contratos), esses limites são críticos para planejamento de capacidade.

> **Minha Perspectiva Prática:** Se eu estivesse adotando isso hoje em um ambiente financeiro, começaria exclusivamente com batch evaluation em GA — é o componente mais maduro e o que oferece valor imediato sem os riscos de preview. A lição que aprendi operando sistemas de alto risco é que o maior risco não é a tecnologia nova em si, mas a confiança prematura nela: times que adotam A/B testing de agentes sem primeiro resolver idempotência de tool calls vão criar estados inconsistentes em produção que são extremamente difíceis de diagnosticar. Eu também insistiria em manter um plano de observabilidade paralelo com OTel e Datadog até que a integração nativa do AgentCore com o ecossistema de traces existente esteja documentada e testada — dois planos de observabilidade são melhor que um silo opaco. O conceito de fechar o loop de MLOps para agentes é correto e necessário; a execução está no caminho certo, mas ainda requer maturidade operacional antes de ser a âncora de um sistema regulado.

## AgentCore vs. Abordagem DIY de Observabilidade de Agentes
| Critério | Dimensão | AgentCore (Gerenciado) | DIY (OTel + Datadog + Scripts) |
| --- | --- | --- | --- |
| Detecção de falhas silenciosas | Nativo, análise de padrões em escala de sessões | Requer implementação custom de análise comportamental | — |
| Recomendações de melhoria | Geradas automaticamente com rationale rastreável | Manual, baseado em análise humana de traces | — |
| A/B testing de versões | Nativo com split de tráfego e evidência estatística | Requer feature flags customizados e análise estatística manual | — |
| Integração com ecossistema OTel | Limitada / não documentada nativamente | Total — OTel é o padrão da abordagem DIY | — |
| Custo de implementação inicial | Baixo — gerenciado pela AWS | Alto — requer engenharia de plataforma dedicada | — |
| Controle e auditabilidade | Médio — depende de APIs da AWS para acesso a dados | Alto — dados e lógica completamente sob controle do time | — |

## Referências

- [Amazon Bedrock AgentCore — What's New (Jun 2026)](https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-bedrock-agentcore-new-optimization-capabilities)
- [Amazon Bedrock AgentCore Harness — Now GA (AWS ML Blog)](https://aws.amazon.com/blogs/machine-learning/amazon-bedrock-agentcore-harness-is-now-generally-available-go-from-idea-to-production-grade-agent-in-minutes/)
- [Amazon Bedrock Guardrails — New API for Agentic AI Workflows](https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-bedrock-guardrails-api-ai/)
- [Amazon Bedrock AgentCore Documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/agentcore.html)
- [AWS Well-Architected Framework — Machine Learning Lens](https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/welcome.html)
- [OpenTelemetry — W3C TraceContext Propagation](https://opentelemetry.io/docs/specs/otel/context/api-propagators/)

## Veredicto: Promissor, Mas com Maturidade Operacional Ainda em Construção

O Amazon Bedrock AgentCore representa a abordagem mais coerente que a AWS já lançou para o problema real de operar agentes de IA em produção: não apenas executá-los, mas entender o que estão fazendo, identificar onde falham silenciosamente, e melhorá-los com rigor estatístico. O loop observe → diagnostique → recomende → valide → promova é arquiteturalmente correto e endereça o gap que todo time que opera agentes em produção sente.

Para ambientes financeiros de alta criticidade, minha recomendação é adoção em fases: **comece com batch evaluation em GA hoje** para estabelecer baselines de qualidade; **pilote Failure Insights em preview** em agentes não-críticos para calibrar confiança; **adote A/B testing apenas após resolver idempotência de tool calls e formalizar o processo de aprovação de recomendações**. Não tente fazer tudo de uma vez.

O que me impede de dar uma recomendação irrestrita é a combinação de: insights ainda em preview (sem SLA), ausência de integração OTel documentada, modelo de custo em escala não publicado, e lacunas de governança para ambientes regulados. Essas não são objeções filosóficas — são requisitos operacionais reais que precisam de respostas antes de uma adoção fleet-wide em sistemas financeiros.

Potencial: alto. Maturidade para produção financeira regulada: médio-alto para os componentes GA, médio para os componentes em preview. Acompanhe de perto — esse espaço vai evoluir rapidamente nos próximos trimestres.

**Rating:** 4/5 — GA components; 3/5 — preview compo