AWS Bedrock AgentCore em 2026: o que mudou para agentes
TL;DR
Em 2026, o Amazon Bedrock AgentCore saiu da ideia de “runtime para agentes” e ganhou peças de plataforma para operação real: governança com Policy, avaliação contínua com Evaluations e melhorias em Identity e Payments. Na prática, isso reduz a quantidade de lógica espalhada no código do agente e aproxima a arquitetura de requisitos de produção, como controle de acesso, qualidade mensurável e fluxos com credenciais escopadas.
O que mudou de forma relevante
O anúncio mais importante é a mudança de foco. Antes, muita gente olhava o AgentCore como a camada que executa agentes com menos esforço operacional; agora, a plataforma explicita três preocupações que aparecem quando o piloto sai do laboratório: governança, qualidade e identidade/transações. A síntese oficial da AWS está no post sobre Policy e Evaluations do AgentCore, além das notas de disponibilidade geral de março e abril de 2026 (AWS blog, Evaluations GA, Policy GA).
Policy: controle fora do código do agente
O movimento mais claro é a chegada de Policy como controle declarativo no AgentCore Gateway. Em vez de confiar só em condicionais dentro do app, a chamada de ferramenta pode ser interceptada antes da execução, permitindo bloquear ou liberar ações com base em regras centralizadas (fonte oficial). Isso importa porque agente em produção quase nunca é só “gerar texto”: ele consulta CRM, dispara ticket, lê dados internos e, às vezes, chama serviços pagos. Se a regra vive no código do agente, cada novo fluxo vira retrabalho.
Na prática, o desenho fica mais próximo de uma camada de autorização para ferramentas. Você consegue separar o raciocínio do agente da política que decide se a ação pode ocorrer. Para equipes que já usam AWS, isso conversa bem com o padrão de centralizar controles em serviços de borda ou gateways, em vez de espalhar validações em cada função.
Evaluations: qualidade monitorada com uso real
Outro salto é o AgentCore Evaluations, que entrou em GA em março de 2026 e foi apresentado como mecanismo para avaliar agentes com base em interações reais, com avaliadores nativos e customizados (AWS “What’s New”, AWS blog). O efeito prático é sair do “parece funcionar” e ir para um ciclo onde respostas e ações do agente podem ser medidas ao longo do tempo.
Isso é particularmente útil em agentes de suporte, operação e backoffice, em que o erro mais cara não é só uma resposta imprecisa, mas um ticket mal classificado ou uma ação executada sem o passo de validação certo. A vantagem de uma avaliação contínua é conseguir criar critérios de negócio, e não só métricas genéricas de linguagem.
Esta seção descreve a versão de 2026 do AgentCore. APIs e recursos de agentes mudam rápido — confira o changelog oficial antes de adotar em produção.
Identity OBO: menos fricção para agir em nome do usuário
Em abril de 2026, a AWS anunciou suporte a On-Behalf-Of (OBO) token exchange no AgentCore Identity (nota oficial). O ganho aqui é simples de entender: o agente pode obter credenciais escopadas em nome do usuário autenticado, o que ajuda a manter o princípio de menor privilégio sem redesenhar consentimentos a cada recurso autenticado.
Esse ponto pesa muito em fluxos corporativos. Um agente que lê dados de um sistema interno e depois atualiza outro serviço precisa responder ao contexto do usuário, e não operar como uma conta genérica com acesso amplo. O OBO reduz a chance de atalho perigoso do tipo “um token único resolve tudo”.
Payments: agentes que encostam em APIs pagas
Também em abril de 2026, a AWS colocou Payments em preview no AgentCore (fonte oficial). A ideia é permitir que agentes acessem e paguem APIs ou recursos pagos de forma gerenciada, o que abre espaço para microtransações durante a execução.
Esse recurso é interessante para casos de automação operacional e compras assistidas. Em vez de o agente depender de uma integração artesanal para cada serviço pago, a camada de plataforma passa a encobrir parte da complexidade transacional. Isso não elimina revisão humana, mas reduz o atrito estrutural para cenários em que custo por chamada é parte natural do fluxo.
Como isso afeta a arquitetura de agentes
O somatório dessas mudanças aponta para uma plataforma mais completa: Runtime + Gateway + Identity + Memory + Observability + Policy + Evaluations + Payments, como a própria página oficial do serviço descreve (landing page oficial). Em vez de tratar o agente como uma aplicação isolada, o desenho passa a parecer uma malha de capacidades operacionais.
Para times de engenharia, o impacto é direto. Fica mais fácil dividir responsabilidade entre quem escreve o comportamento, quem define limites, quem mede qualidade e quem integra sistemas externos. Isso também ajuda em auditoria, já que decisões e acessos deixam de depender de lógica espalhada em múltiplos repositórios.
Padrão de uso mais adequado
Se você está montando um agente para produção, o ponto de partida em 2026 não é mais “qual modelo gera melhores respostas”, e sim “qual combinação de política, identidade, avaliação e observabilidade sustenta a operação”. O modelo continua importante, mas agora a plataforma já assume parte do trabalho que antes ficava no framework ou no código do app.
Em termos de implementação, vale pensar assim: o botão de ligar/desligar permissões deve viver no gateway; a medição de qualidade, no ciclo de avaliação; e a autorização em nome do usuário, na camada de identidade. Essa divisão reduz o acoplamento entre o agente e os sistemas que ele orquestra.
Por que importa pro dev brasileiro
No Brasil, a discussão não é abstrata: LGPD e exigências de auditoria interna tornam muito sensível a ideia de um agente ter acesso amplo demais a dados e sistemas. Em bancos, varejo, logística e SaaS B2B, é comum que o caminho mais curto tecnicamente acabe caro na revisão de segurança. Uma camada como Policy e OBO ajuda a aproximar a implementação de exigências concretas de privacidade e rastreabilidade, sem obrigar cada time a reinventar autorização no próprio agente.
Tem também um fator operacional local: muitos times brasileiros trabalham com orçamento em BRL e contratos que precisam justificar cada chamada a serviço gerenciado. Quando o agente passa a lidar com avaliações contínuas e políticas centralizadas, a arquitetura fica mais previsível para estimar custo e governança antes de escalar para dezenas de fluxos internos. Isso é particularmente útil em empresas que usam AWS em regiões fora do Brasil, onde latência e custo de tráfego cruzado entram na conta diária.
O que observar antes de adotar
Para adoção prática, eu observaria três pontos. Primeiro, se seus fluxos dependem de múltiplas ferramentas com dados sensíveis, vale desenhar a política fora do código desde o início. Segundo, se o agente vai apoiar atendimento, operações ou qualquer fluxo repetitivo, configure avaliações com critérios de negócio desde o piloto. Terceiro, trate identidade e pagamentos como capacidades de plataforma, e não como “detalhe de integração”.
O ecossistema oficial também já tem exemplos e starters úteis, como awslabs/agentcore-samples, sample-ai-agent-accelerator e sample-amazon-bedrock-agentcore-fullstack-webapp. Eles ajudam a sair do conceito e ver como a plataforma se encaixa em app, infraestrutura e autenticação.
Conclusão
O AWS Bedrock AgentCore em 2026 deixa claro que agente em produção não é só prompt mais modelo: é também política, avaliação, identidade e transação. A principal mudança foi transformar a operação do agente em algo mais governável e mensurável, com menos lógica crítica espalhada pelo código.
Se você já usa AWS, o próximo passo mais útil é abrir a documentação oficial do AgentCore, mapear um fluxo real do seu time e desenhar onde Policy, OBO e Evaluations entrariam hoje. Em menos de uma hora, você consegue identificar pelo menos um caso de uso para refatorar a autorização de ferramenta e começar um plano de validação contínua (documentação oficial).
Conteúdos da DIO para quem quer aprofundar
- Nexa - Fundamentos de IA Generativa com Bedrock — trilha curta para entender bases de IA generativa na AWS e aplicar Bedrock em projetos práticos.
- Nexa - Engenharia de Prompts na AWS com Claude — foco em engenharia de prompts para ganhar controle e consistência em fluxos com IA generativa.
- CI&T - Backend com Java & AWS — ajuda a conectar agentes e serviços em uma base backend escalável com AWS e Spring Boot.
- Aceleração Microsoft AI Agents — aborda o desenho e a operação de agentes de IA em contexto prático, útil para comparar padrões de mercado.
Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.
