Amazon Bedrock AgentCore: runtime, tools e evals
TL;DR
Amazon Bedrock AgentCore junta três peças que costumam ficar espalhadas em projetos de agentes: runtime isolado, gateway para tool calls e avaliações automatizadas. Na prática, isso simplifica operação, observabilidade e governança quando você quer levar um agente do protótipo para produção sem reinventar a base de infraestrutura.
O ponto central é que a plataforma trata execução, autorização e qualidade como partes do mesmo sistema. Isso importa especialmente para times que precisam controlar acesso a ferramentas, medir comportamento em produção e validar trajetórias de uso de tools com rastreamento consistente.
O que o AgentCore resolve na prática
Em arquiteturas de agentes, o problema raramente é só “chamar o modelo”. O difícil é sustentar sessão, memória operacional, acesso a ferramentas e auditoria sem transformar cada projeto em um conjunto de integrações soltas. O AgentCore entra exatamente nessa lacuna, oferecendo um conjunto gerenciado para runtime, gateway e evals, conforme a documentação oficial da AWS: runtime, gateway e evaluations.
Esse tipo de desenho faz sentido quando o agente deixa de ser demo e passa a lidar com fluxo real de negócio. Em vez de espalhar autorização em cada microserviço e avaliação em scripts independentes, você ganha um caminho mais padronizado para observar, controlar e evoluir o comportamento do agente.
Runtime: isolamento por sessão e tracing do comportamento
O AgentCore Runtime executa cada sessão do usuário em uma microVM dedicada, com isolamento de CPU, memória e filesystem, e registra traces para etapas de raciocínio, invocações de tools e interações com o modelo, segundo a documentação da AWS: Host agent or tools with Amazon Bedrock AgentCore Runtime.
Esse detalhe muda bastante a forma de operar agentes em produção. Em vez de depender só de logs da aplicação, você passa a ter uma trilha mais consistente do que o agente pensou, qual tool chamou e como a sessão se comportou. Para quem precisa depurar respostas erradas, loops de tool use ou latência em pipelines mais longos, isso vale ouro.
Por que isso importa para tool use
Tool use em agente não é apenas uma questão de “function calling”. O runtime precisa sustentar a conversa entre modelo, orquestrador e ferramenta sem perder contexto nem misturar sessões. Ao isolar a execução por usuário, o AgentCore reduz o risco de vazamento acidental entre sessões e facilita o rastreamento de decisões que levaram a uma chamada específica de ferramenta.
Esse tipo de isolamento também ajuda quando você precisa auditar o comportamento depois. Se a sessão foi aberta às 10h, chamou uma ferramenta de consulta e depois acionou uma segunda etapa, o trace fica como linha do tempo útil para troubleshooting e para avaliação posterior.
Gateway: uma porta única para tools, agentes e serviços
O AgentCore Gateway funciona como ponto de entrada gerenciado para tráfego agentic, conectando agentes, tools e modelos, além de expor integrações em formato compatível com Model Context Protocol, conforme a documentação oficial: Amazon Bedrock AgentCore Gateway e Use an AgentCore gateway.
Na prática, isso ajuda a padronizar discovery e execução de ferramentas. Em vez de acoplar cada agente diretamente a cada serviço interno, você coloca o gateway no meio e centraliza roteamento, exposição de capabilities e controles de acesso. Para times que lidam com vários domínios de negócio, esse desenho reduz a dispersão de integrações.
Tool calls com controle na borda
O anúncio da AWS sobre políticas e avaliações do AgentCore destaca que o gateway pode aplicar controles de policy antes da execução da tool call: AWS Blog. A política é descrita com Cedar, e a documentação explica a semântica de autorização, incluindo o comportamento de deny por padrão quando não há correspondência adequada: Understanding Cedar policies.
Esse ponto é importante porque muda o lugar onde a segurança é aplicada. Em vez de confiar que o modelo “vai se comportar”, você autoriza a chamada antes que a ferramenta seja executada. Para cenários com ações sensíveis — reembolso, acesso a dados internos ou atualização de cadastro — isso é um requisito de engenharia, não um detalhe de UX.
Exemplo de uso com gateway
O fluxo típico é: o agente consulta as tools disponíveis, escolhe uma opção e chama a ação por meio do gateway. A AWS documenta operações como listagem e chamada de tools no endpoint do gateway, que serve como abstração uniforme para vários serviços e integrações: Use an AgentCore gateway.
Se o seu agente precisa atravessar múltiplos domínios internos, centralizar tool discovery e autorização no gateway evita que cada projeto crie sua própria “mini plataforma” de agentes.
Ai, policies e governança com Cedar
A peça de policy do AgentCore usa Cedar para expressar quem pode fazer o quê, em qual contexto e contra qual recurso. O material oficial mostra que o modelo é centrado em principal, action, resource e scope, com regras que podem aprovar ou bloquear chamadas de ferramenta: Understanding Cedar policies.
Isso permite montar regras de negócio próximas da execução. Por exemplo, uma política pode restringir o uso de uma tool a um conjunto específico de usuários ou a um valor máximo de operação, o que é útil para processos financeiros, atendimento e automação interna. O benefício é reduzir a distância entre a regra escrita e o ponto onde ela precisa ser aplicada.
Para um time brasileiro, há um argumento adicional bem concreto: conformidade e rastreabilidade costumam caminhar junto com exigências da LGPD. Quando você automatiza interações que tocam dados pessoais, autorização explícita, trilha de auditoria e minimização de acesso deixam de ser “boas práticas” e passam a ser parte da implementação. Em empresas que operam com dados de clientes no Brasil, isso afeta diretamente como o agente pode consultar, classificar e acionar ferramentas.
Evals: medir qualidade, tool usage e consistência
O AgentCore Evaluations foi projetado para avaliar agentes com base em traces, convertendo a execução para um formato comum e aplicando scoring com LLM-as-a-judge, além de avaliadores built-in e custom, segundo a documentação oficial: Evaluate agent performance with Amazon Bedrock AgentCore Evaluations.
O lançamento em GA também destaca monitoramento contínuo, execução online, on-demand e batch, além de cobertura para tool usage entre os built-ins: AWS What’s New. Essa combinação é relevante porque agentes raramente falham de um único jeito. Às vezes erram a resposta final; às vezes até respondem certo, mas chamam a ferramenta errada no caminho.
LLM-as-a-judge não é só “notas subjetivas”
Quando a AWS fala em eval por LLM-as-a-judge, não está descrevendo uma “opinião do modelo” no sentido informal. O contexto é usar critérios e avaliadores definidos para pontuar traces e comparar comportamento contra requisitos esperados. Isso ajuda a automatizar checks que, manualmente, seriam caros demais para rodar em toda mudança de prompt, tool ou policy.
Para times de produto e plataforma, o ganho está em conseguir observar regressões antes que elas cheguem ao usuário final. Se uma atualização faz o agente ficar menos consistente ao escolher tools, o score cai e o problema aparece no pipeline de validação.
Ground truth e trajetória esperada
Além das avaliações baseadas em judge, a AWS documenta avaliações de ground truth para comparar o comportamento real com uma trajetória de referência, incluindo checagens como trajectory matching: Ground truth evaluations.
Esse tipo de avaliação é especialmente útil em fluxos com tool use previsível. Se sua aplicação espera que o agente consulte uma base, depois faça uma validação e só então responda, a trajetória esperada vira parte do contrato do sistema. Isso é diferente de apenas avaliar o texto final.
Como pensar a adoção sem virar refém da plataforma
Uma maneira saudável de adotar o AgentCore é separar o que é contrato de plataforma do que é lógica de produto. O runtime pode cuidar da execução e observabilidade; o gateway pode centralizar descoberta e autorização; as evals podem medir qualidade e tool usage. Já a regra de negócio do seu produto continua no seu domínio, com prompts, ferramentas e políticas próprias.
Esse recorte ajuda a evitar o erro comum de acoplar o agente inteiro à infraestrutura de um único cenário. Se amanhã você quiser trocar a ferramenta de busca, ajustar o fluxo de aprovação ou adicionar política para uma ação sensível, a mudança fica mais localizada.
Relação com o ecossistema AWS
O briefing também indica uma transição de tooling: o repositório aws/bedrock-agentcore-starter-toolkit aparece como legado, enquanto o aws/agentcore-cli é a CLI recomendada para novos projetos. Isso sugere um ecossistema em consolidação, com foco em desenvolvimento, harness e online evals. Para quem já opera na AWS, a curva de adoção tende a ser menor porque o modelo mental continua próximo de runtime, gateway e observabilidade.
Por que importa pro dev brasileiro
No Brasil, muita equipe chega em agentes por caminhos práticos: times pequenos, pressão por provar valor rápido e orçamento em BRL que precisa caber em AWS, banco de horas e manutenção. Nesse cenário, um runtime gerenciado com tracing e evals reduz o custo de montar do zero o que, em geral, viraria uma plataforma interna paralela. Isso é ainda mais sensível quando a arquitetura precisa respeitar regras locais de dados e rotinas de governança em empresas que processam informações de clientes no país.
Outro ponto concreto é operação. Em muitos stacks brasileiros, o ambiente de produção fica em regiões AWS fora do país e o time precisa equilibrar latência, custo e requisitos de controle. Quando o agente depende de várias chamadas de ferramenta, centralizar autorização e observabilidade no gateway evita uma cadeia de integrações difícil de diagnosticar em horário comercial, quando tudo precisa ser corrigido rápido.
Conclusão
AgentCore faz sentido quando você quer tratar agente como sistema, não como demo de prompt. O runtime cuida da execução isolada, o gateway organiza o uso de tools e o módulo de evals fecha o ciclo com medição contínua de qualidade, trailer de tracing e validação de trajetória.
Se você estiver estudando isso para um projeto real, faça uma validação de uma hora: abra a documentação oficial do runtime, do gateway e de evaluations, e mapeie uma tool crítica do seu sistema para entender onde entraria policy, tracing e avaliação antes de escrever a primeira linha de integração.
Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.
Conteúdos da DIO para quem quer aprofundar
- AWS - Agentes de IA em Campo — Trilha prática para criar soluções com Amazon Bedrock, agentes autônomos, automação e projetos aplicados em cloud.
- Nublify - Primeiros passos em IA e Cloud — Jornada introdutória que combina fundamentos de cloud na AWS com IA Generativa, agentes e automações.
- XP Inc. - Cloud com Inteligência Artificial — Bootcamp voltado a IA na nuvem, engenharia de prompt, machine learning e projetos de portfólio.
- Aceleração Microsoft - Azure AI Agents — Experiência focada em criação, orquestração e governança de agentes de IA em ambiente corporativo.
- Formação AWS Cloud Foundations — Formação para dominar fundamentos da AWS, arquitetura, segurança e serviços essenciais de cloud.
