Amazon Bedrock Agents Classic: o que muda com AgentCore
TL;DR
O Amazon Bedrock Agents passou a ser tratado como Amazon Bedrock Agents Classic e entrou em maintenance mode, com bloqueio para novos clientes a partir de 30 jul 2026. Na prática, isso empurra projetos de agentes com tool-use/function calling para o Amazon Bedrock AgentCore, onde o time passa a controlar mais claramente runtime, ferramentas, policy e observabilidade.
Para quem já usa agentes em produção, a mudança importa menos como um “rename” e mais como uma troca de modelo operacional. O foco sai de um orquestrador único e vai para uma arquitetura modular, com Gateway MCP, ferramentas declaradas como funções e fronteira de autorização explícita entre agente e tool.
O que mudou no Bedrock Agents Classic
A documentação oficial da AWS diz que o produto foi reposicionado como Amazon Bedrock Agents Classic e entrou em maintenance mode, com o catálogo de modelos congelado na data efetiva para o Classic. Isso significa que novos modelos e a evolução da experiência de agentes passam a acontecer no guia oficial de maintenance mode e no ecossistema do Amazon Bedrock AgentCore.
O ponto importante aqui é arquitetural. O Classic centralizava mais a orquestração; já a nova direção da AWS trata o agente como uma composição de runtime, tools, memória, identidade e policy boundary. Para o time, isso muda a forma de organizar deploy, observabilidade e governança do ciclo de chamada de ferramenta.
Por que AgentCore virou o destino natural da migração
O AgentCore aparece como o sucessor arquitetural para workloads agentic porque separa responsabilidades que, no Classic, ficavam bastante acopladas. A AWS descreve primitivas para Gateway, Runtime, Memory, Identity e Tools na visão geral oficial do produto: What is Bedrock AgentCore.
Essa separação fica especialmente útil quando o caso de uso envolve tool-use/function calling. Em vez de depender de um fluxo fechado de “ação gerenciada” no produto, o time pode expor funções do próprio código ao harness e conectar ferramentas externas por meio de um gateway padronizado. O efeito prático é mais previsibilidade para versionamento, testes e controle de acesso.
Esta seção descreve a versão documentada pela AWS em 2026. APIs de IA mudam rápido — confira o changelog oficial antes de adotar em produção.
Tool-use na prática: Gateway MCP e funções como ferramentas
Um dos eixos mais concretos da migração é o uso de MCP no Gateway do AgentCore. Em vez de acoplar tool-calling diretamente ao ciclo do modelo, o gateway expõe uma interface padronizada para chamar ferramentas, incluindo fluxo de tools/call conforme a documentação oficial.
Na outra ponta, o AgentCore também aceita o padrão de tool como função no próprio código do agente, algo alinhado ao uso do SDK/framework do time. O exemplo prático mais próximo do que a AWS vem promovendo é o uso de funções anotadas como tool, com o runtime hospedando o agente e delegando a execução das ferramentas de forma explícita: mass-migrating AI agents to Amazon Bedrock AgentCore.
Para quem trabalha com function calling, isso reduz a chance de “mágica escondida” no operador de orquestração. O pipeline fica mais legível: o modelo decide que precisa de uma tool, o harness emite a chamada, o gateway aplica política, a função executa e o resultado volta para a próxima etapa do raciocínio.
Exemplo mental do fluxo
Sem entrar em pseudocódigo inventado, o fluxo típico fica assim: o agente recebe a pergunta, identifica que precisa consultar um sistema externo, chama a tool via gateway MCP, recebe a resposta e continua a conversa. A documentação de Tools no AgentCore mostra exatamente esse padrão de ida e volta com stop reason ligado a tool use.
Esse desenho ajuda quando a aplicação precisa de observabilidade real sobre a sequência “prompt → tool invoke → retorno → próxima ação”. Em produção, isso facilita depuração, auditoria e análise de falhas de integração.
Policy como fronteira entre agente e ferramenta
Outro ponto relevante da migração é a política como fronteira explícita. A AWS documenta o uso de Cedar no AgentCore para controlar interações agente→tool com lógica determinística e modelo de default-deny.
Isso é importante porque agentes com tool-use não falham só por problemas de modelo; eles também falham por excesso de permissão. Quando o authorization boundary vira uma camada nativa do gateway, fica mais simples separar o que o agente pode sugerir do que ele de fato pode executar.
Em organizações com requisitos de compliance, esse detalhe vale muito. No Brasil, empresas sujeitas à LGPD e auditorias internas costumam precisar justificar por que um agente acessa determinado dado, sistema ou API. Colocar essa regra em policy code, em vez de espalhar checagens na aplicação, reduz ambiguidade e ajuda a demonstrar controle.
Observabilidade e operação: do protótipo ao time de plataforma
O AgentCore também coloca observabilidade no centro. A documentação oficial cobre métricas e spans para runtime, gateway e chamadas relacionadas ao ecossistema do agente: observability for gateway metrics.
Isso faz diferença porque agentes em produção raramente falham de forma linear. Às vezes o LLM está certo, mas a tool não responde; às vezes a tool responde, mas a policy bloqueia; às vezes a memória precisa ser revisada para entender por que a decisão anterior influenciou a próxima chamada. Com tracing, o time enxerga esse encadeamento sem depender de logs soltos em vários serviços.
Na prática, a migração para AgentCore empurra o time de desenvolvimento para um modelo mais próximo de plataforma. Em vez de tratar o agente como uma feature isolada, ele passa a ser um serviço com runtime, identidade, memória, gateway de ferramentas e métricas padronizadas.
Como pensar a migração a partir do Classic
Se o seu agente hoje está no Classic, a pergunta útil não é “como replicar tudo igual”, mas “qual é a menor superfície que preciso preservar”. Em muitos casos, o caminho é migrar primeiro o harness e o tool-use: identificar as chamadas externas, mover essas integrações para tools explícitas e colocar o agente em um runtime mais controlável.
O blog da AWS sobre migração em massa deixa claro que a estratégia envolve converter o padrão antigo para um novo desenho com runtime hospedado e ferramentas conectadas via gateway: mass-migrating AI agents to Amazon Bedrock AgentCore. Essa é a parte que mais se aproxima de uma migração real de arquitetura, e não só de nomenclatura.
Se você ainda estiver em fase de desenho, vale olhar também exemplos de implementação com Strands e AgentCore no repositório oficial de amostras: sample-for-bedrock-agentcore-strands-agents. Mesmo sem copiar a estrutura literalmente, ele ajuda a visualizar como separar ferramentas, memória e runtime.
Por que isso importa pro dev brasileiro
O impacto no Brasil aparece em dois pontos concretos. Primeiro, muita operação local roda com restrição de orçamento em BRL e com equipes pequenas, então uma arquitetura de agente que dificulta testes, auditoria e rollback tende a encarecer a adoção. Segundo, empresas brasileiras que tratam dados pessoais sob a LGPD precisam controlar melhor quem pode acessar o quê, principalmente em integrações com sistemas internos, atendimento e dados sensíveis.
Além disso, é comum que times no Brasil operem com latência sensível para us-east-1 e dependam de janelas curtas de deploy. Ter policy, observabilidade e tools mais explícitas no desenho reduz o custo de diagnóstico quando o agente começa a errar em produção. Isso é especialmente útil para fintechs, varejo e SaaS locais, onde o agente não pode virar uma caixa-preta difícil de fiscalizar.
Conclusão
O fim do Bedrock Agents no modo clássico não encerra o uso de agentes na AWS; ele muda o ponto de entrada. Para projetos que dependem de tool-use/function calling, o AgentCore oferece um caminho mais modular, com gateway padronizado, policy explícita e observabilidade suficiente para sair do protótipo e entrar em operação.
Se você já tem um agente em produção, a ação mais útil na próxima hora é simples: abra a documentação oficial do Amazon Bedrock AgentCore, liste todas as ferramentas que seu agente chama hoje e classifique cada uma em “pode virar tool no gateway” ou “precisa permanecer fora do fluxo do agente”. A partir daí, você já tem o primeiro passo real da migração.
Conteúdos da DIO para quem quer aprofundar
- Nexa - Fundamentos de IA Generativa com Bedrock — trilha curta para entender fundamentos de IA generativa com Amazon Bedrock, PartyRock, Amazon Nova e AgentCore em projetos práticos.
Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.
