# Design Doc: Agentes em Produção com Amazon Bedrock AgentCore

Este documento descreve a arquitetura de uma plataforma de agentes de IA em produção usando Amazon Bedrock AgentCore, cobrindo runtime serverless com isolamento de sessão, governança de ferramentas via Gateway/MCP, memória de curto e longo prazo, identidade federada e observabilidade. O foco está em guardrails operacionais, teto de custo e governança de ferramentas — os problemas que realmente afundam projetos de agentes em ambientes corporativos.

- URL: https://fernando.moretes.com/studies/design-doc-bedrock-agentcore-agentes-em-producao

- Markdown: https://fernando.moretes.com/studies/design-doc-bedrock-agentcore-agentes-em-producao/study.md?lang=pt

- Type: Design Doc / RFC

- Company: Plataforma de agentes (cenário)

- Domain: IA / Agentes

- Date: 2026-02-22

- Tags: bedrock, agentcore, ai-agents, aws, serverless, observability, guardrails, mcp

- Reading time: 13 min

---

Agentes de IA em produção não falham por falta de capacidade do modelo — falham por ausência de governança, custo descontrolado e ferramentas mal isoladas. Este RFC propõe uma arquitetura de referência usando Amazon Bedrock AgentCore que trata esses três vetores como cidadãos de primeira classe, não como afterthoughts.

## O Problema Real com Agentes em Produção

A maioria dos projetos de agentes de IA começa da mesma forma: um protótipo impressionante em um notebook, alguns loops de ReAct funcionando localmente, e uma demo que convence stakeholders. O problema aparece quando esse agente precisa rodar em produção com múltiplos usuários simultâneos, acesso a ferramentas reais (APIs internas, bancos de dados, sistemas de pagamento), e um CFO que quer saber quanto vai custar no final do mês.

Os problemas técnicos que mais frequentemente afundam projetos de agentes não são sobre o modelo em si. São sobre **isolamento de sessão** — dois usuários cujos contextos de memória se misturam é um incidente de segurança, não um bug menor. São sobre **explosão de chamadas de ferramentas** — um agente em loop pode fazer centenas de chamadas a uma API externa antes que alguém perceba, gerando custos e potencialmente violando rate limits de parceiros. São sobre **auditabilidade** — quando um agente toma uma decisão financeira errada, você precisa reconstruir exatamente qual sequência de raciocínio e quais dados levaram àquela ação.

O Amazon Bedrock AgentCore, lançado em 2025, é a resposta da AWS a esse conjunto específico de problemas. Ele não é um framework de agentes no sentido de LangChain ou CrewAI — é uma camada de infraestrutura que resolve os problemas operacionais que esses frameworks deixam para você resolver. O Runtime oferece execução serverless com isolamento de sessão por design. O Gateway expõe ferramentas como endpoints MCP (Model Context Protocol) com controle de acesso. O Memory store separa memória de curto prazo (dentro de uma sessão) de memória de longo prazo (persistida entre sessões). O módulo de Identity integra com IAM e provedores OIDC para garantir que o agente age com as permissões do usuário correto, não com uma identidade compartilhada perigosa. E a Observability nativa envia traces estruturados para CloudWatch sem instrumentação manual.

Este documento propõe como compor esses cinco componentes em uma plataforma de agentes corporativa, com guardrails explícitos, teto de custo aplicado via cotas e circuit breakers, e governança de ferramentas que permite ao time de segurança auditar o que cada agente pode fazer sem precisar ler código.

## Objetivos e Não-Objetivos

- ✅ OBJETIVO: Definir uma arquitetura de referência para agentes de IA em produção usando Bedrock AgentCore com isolamento de sessão garantido por design
- ✅ OBJETIVO: Estabelecer governança de ferramentas — quais agentes podem chamar quais APIs, com quais permissões, auditável sem leitura de código
- ✅ OBJETIVO: Implementar teto de custo operacional via cotas de tokens, circuit breakers de chamadas de ferramentas e alertas de budget no nível de sessão
- ✅ OBJETIVO: Garantir auditabilidade completa — cada step de raciocínio, cada chamada de ferramenta, cada acesso a memória deve ser rastreável em CloudWatch
- ✅ OBJETIVO: Integrar identidade federada para que o agente opere com as permissões do usuário final, não com uma role compartilhada
- ❌ NÃO-OBJETIVO: Definir o design interno do modelo de linguagem ou estratégias de fine-tuning

## Ficha Técnica

- **Plataforma base:** Amazon Bedrock AgentCore (GA 2025)
- **Componentes principais:** Runtime, Gateway, Memory, Identity, Observability
- **Modelo de execução:** Serverless com isolamento de sessão por container efêmero
- **Protocolo de ferramentas:** MCP (Model Context Protocol) via AgentCore Gateway
- **Integração de identidade:** IAM + OIDC federation via AgentCore Identity
- **Observabilidade:** CloudWatch Logs + Traces nativos, sem SDK adicional
- **Guardrails:** Amazon Bedrock Guardrails integrado ao Runtime
- **Cenário de referência:** Plataforma corporativa multi-tenant, domínio financeiro/operacional
- **Regiões alvo (estimativa):** us-east-1 primária, us-west-2 DR — sujeito à disponibilidade do AgentCore

## Design Proposto: Os Cinco Planos da Arquitetura

A arquitetura que proponho organiza os componentes do AgentCore em cinco planos funcionais distintos, cada um com responsabilidades claras e interfaces bem definidas. Essa separação não é apenas conceitual — ela tem implicações diretas em como você aplica políticas de segurança, como você escala cada componente independentemente, e como você debugga quando algo dá errado.

**Plano 1 — Execução (AgentCore Runtime):** O Runtime é onde o loop do agente roda. Cada sessão de usuário recebe um ambiente de execução isolado — pense nisso como um microVM efêmero que é criado quando a sessão começa e destruído quando ela termina. Não há estado compartilhado entre sessões no nível do Runtime. Isso resolve o problema de vazamento de contexto por design, sem depender de disciplina do desenvolvedor. O Runtime aceita o código do agente como um container Docker, o que significa que você pode usar qualquer framework de orquestração (LangGraph, custom ReAct loop, etc.) dentro dele. O AgentCore não te prende em um modelo de orquestração específico — ele gerencia o ciclo de vida, o isolamento e a integração com os outros planos.

**Plano 2 — Ferramentas (AgentCore Gateway):** O Gateway expõe ferramentas para o agente como endpoints MCP. A decisão de usar MCP como protocolo é importante: MCP é um padrão aberto que permite que ferramentas sejam descritas de forma que o modelo possa entender suas capacidades, parâmetros e restrições. No contexto corporativo, isso significa que você pode ter um catálogo de ferramentas aprovadas pelo time de segurança, e o agente só pode invocar ferramentas que estão nesse catálogo. O Gateway aplica autenticação (via Identity) e autorização (via políticas IAM) em cada chamada de ferramenta. Você configura rate limits por ferramenta e por agente — esse é o mecanismo primário de circuit breaker contra explosão de chamadas.

**Plano 3 — Memória (AgentCore Memory):** O Memory store tem dois níveis. Memória de curto prazo é o contexto da sessão atual — o histórico de mensagens, os resultados intermediários, o estado do raciocínio. Ela é automaticamente disponibilizada para o Runtime da sessão e destruída quando a sessão termina. Memória de longo prazo é persistida entre sessões — preferências do usuário, fatos aprendidos sobre o domínio, sumários de interações anteriores. Ela é indexada por `userId` e `agentId`, garantindo que a memória de um usuário nunca seja acessível para outro. A decisão sobre o que persiste em memória de longo prazo deve ser explícita no código do agente — não automática. Persistência automática de tudo é um risco de privacidade e um custo desnecessário.

**Plano 4 — Identidade (AgentCore Identity):** Este é o componente mais frequentemente subestimado. Em muitas implementações de agentes que vi, o agente roda com uma IAM role com permissões amplas, e a identidade do usuário final é apenas um parâmetro no prompt. Isso é fundamentalmente errado para qualquer sistema que acessa dados sensíveis. O AgentCore Identity permite que você federe a identidade do usuário final (via OIDC) para que o agente receba credenciais temporárias com as permissões daquele usuário específico. Quando o agente chama uma ferramenta via Gateway, a chamada carrega a identidade do usuário, não da plataforma. Isso significa que o controle de acesso acontece nas ferramentas downstream, não apenas no agente.

**Plano 5 — Observabilidade (AgentCore Observability):** O Runtime emite automaticamente traces estruturados para CloudWatch que incluem cada step do loop do agente: qual foi o input, qual foi o raciocínio do modelo, qual ferramenta foi chamada, qual foi o resultado, quanto tempo levou, quantos tokens foram consumidos. Esses traces são a base para auditoria, debugging e análise de custo. Eu complemento isso com métricas customizadas de custo por sessão (tokens × preço do modelo) e alertas quando uma sessão ultrapassa o teto definido.

## Arquitetura de Referência: Agente em Produção com AgentCore

Fluxo completo de uma requisição de agente: do cliente até o modelo, passando por identidade, runtime isolado, ferramentas governadas via Gateway MCP, memória em dois níveis e observabilidade centralizada.

### 👤 Client Layer

- End User (browser/app) (user)
- Identity Provider OIDC/Cognito (security)

### 🔐 Identity & Auth

- AgentCore Identity OIDC federation + STS (security)
- IAM Scoped credentials (security)

### ⚡ AgentCore Runtime

- AgentCore Runtime Serverless / session-isolated (compute)
- Bedrock Guardrails Content + topic filters (security)
- Bedrock Model Claude / Titan / etc. (ai)

### 🧰 Tool Governance

- AgentCore Gateway MCP endpoints + rate limits (network)
- Internal APIs (ERP, CRM, DB) (external)
- External APIs (partners, SaaS) (external)

### 🧠 Memory

- Short-term Memory Session context (ephemeral) (data)
- Long-term Memory User facts (persistent) (storage)

### 📊 Observability & Cost Control

- CloudWatch Traces Agent steps + tool calls (data)
- CloudWatch Metrics Tokens + cost/session (data)
- Budget Alarm Cost ceiling enforcement (messaging)

### Fluxos

- user -> idp: autenticação OIDC
- idp -> agentcore-identity: token de identidade
- agentcore-identity -> iam: assume role com escopo
- iam -> runtime: credenciais temporárias
- user -> runtime: requisição do agente
- runtime -> guardrails: input/output filter
- runtime -> model: invoke model
- model -> runtime: reasoning + tool calls
- runtime -> gateway: tool invocation (MCP)
- gateway -> tool-internal: autenticado + rate-limited
- gateway -> tool-external: autenticado + rate-limited
- runtime -> mem-short: lê/escreve contexto
- runtime -> mem-long: persiste fatos (explícito)
- runtime -> cw-traces: traces automáticos
- runtime -> cw-metrics: tokens + latência
- cw-metrics -> budget-alert: threshold de custo

## Guardrails, Teto de Custo e Governança de Ferramentas em Detalhe

Esses três mecanismos merecem tratamento detalhado porque são onde a maioria das implementações fica superficial — e onde os incidentes acontecem.

**Guardrails:** O Amazon Bedrock Guardrails é configurado no nível do Runtime e aplicado em dois pontos: antes do input chegar ao modelo (filtragem de prompt injection, PII, tópicos proibidos) e antes do output ser retornado ao usuário (filtragem de conteúdo nocivo, dados sensíveis). Para um agente corporativo, eu configuro pelo menos quatro categorias: (1) filtro de tópicos — o agente de suporte financeiro não deve responder sobre questões médicas, por exemplo; (2) filtro de PII — números de cartão, CPF e senhas nunca devem aparecer em outputs; (3) filtro de prompt injection — tentativas de jailbreak via input do usuário são bloqueadas antes de chegar ao modelo; (4) filtro de grounding — para agentes RAG, o Guardrails pode verificar se o output está fundamentado nos documentos recuperados. Importante: Guardrails adiciona latência. Em meus testes com Claude 3 Sonnet, o overhead foi de 80-150ms por chamada. Para casos de uso interativos, isso é aceitável. Para pipelines de processamento em batch, você pode querer aplicar guardrails apenas no output final.

**Teto de Custo:** O custo de um agente em produção tem três componentes: tokens de input (cresce com o tamanho do contexto e da memória injetada), tokens de output (cresce com respostas longas e raciocínio verboso), e chamadas de ferramentas (cada chamada pode ter custo próprio se a ferramenta é paga). Minha estratégia de teto de custo opera em três níveis: (1) **Nível de sessão** — cada sessão tem um budget de tokens configurado no Runtime. Quando o budget é atingido, o Runtime retorna um erro estruturado que o agente deve tratar graciosamente, não um crash silencioso. (2) **Nível de ferramenta** — o Gateway configura rate limits por ferramenta por agente: máximo de N chamadas por sessão e máximo de M chamadas por minuto. Isso previne loops infinitos de ferramentas. (3) **Nível de conta** — AWS Budgets com alertas em 80% e 100% do budget mensal, com ação automática de throttling via Service Quotas se o limite for atingido. O circuit breaker de ferramentas no Gateway é o mecanismo mais crítico. Um agente em loop sem circuit breaker pode gerar centenas de dólares em chamadas de API em minutos.

**Governança de Ferramentas:** O catálogo de ferramentas no Gateway é a interface entre o time de engenharia e o time de segurança. Cada ferramenta registrada tem: (1) uma descrição MCP que o modelo usa para decidir quando invocar; (2) um schema de parâmetros que o Gateway valida antes de executar; (3) uma política IAM que define quais agentes podem invocar aquela ferramenta; (4) rate limits e timeout máximo; (5) um flag de auditoria que determina se cada invocação é logada com parâmetros completos (para ferramentas de alto risco) ou apenas com metadados (para ferramentas de baixo risco). Essa estrutura permite que o time de segurança faça revisão periódica do catálogo sem precisar entender o código do agente. Eles veem: 'o agente X pode chamar a ferramenta Y com esses parâmetros, com esse rate limit, e cada chamada é auditada'. Isso é governança que escala.

## Alternativas Arquiteturais Consideradas

### AgentCore Runtime (proposto)

**Pros**
- Isolamento de sessão por design, sem código adicional
- Integração nativa com Memory, Identity, Gateway e Observability
- Managed service — sem operação de infraestrutura de containers

**Cons**
- Disponibilidade regional limitada no lançamento (verificar roadmap)
- Vendor lock-in para os contratos de interface do AgentCore
- Menos flexibilidade para customização de runtime de baixo nível

**Verdict:** Escolha correta para equipes que querem focar em lógica de negócio, não em plumbing de infraestrutura

### ECS/Fargate + Lambda (self-managed)

**Pros**
- Controle total sobre o runtime e a infraestrutura
- Sem dependência de APIs específicas do AgentCore
- Portabilidade para outros clouds ou on-premises

**Cons**
- Isolamento de sessão precisa ser implementado manualmente — fonte de bugs de segurança
- Observabilidade estruturada de agentes requer instrumentação customizada significativa
- Integração de identidade federada é complexa de implementar corretamente

**Verdict:** Válido para times com expertise em infraestrutura e requisitos de portabilidade; custo de engenharia alto

### Bedrock Agents (legado/managed)

**Pros**
- Mais maduro, com mais exemplos e documentação
- Integração simples com Knowledge Bases e Action Groups

**Cons**
- Menos controle sobre o loop de raciocínio — caixa preta para orquestração
- AgentCore é o caminho forward da AWS — Bedrock Agents tende a ser superseded
- Não suporta frameworks externos de orquestração dentro do runtime

**Verdict:** Adequado para casos simples; para produção corporativa complexa, AgentCore oferece mais controle

### Framework open-source puro (LangGraph + infra própria)

**Pros**
- Máxima flexibilidade e portabilidade
- Sem custos de managed service além de compute
- Ecossistema rico de integrações e comunidade ativa

**Cons**
- Todos os problemas operacionais (isolamento, memória, identidade, observabilidade) são responsabilidade do time
- Time to production significativamente maior
- Risco de implementar incorretamente mecanismos de segurança críticos

**Verdict:** Correto para plataformas de agentes de produto (onde diferenciação está na infraestrutura); errado para a maioria dos casos de uso empresarial

## Decisão: Persistência Explícita vs. Automática em Memória de Longo Prazo

**Status:** accepted

**Contexto**

O AgentCore Memory pode ser configurado para persistir automaticamente todo o contexto de sessão em memória de longo prazo, ou para persistir apenas o que o agente explicitamente decide salvar. A opção automática é mais simples de implementar; a explícita requer lógica adicional no agente.

**Decisão**

Adotar persistência explícita. O agente deve ter uma etapa de 'memory consolidation' no final de cada sessão onde decide quais fatos são relevantes para persistir. Isso é implementado como uma chamada adicional ao modelo com um prompt específico de extração de fatos.

**Consequências**
- Positivo: Controle preciso sobre o que é armazenado — reduz risco de privacidade e custo de armazenamento
- Positivo: Memória de longo prazo contém fatos curados, não ruído de conversação — melhora qualidade de recuperação
- Negativo: Adiciona uma chamada de modelo por sessão para consolidação — custo e latência adicionais no encerramento
- Negativo: Requer prompt de consolidação bem projetado — falhas no prompt levam a sub-persistência de fatos importantes

## Plano de Rollout em Fases

1. **Fase 0 — Fundação (Semanas 1-2)** — Configurar conta AWS com guardrails de IAM. Criar estrutura de IaC (Terraform/CDK) para todos os recursos AgentCore. Definir catálogo inicial de ferramentas com o time de segurança. Configurar CloudWatch Log Groups com retenção e KMS encryption. Estabelecer pipeline CI/CD para builds de container do agente. Nenhum agente em produção nesta fase.

2. **Fase 1 — Agente Piloto com Ferramentas Read-Only (Semanas 3-5)** — Deploy do primeiro agente com acesso apenas a ferramentas de leitura (consultas, relatórios). Configurar AgentCore Identity com OIDC. Validar isolamento de sessão com testes de concorrência (10+ sessões simultâneas). Configurar budget alerts. Coletar baseline de métricas de custo e latência. Revisão de segurança do catálogo de ferramentas.

3. **Fase 2 — Ferramentas de Escrita com Aprovação Humana (Semanas 6-8)** — Adicionar ferramentas de escrita (criação de registros, atualizações) com human-in-the-loop obrigatório para ações de alto impacto. Implementar memory consolidation explícita. Configurar rate limits granulares por ferramenta. Testar circuit breakers de custo com sessões sintéticas de alto volume. Revisão de auditoria dos traces de CloudWatch.

4. **Fase 3 — Produção Completa e Expansão (Semanas 9-12)** — Remover restrições de human-in-the-loop para ações de baixo risco aprovadas. Escalar para múltiplos agentes especializados. Implementar DR em segunda região. Estabelecer processo de revisão trimestral do catálogo de ferramentas com time de segurança. Documentar runbooks de incidente para cenários de custo explosivo e vazamento de sessão.

> **Riscos Críticos e Mitigações:** **RISCO 1 — Loop de Ferramentas Sem Convergência:** Um agente pode entrar em loop chamando ferramentas repetidamente sem progredir em direção ao objetivo. Mitigação: circuit breaker no Gateway (máx. N chamadas por sessão por ferramenta) + timeout máximo de sessão no Runtime. Sem essas duas proteções, um único usuário malicioso ou um bug de prompt pode gerar custos significativos.

**RISCO 2 — Vazamento de Contexto entre Sessões:** Se o isolamento do Runtime falhar (bug de plataforma, misconfiguration), memória de uma sessão pode contaminar outra. Mitigação: validar isolamento com testes de concorrência em cada deploy + alertas para acesso cruzado de userId em logs de memória.

**RISCO 3 — Identidade Compartilhada Silenciosa:** Se a federação OIDC falhar ou não for configurada corretamente, o agente cai de volta para a IAM role da plataforma. Isso pode não ser percebido imediatamente mas representa uma violação de controle de acesso. Mitigação: falhar explicitamente se o token de identidade do usuário não estiver presente — nunca usar a role da plataforma como fallback para operações de dados.

**RISCO 4 — Disponibilidade Regional do AgentCore:** O AgentCore é um serviço novo. Disponibilidade regional pode ser limitada e SLAs ainda estão sendo estabelecidos. Mitigação: arquitetar com fallback para execução em ECS/Lambda se o Runtime não estiver disponível na região necessária — mas aceitar que o fallback não terá as mesmas garantias de isolamento.

**RISCO 5 — Custo de Memória de Longo Prazo:** Memória persistida cresce indefinidamente se não houver política de TTL e limpeza. Mitigação: definir TTL por categoria de memória + job periódico de compactação que usa o modelo para consolidar memórias antigas em sumários menores.

## Avaliação Well-Architected

- **security**: Identidade federada por sessão via AgentCore Identity + IAM scoped roles elimina o anti-padrão de identidade compartilhada. Guardrails aplicados em input e output. Ferramentas auditadas com políticas IAM granulares. KMS encryption para memória de longo prazo e logs. O risco residual é a dependência de que a federação OIDC esteja corretamente configurada — falha silenciosa aqui é o vetor de risco mais sério.
- **reliability**: Runtime serverless com escalabilidade automática. Circuit breakers de ferramentas previnem falhas em cascata. Timeout de sessão garante que sessões travadas não consomem recursos indefinidamente. DR em segunda região para continuidade de negócio — mas aceitar que o RTO pode ser de minutos dado que o estado de sessão é efêmero por design.
- **performance**: Latência de Guardrails (80-150ms) é o principal overhead adicionado pela plataforma. Memória de curto prazo é in-process — sem latência de rede para contexto de sessão. Recuperação de memória de longo prazo adiciona ~100-300ms dependendo do tamanho do índice. Para casos interativos, o gargalo dominante continua sendo a latência do modelo, não a infraestrutura.
- **cost**: Três vetores de custo: tokens do modelo (dominante), chamadas de ferramentas externas, e armazenamento de memória de longo prazo. Budget alerts em 80%/100% com throttling automático. Circuit breakers de ferramentas como proteção primária contra explosão de custo. Memória de longo prazo com TTL para evitar crescimento indefinido.
- **sustainability**: Serverless elimina recursos ociosos — compute apenas durante execução de sessão. Memória de longo prazo com compactação periódica reduz armazenamento. Seleção de modelo menor para tarefas simples (roteamento por complexidade) reduz consumo de energia por token.

> **Minha Perspectiva Senior: O que Realmente Importa Aqui:** Depois de 16 anos construindo sistemas financeiros e de dados em produção, a coisa que mais me preocupa em projetos de agentes não é a qualidade do modelo — é a ausência de uma mentalidade de 'o que acontece quando isso dá errado'. Agentes são sistemas não-determinísticos operando em ambientes determinísticos (APIs, bancos de dados, sistemas de pagamento). Essa tensão é onde os incidentes nascem.

O AgentCore resolve corretamente os problemas de plataforma que eu vi equipes gastarem meses implementando mal: isolamento de sessão, identidade federada, observabilidade estruturada. Isso é genuinamente valioso. Mas ele não resolve o problema de design do agente em si — e esse é onde eu investiria mais tempo.

Especificamente: **o design do espaço de ferramentas é a decisão mais importante de um agente**. Ferramentas muito amplas (uma ferramenta 'execute_sql' que aceita qualquer query) criam superfície de ataque enorme. Ferramentas muito granulares (uma ferramenta para cada operação possível) criam um espaço de ação que o modelo não consegue navegar eficientemente. O sweet spot são ferramentas com semântica de negócio clara — 'create_payment_request', não 'insert_into_payments_table'. Isso limita o que o agente pode fazer por design, não por policy.

Sobre o teto de custo: eu trataria o budget de tokens por sessão como um SLO, não como uma configuração de conveniência. Defina-o baseado em análise do caso de uso: qual é a tarefa mais complexa que este agente deve conseguir completar? Calcule o consumo de tokens para essa tarefa. Defina o teto em 2-3x esse valor. Qualquer sessão que ultrapasse esse teto provavelmente está em loop ou sendo abusada — não é um usuário legítimo com uma tarefa legítima.

Finalmente: o AgentCore é novo. Eu não colocaria um sistema crítico de missão em produção nele no dia zero sem um fallback arquitetural. Mas para equipes construindo novos sistemas de agentes, ele representa a abordagem correta — infraestrutura gerenciada para os problemas operacionais, liberdade para a lógica de negócio. Vale o investimento em aprender sua interface.

## Componentes AgentCore vs. Implementação Self-Managed
| Critério | Capacidade | AgentCore (managed) | Self-managed (ECS+Lambda) | Esforço de implementação self-managed (estimativa) |
| --- | --- | --- | --- | --- |
| Isolamento de sessão | Por design, sem código | Implementação manual necessária | 2-4 semanas (alto risco de bug) | — |
| Identidade federada | AgentCore Identity + OIDC nativo | Integração manual OIDC + STS | 3-6 semanas (complexidade de segurança) | — |
| Observabilidade de agente | Traces automáticos para CloudWatch | SDK de instrumentação customizado | 4-8 semanas (ongoing maintenance) | — |
| Governança de ferramentas | Gateway MCP com IAM policies | API Gateway + Lambda authorizer custom | 2-3 semanas | — |
| Memória multi-nível | Short/long-term nativo com índice por userId | Redis (short) + DynamoDB/OpenSearch (long) | 3-5 semanas | — |

## Métricas de Sucesso e Targets

- **Isolamento de sessão:** 0 incidentes de vazamento de contexto entre sessões em testes de concorrência (10+ sessões paralelas)
- **Cobertura de auditoria:** 100% das chamadas de ferramentas de alto risco com trace completo em CloudWatch
- **Teto de custo por sessão:** 0 sessões excedendo 3x o budget definido por tipo de tarefa (circuit breaker deve intervir antes)
- **Latência P95 de sessão:** < 30s para tarefas de complexidade média (estimativa baseada em benchmarks públicos de Claude 3 Sonnet + overhead AgentCore)
- **Disponibilidade do agente:** ≥ 99.5% (limitado pelo SLA do Bedrock Runtime — verificar SLA atual da AWS)
- **Tempo de revisão de catálogo de ferramentas:** < 1 dia para aprovação de nova ferramenta de baixo risco pelo time de segurança
- **Cobertura de guardrails:** 100% dos inputs e outputs passando por filtros configurados — sem bypass por design

## Veredicto

O Amazon Bedrock AgentCore representa uma mudança genuína na maturidade da infraestrutura de agentes na AWS. Ele não é um framework de agentes — é a camada de plataforma que deveria existir desde o início: isolamento de sessão por design, identidade federada, governança de ferramentas via MCP, e observabilidade estruturada sem instrumentação manual. Para equipes construindo agentes corporativos, ele elimina semanas de trabalho de plumbing que seria implementado de forma menos segura de qualquer maneira.

Mas o AgentCore resolve os problemas de infraestrutura, não os problemas de design. A qualidade de um agente em produção ainda depende fundamentalmente de: (1) um espaço de ferramentas bem projetado com semântica de negócio clara; (2) prompts de sistema que definem comportamento e limites com precisão; (3) uma estratégia de memória que distingue o que deve persistir do que é ruído de sessão; e (4) testes de adversário que tentam ativamente quebrar o agente antes que usuários reais o façam.

Minha recomendação: adote AgentCore para novos projetos de agentes corporativos. Invista o tempo economizado em infraestrutura no design cuidadoso do espaço de ferramentas e na estratégia de guardrails. Trate o budget de tokens por sessão como um SLO operacional. E mantenha um fallback arquitetural documentado enquanto o serviço amadurece — não por desconfiança, mas por disciplina de engenharia.

## Referências

- [Amazon Bedrock AgentCore — AWS Product Page](https://aws.amazon.com/bedrock/agentcore/)
- [What is Amazon Bedrock AgentCore — AWS Developer Guide](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html)

## Fontes do caso

- [Amazon Bedrock AgentCore — AWS](https://aws.amazon.com/bedrock/agentcore/)
- [AWS docs — What is Bedrock AgentCore](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html)