# Agentes de IA por Dentro (3/3): Agentes em Produção na AWS com Bedrock AgentCore

A terceira e última parte da série desce o elevador até o andar técnico: como colocar um agente de IA em produção na AWS usando o Amazon Bedrock AgentCore. Cobrimos o mapa completo dos componentes (Runtime, Gateway, Memory, Identity, Observability), a escolha de modelo por custo/latência/raciocínio, segurança com guardrails e isolamento de sessão, e FinOps para manter o custo real abaixo de poucos dólares por mês.

- URL: https://fernando.moretes.com/studies/agentes-de-ia-por-dentro-3-em-producao-na-aws

- Markdown: https://fernando.moretes.com/studies/agentes-de-ia-por-dentro-3-em-producao-na-aws/study.md?lang=pt

- Type: Guia / Deep Dive

- Domain: IA / Agentes

- Date: 2026-06-26

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

- Reading time: 10 min

---

Nas partes 1 e 2 desta série você aprendeu o que é um agente de IA e como ele raciocina em loops. Agora é hora de colocar isso em produção — com código real, infraestrutura real e conta real na AWS. O Amazon Bedrock AgentCore é o conjunto de peças que a AWS lançou em 2025 para resolver exatamente os problemas que aparecem quando você sai do notebook e vai para produção: isolamento entre sessões de usuários, credenciais seguras para ferramentas externas, memória que persiste entre conversas, rastreabilidade de cada decisão do agente, e custo controlado em modelo pay-per-use. Se você vem do mundo de microsserviços ou plataformas de dados, vai reconhecer os padrões — só que aplicados a um runtime de agente. Este documento é o andar técnico do elevador: saímos do 'por que agentes' e entramos no 'como rodar isso de forma séria'.

## O que você vai aprender

- O mapa completo do Amazon Bedrock AgentCore: Runtime, Gateway (MCP), Memory, Identity, Observability, Browser e Code Interpreter
- Quando usar Bedrock Agents vs AgentCore vs frameworks como Strands ou LangGraph — e como eles se compõem
- Como o Web Search / MCP mantém o agente atualizado com fatos recentes (e por que isso é o mecanismo que mantém este próprio site atualizado)
- Seleção de modelo no Bedrock: raciocínio × custo × latência e o impacto no TCO real
- Deploy serverless event-driven, guardrails de segurança, isolamento de sessão e FinOps para manter custos abaixo de poucos dólares/mês

## Glossário Rápido — Termos que Aparecem Nesta Aula

- **AgentCore:** Conjunto de serviços gerenciados da AWS (lançado em 2025) que fornece os blocos de infraestrutura para rodar agentes em produção: runtime, memória, identidade, observabilidade e ferramentas.
- **Runtime (AgentCore Runtime):** Ambiente de execução serverless que roda o loop do agente. Cada sessão de usuário é isolada — pense em um container efêmero que nasce, executa e morre por sessão.
- **MCP (Model Context Protocol):** Protocolo aberto (Anthropic, 2024) que padroniza como um modelo de linguagem chama ferramentas externas. É o 'USB-C dos agentes': um conector universal entre o LLM e qualquer ferramenta.
- **Gateway (AgentCore Gateway):** Componente que expõe ferramentas (APIs, funções Lambda, serviços externos) para o agente via MCP. É o 'API Gateway' do mundo de agentes.
- **Guardrails:** Filtros configuráveis no Bedrock que bloqueiam conteúdo indesejado (tópicos proibidos, PII, alucinações) antes que a resposta chegue ao usuário. É o 'WAF do LLM'.
- **TCO (Total Cost of Ownership):** Custo total de manter um sistema rodando: não só a fatura de tokens do LLM, mas também compute, armazenamento, chamadas de ferramentas e operação.
- **Strands Agents:** Framework open-source da AWS para construir agentes em Python, com integração nativa ao Bedrock AgentCore. Pense nele como o 'CDK dos agentes': abstração de alto nível sobre a infraestrutura.
- **LangGraph:** Framework da LangChain para orquestrar agentes como grafos de estado. Mais flexível e mais complexo que Strands; indicado quando o fluxo de raciocínio é altamente customizado.

## O Mapa do AgentCore: Seis Peças que Resolvem Seis Problemas Reais

Quando você coloca um agente em produção pela primeira vez, seis problemas aparecem quase simultaneamente. Primeiro: **onde o loop roda?** Você não quer gerenciar servidores para algo que pode ficar ocioso 99% do tempo. Segundo: **como o agente chama ferramentas externas de forma padronizada?** Cada API tem seu próprio esquema; sem um protocolo comum, você escreve glue code para sempre. Terceiro: **como o agente lembra do que aconteceu?** LLMs são stateless por natureza — cada chamada começa do zero. Quarto: **como o agente obtém credenciais para ferramentas sem que você coloque secrets no prompt?** Quinto: **como você sabe o que o agente decidiu e por quê?** Sem rastreabilidade, depurar um agente é como depurar um programa sem logs. Sexto: **como o agente acessa informações que não estavam no seu treinamento?**

O AgentCore resolve cada um desses problemas com um componente dedicado: **Runtime** (onde o loop roda, serverless, isolado por sessão), **Gateway** (protocolo MCP para ferramentas), **Memory** (curto e longo prazo gerenciados), **Identity** (credenciais de ferramentas sem secrets no código), **Observability** (traces, métricas e avaliação), e as ferramentas gerenciadas **Browser** e **Code Interpreter** (para navegar na web e executar código de forma segura). Cada peça pode ser usada independentemente — você não precisa adotar tudo de uma vez.

## Diagrama 1 — Mapa de Capacidades do Amazon Bedrock AgentCore

Visão estática dos componentes do AgentCore e como eles se relacionam. Leia da esquerda (usuário) para a direita (ferramentas externas), passando pelo núcleo de execução.

### 👤 Client Layer

- User / App client (user)
- Strands / LangGraph or custom SDK (frontend)

### ⚙️ AgentCore Runtime

- AgentCore Runtime serverless, isolated session (compute)
- AgentCore Memory short-term + long-term (data)
- AgentCore Identity tool credentials / OAuth (security)

### 🤖 Model Layer (Bedrock)

- Bedrock Model Claude / Nova / Llama (ai)
- Bedrock Guardrails content + PII filter (security)

### 🔌 Gateway & Tools

- AgentCore Gateway MCP server / tool registry (network)
- Managed Browser web navigation tool (compute)
- Code Interpreter sandboxed execution (compute)
- Web Search grounding / freshness (external)

### 📊 Observability

- AgentCore Observability traces + evals (data)
- CloudWatch metrics / logs (data)

### 🌐 External Systems

- External APIs CRM, ERP, DBs (external)
- Lambda Functions custom tools (compute)

### Fluxos

- user -> sdk: invoca
- sdk -> runtime: sessão
- runtime -> llm: prompt + contexto
- llm -> guardrails: resposta filtrada
- guardrails -> runtime: resposta segura
- runtime -> memory: lê/escreve estado
- runtime -> identity: solicita credencial
- runtime -> gateway: tool call (MCP)
- gateway -> browser: navega web
- gateway -> codeint: executa código
- gateway -> websearch: busca atual
- gateway -> lambda: tool handler
- lambda -> extapi: integra sistema
- runtime -> obs: traces / spans
- obs -> cw: métricas

## Bedrock Agents vs AgentCore vs Frameworks: Quando Usar Cada Um

Esta é a pergunta que mais confunde quem chega ao ecossistema AWS de agentes. Existem três camadas e elas **se compõem**, não se excluem.

**Bedrock Agents** é o serviço de alto nível, totalmente gerenciado, com interface no console. Você define um prompt de sistema, associa um modelo, conecta bases de conhecimento (RAG) e action groups (ferramentas). É o caminho mais rápido para um agente funcional — pense nele como o 'Amplify dos agentes': produtivo para casos comuns, menos flexível para casos avançados.

**AgentCore** é a camada de infraestrutura. Ele não orquestra o agente — ele fornece os blocos que qualquer orquestrador precisa: runtime isolado, memória gerenciada, gateway de ferramentas, identidade e observabilidade. Você usa AgentCore quando precisa de controle fino sobre o loop de raciocínio ou quando está construindo um sistema multi-agente.

**Strands Agents** é um framework Python open-source da AWS que usa o AgentCore como backend. É a abstração de código sobre a infraestrutura — você escreve `@tool` em Python e o Strands cuida do loop ReAct, da chamada ao Bedrock e da integração com AgentCore. **LangGraph** é uma alternativa mais flexível e mais complexa, ideal quando o grafo de estados do agente é não-linear ou quando você precisa de controle explícito sobre cada transição de estado.

A regra prática: comece com Bedrock Agents para provas de conceito. Migre para Strands + AgentCore quando precisar de isolamento de sessão, memória persistente ou ferramentas customizadas. Use LangGraph quando o fluxo de raciocínio for um grafo complexo que o Strands não consegue expressar.

## Bedrock Agents × AgentCore + Strands × LangGraph — Quando Usar Cada Um
| Critério | Critério | Bedrock Agents | AgentCore + Strands | AgentCore + LangGraph |
| --- | --- | --- | --- | --- |
| Curva de aprendizado | Baixa — console UI | Média — Python SDK | Alta — grafos de estado | — |
| Controle do loop | Gerenciado pela AWS | Controlado via decoradores | Controle total por grafo | — |
| Isolamento de sessão | Básico | Nativo (AgentCore Runtime) | Nativo (AgentCore Runtime) | — |
| Multi-agente | Limitado | Suportado | Nativo (grafo de agentes) | — |
| Ferramentas via MCP | Parcial (action groups) | Nativo (AgentCore Gateway) | Nativo (AgentCore Gateway) | — |
| Melhor para | PoC, RAG simples, chatbots | Produção, ferramentas customizadas | Fluxos complexos, orquestração avançada | — |

## Web Search e MCP: Como o Agente Sabe o que Aconteceu Hoje

Todo modelo de linguagem tem uma **data de corte de treinamento** — um ponto no tempo após o qual ele não sabe o que aconteceu. É como contratar um consultor brilhante que passou os últimos 18 meses em um retiro sem internet: ele sabe tudo que aprendeu antes, mas não sabe o que saiu ontem. Para um agente de produção, isso é um problema sério: preços, regulações, notícias, documentação de APIs — tudo muda.

A solução é **grounding por busca**: em vez de depender apenas do conhecimento do modelo, o agente usa uma ferramenta de busca para recuperar informação atual antes de responder. O **AgentCore Web Search** expõe essa capacidade como uma ferramenta MCP — o agente decide quando buscar, formula a query, recebe os resultados e os incorpora ao contexto antes de gerar a resposta final. É exatamente o mesmo mecanismo que um humano usa quando abre o Google no meio de uma conversa.

Este site — o portfólio de arquitetura que você está lendo agora — usa esse mesmo mecanismo para se manter atualizado. Quando um agente gera ou revisa um documento de arquitetura, ele usa Web Search via MCP para verificar se há novos serviços, mudanças de preço ou atualizações de documentação que invalidariam o conteúdo. É um **meta-exemplo real**: o mecanismo que estamos descrevendo é o mecanismo que mantém este documento relevante.

Do ponto de vista de segurança, Web Search via AgentCore tem uma vantagem sobre chamar APIs de busca diretamente: as credenciais da API de busca ficam no **AgentCore Identity**, não no código do agente. O runtime injeta o token no momento da chamada — o modelo nunca vê a chave.

## Diagrama 2 — Fluxo de Uma Sessão de Agente: Request → Runtime → Tools → Resposta

Fluxo temporal de uma única sessão. Leia de cima para baixo. As setas tracejadas são spans de observabilidade capturados em paralelo.

### 👤 User

- User Request 'What is the current Selic rate?' (user)

### ⚙️ AgentCore Runtime (isolated session)

- Session Init load short-term memory (compute)
- ReAct Step 1 Thought: need current data (ai)
- Tool Decision Action: web_search(query) (ai)
- ReAct Step 2 Observation: search result (ai)
- Final Answer write to memory + respond (compute)

### 🤖 Bedrock Model

- Claude 3.5 Sonnet reasoning + tool_use (ai)
- Guardrails PII + topic filter (security)

### 🔌 Tools via AgentCore Gateway (MCP)

- Web Search Tool AgentCore Web Search (external)
- Memory Store short + long term (data)

### 📊 Observability (parallel)

- Trace Span session_id + step + latency (data)
- Eval Hook groundedness score (data)

### Fluxos

- u1 -> r1: inicia sessão
- r1 -> mem1: carrega contexto
- r1 -> r2: prompt montado
- r2 -> llm1: invoca modelo
- llm1 -> r3: tool_use: web_search
- r3 -> ws1: MCP call
- ws1 -> r4: resultado atual
- r4 -> llm1: observation no prompt
- llm1 -> gr1: resposta final
- gr1 -> r5: resposta filtrada
- r5 -> mem1: persiste resumo
- r5 -> u1: entrega resposta
- r2 -> obs1: span step 1
- r4 -> obs1: span step 2
- r5 -> eval1: avalia groundedness

## Seleção de Modelo, FinOps e o Custo Real de um Agente em Produção

A escolha do modelo é a decisão de maior impacto no TCO de um agente. No Bedrock, você tem um espectro que vai de modelos leves e baratos (Amazon Nova Micro, ~$0.035/1M tokens de entrada) até modelos de raciocínio pesado (Claude 3.7 Sonnet com extended thinking, ~$3/1M tokens de entrada). A diferença de custo é de duas ordens de grandeza — e num agente com múltiplos passos ReAct, você paga por cada chamada ao modelo.

A regra que uso na prática: **use o modelo mais barato que resolve o problema**. Para classificação, extração de dados estruturados e respostas simples, Nova Micro ou Haiku são suficientes. Para raciocínio multi-passo com ferramentas, Claude 3.5 Sonnet é o ponto ótimo de custo/qualidade. Para problemas que exigem raciocínio profundo (planejamento financeiro complexo, análise jurídica), Claude 3.7 com extended thinking vale o custo extra.

Na prática, um agente de suporte ao cliente com 1.000 sessões/mês, média de 5 passos ReAct por sessão e contexto de 2.000 tokens por passo fica abaixo de **$5/mês** usando Haiku — e abaixo de **$50/mês** usando Sonnet. O custo ocioso é zero porque o AgentCore Runtime é serverless: você paga apenas pelo tempo de execução real. Isso é radicalmente diferente de manter um servidor de agente rodando 24/7.

O segundo vetor de custo são as **chamadas de ferramentas**: cada invocação de Lambda, cada query ao DynamoDB (para memória), cada chamada de Web Search tem um custo. O AgentCore Observability te dá a visibilidade para identificar quais ferramentas são chamadas com mais frequência e otimizar — por exemplo, colocando um cache na frente de buscas repetidas.

## Segurança em Profundidade: Guardrails, Menor Privilégio e Isolamento de Sessão

Segurança em um sistema de agentes tem três camadas que precisam funcionar juntas. A primeira é o **isolamento de sessão**: cada usuário roda em um contexto completamente separado no AgentCore Runtime. Não há vazamento de memória entre sessões — o que o usuário A disse não aparece no contexto do usuário B. Isso é análogo ao isolamento de processo em um SO: cada processo tem seu próprio espaço de endereçamento.

A segunda camada são os **Bedrock Guardrails**: filtros configuráveis que inspecionam tanto o input do usuário quanto o output do modelo. Você configura tópicos proibidos (ex: 'não fale sobre concorrentes'), filtros de PII (CPF, cartão de crédito são mascarados automaticamente), e thresholds de conteúdo ofensivo. Os guardrails rodam **fora** do modelo — eles não consomem tokens e não podem ser contornados por prompt injection no conteúdo da mensagem.

A terceira camada é o **menor privilégio nas ferramentas**: a IAM Role do AgentCore Runtime deve ter acesso apenas às ferramentas que aquele agente específico precisa. Se o agente de suporte ao cliente não precisa escrever no banco de dados, a role não tem permissão de escrita. O AgentCore Identity gerencia as credenciais de ferramentas externas (APIs de terceiros, OAuth tokens) — o modelo nunca vê essas credenciais, elas são injetadas pelo runtime no momento da chamada.

Um padrão que recomendo: use **tags de sessão** na IAM para que cada chamada de ferramenta carregue o ID do usuário. Isso permite auditoria granular no CloudTrail — você consegue reconstruir exatamente quais ferramentas foram chamadas por qual usuário em qual sessão.

## AgentCore em Produção — Lente do Well-Architected

- **security**: Isolamento de sessão no Runtime, Guardrails para PII e tópicos proibidos, AgentCore Identity para credenciais de ferramentas, IAM com menor privilégio e session tags para auditoria no CloudTrail.
- **reliability**: Runtime serverless com retry automático; Memory com backend DynamoDB (multi-AZ por padrão); fallback de modelo configurável no Bedrock (ex: Sonnet → Haiku em caso de throttling).
- **performance**: Seleção de modelo por tarefa (não use Claude 3.7 para classificação simples); cache de ferramentas para buscas repetidas; streaming de resposta para reduzir latência percebida pelo usuário.

## Por Onde Começar — Checklist Mental para o Arquiteto AWS

- 1. Defina o caso de uso: é um agente reativo (responde perguntas) ou proativo (executa tarefas)? Isso determina se você precisa de memória de longo prazo e quais ferramentas são necessárias.
- 2. Comece com Bedrock Agents no console para validar o prompt de sistema e as ferramentas básicas. Migre para Strands + AgentCore quando precisar de isolamento de sessão ou ferramentas customizadas.
- 3. Escolha o modelo pelo problema, não pela reputação: teste Haiku primeiro, suba para Sonnet se a qualidade não for suficiente, use extended thinking apenas para raciocínio genuinamente complexo.
- 4. Configure Guardrails desde o dia 1: PII masking e tópicos proibidos são não-negociáveis em produção. Adicione filtros de conteúdo mesmo que o caso de uso pareça 'seguro'.
- 5. Instrumente com AgentCore Observability desde o início: traces distribuídos são a única forma de depurar loops de raciocínio em produção. Adicione evals automatizadas (groundedness) como gate de deploy.
- 6. Modele o custo antes de ir a produção: estime sessões/mês × passos ReAct × tokens por passo × preço do modelo. Um agente bem dimensionado custa menos de $50/mês para cargas modestas.

> **Minha Perspectiva — Para Quem Está Fazendo Esta Transição:** Depois de 16 anos construindo sistemas financeiros e de dados na AWS, o que mais me impressiona no AgentCore não é a tecnologia em si — é o fato de que os problemas que ele resolve (isolamento, credenciais, observabilidade, custo ocioso zero) são exatamente os mesmos problemas que resolvemos em microsserviços há uma década. A diferença é que agora o 'serviço' é um loop de raciocínio não-determinístico, e isso muda fundamentalmente como você testa, monitora e opera.

O erro mais comum que vejo arquitetos cometendo ao entrar neste espaço é tratar o agente como um microsserviço determinístico. Não é. Você precisa aceitar que o mesmo input pode produzir outputs diferentes, e projetar o sistema para isso: evals automatizadas em vez de testes unitários clássicos, traces de raciocínio em vez de logs de transação, guardrails em vez de validação de schema.

O segundo erro é escolher o modelo mais poderoso por padrão. O custo de usar Claude 3.7 para tudo é proibitivo em escala — e na maioria dos casos, Haiku ou Sonnet resolvem o problema com uma fração do custo. Trate a seleção de modelo como uma decisão de arquitetura, não uma configuração.

Se você vem de plataformas de dados ou sistemas financeiros, você já tem as habilidades mais importantes: pensar em isolamento, auditoria, custo e confiabilidade. O AgentCore é, no fundo, uma plataforma de dados para loops de raciocínio. A transição é mais natural do que parece.

## Fechando a Série: O Que as Três Partes Constroem Juntas

Esta série percorreu o elevador de arquitetura do topo ao fundo. A **Parte 1** estabeleceu o andar de negócio: o que é um agente de IA, por que ele é diferente de um chatbot, e quando faz sentido usar. A **Parte 2** desceu para o andar de design: os padrões de orquestração (ReAct, Chain-of-Thought, multi-agente), como os loops de raciocínio funcionam, e as armadilhas de design mais comuns. Esta **Parte 3** chegou ao andar técnico: como colocar tudo isso em produção na AWS com isolamento, segurança, observabilidade e custo controlado.

O que as três partes constroem juntas é um **modelo mental completo**: você sabe por que agentes existem (Parte 1), como eles pensam (Parte 2), e como você os opera (Parte 3). Esse modelo mental é o que diferencia um arquiteto que 'usa LLMs' de um arquiteto que 'projeta sistemas de agentes'.

Os próximos estudos desta série de arquitetura aprofundam dois temas que apenas tocamos aqui: **orquestração multi-agente** (como coordenar múltiplos agentes especializados em um sistema coerente) e **AgentCore em produção** (um estudo de caso detalhado com números reais de custo e latência). Se você chegou até aqui, você tem a base para ler esses estudos com profundidade.

## Veredicto — O Estado Real do AgentCore em 2025

O Amazon Bedrock AgentCore resolve problemas reais de produção que qualquer equipe encontra ao sair do notebook. O Runtime serverless com isolamento de sessão, o Gateway MCP, a memória gerenciada e a observabilidade com traces são componentes maduros o suficiente para sistemas de produção em 2025. O modelo de custo pay-per-use é genuinamente vantajoso para cargas intermitentes — um agente bem dimensionado custa menos de $50/mês para uso moderado, sem custo ocioso.

As limitações reais: o ecossistema ainda é jovem (muitas APIs em preview), a documentação tem lacunas, e a curva de aprendizado para depurar loops de raciocínio não-determinísticos é real. A escolha entre Strands e LangGraph depende da complexidade do seu grafo de raciocínio — não existe resposta universal.

Minha recomendação prática: se você está construindo seu primeiro agente de produção na AWS, comece com Bedrock Agents para validar o caso de uso, migre para Strands + AgentCore quando precisar de controle fino, e invista em observabilidade desde o dia 1. A seleção de modelo é a decisão de maior impacto no TCO — trate-a como uma decisão de arquitetura explícita, revisada periodicamente à medida que novos modelos são lançados no Bedrock.

## Referências

- [Amazon Bedrock AgentCore — Product Page](https://aws.amazon.com/bedrock/agentcore/)
- [Amazon Bedrock Agents — Product Page](https://aws.amazon.com/bedrock/agents/)
- [Introducing Web Search on Amazon Bedrock AgentCore — AWS Blog](https://aws.amazon.com/blogs/machine-learning/introducing-web-search-on-amazon-bedrock-agentcore/)
- [Building Effective Agents — Anthropic Engineering](https://www.anthropic.com/engineering/building-effective-agents)
- [The Architecture Elevator — Gregor Hohpe](https://architectelevator.com/)

## Fontes do caso

- [AWS — Amazon Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/)
- [AWS — Amazon Bedrock Agents](https://aws.amazon.com/bedrock/agents/)
- [AWS — Web Search on Amazon Bedrock AgentCore](https://aws.amazon.com/blogs/machine-learning/introducing-web-search-on-amazon-bedrock-agentcore/)
- [Anthropic — Building effective agents](https://www.anthropic.com/engineering/building-effective-agents)