Bedrock AgentCore: agentes em produção na AWS

O AgentCore Runtime é o ambiente de execução do agente — serverless, isolado por sessão. Cada sessão ganha seu próprio sandbox: sem estado compartilhado entre usuários, sem você gerenciar containers ou escalar manualmente. Você traz seu código de agente (qualquer framework: LangGraph, Strands Agents, código puro) e o Runtime cuida do ciclo de vida.

O AgentCore Gateway é o que conecta o modelo ao mundo externo usando o protocolo MCP que vimos na aula 14. Em vez de você implementar um servidor MCP do zero, o Gateway expõe suas ferramentas como endpoints MCP gerenciados. O modelo chama uma tool, o Gateway roteia para a implementação correta, devolve o resultado — e o loop ReAct da aula 11 continua.

A separação entre Runtime e Gateway é intencional: o Runtime pensa, o Gateway age. Isso significa que você pode trocar o framework do agente sem mexer nas ferramentas, e pode adicionar ferramentas sem redeployar o agente. É o mesmo princípio de desacoplamento que aplicamos em event-driven architecture — só que aplicado ao loop cognitivo do agente.

Na aula 12 vimos que agentes precisam de dois tipos de memória: curto prazo (o que aconteceu nesta conversa) e longo prazo (o que o agente deve lembrar entre sessões). O AgentCore Memory implementa exatamente isso. A memória de curto prazo é o histórico de mensagens da sessão atual, gerenciada automaticamente. A de longo prazo é um armazenamento persistente que o agente pode consultar e atualizar — útil para preferências do usuário, decisões anteriores ou contexto de projetos em andamento.

O AgentCore Identity resolve um problema que todo arquiteto enfrenta: como o agente autentica nas ferramentas que chama? Sem um bloco dedicado, você acaba com credenciais hardcoded, IAM roles excessivamente permissivas ou um sistema caseiro de gestão de segredos. O Identity centraliza isso: cada tool call passa por uma camada de autorização que valida se aquele agente, naquela sessão, tem permissão para chamar aquele recurso. É o princípio de menor privilégio da aula 10 aplicado em runtime.

A combinação Memory + Identity é o que diferencia um agente de produção de um protótipo. Um protótipo esquece tudo e tem acesso irrestrito. Um agente de produção lembra o que importa e só acessa o que precisa.

AgentCore Observability entrega o que a aula 9 pediu: visibilidade sobre o que o agente está fazendo. Cada passo do loop ReAct — qual tool foi chamada, qual foi a resposta, quanto tempo levou, qual foi o raciocínio do modelo — vira um traço estruturado. Você consegue responder perguntas como: por que o agente tomou essa decisão? Em qual passo ele alucionou? Qual tool está sendo o gargalo de latência? Sem isso, depurar um agente em produção é trabalhar no escuro.

As ferramentas gerenciadas fecham o ciclo. O Browser Tool dá ao agente a capacidade de navegar na web de forma isolada e auditável — sem você provisionar instâncias de browser, lidar com Playwright em produção ou expor sua rede. O Code Interpreter faz o mesmo para execução de código: o modelo gera Python, o Code Interpreter executa em sandbox, devolve o resultado. Ambos chegam via Gateway como qualquer outra tool MCP.

O ponto arquitetural aqui é consistência: todas as capacidades — ferramentas externas, browser, código, RAG — chegam ao modelo pelo mesmo protocolo. O agente não sabe se está chamando uma Lambda sua ou o Browser Tool gerenciado. Isso simplifica o design e facilita substituir implementações sem reescrever o agente.