AWS Agent Registry chega ao uso geral — namespace antigo acaba dia 17

O AWS Agent Registry chegou à disponibilidade geral em 31 de agosto de 2026, com um catálogo privado para agentes, ferramentas, habilidades, servidores MCP e recursos personalizados. O anúncio de disponibilidade geral da AWS também delimita a oferta a cinco regiões: Norte da Virgínia, Oregon, Irlanda, Tóquio e Sydney.

Para equipes que adotaram a prévia, o lançamento traz uma migração obrigatória: dados e integrações precisam sair do namespace bedrock-agentcore antes de 17 de setembro de 2026. Uma verificação independente da transição confirma tanto o uso geral desde 31 de agosto quanto o caráter incompatível da mudança para agent-registry.

O que muda com a disponibilidade geral

O Registry passa a funcionar como uma camada gerenciada de catálogo, governança e descoberta. Registros aprovados podem ser encontrados por pesquisa semântica, palavras-chave, navegação pelo console, APIs e um endpoint compatível com MCP; o catálogo descreve os recursos, mas não substitui a autorização necessária para invocá-los.

Além dos recursos já apresentados na prévia — criação manual ou baseada em URL, aprovação, pesquisa e auditoria pelo AWS CloudTrail —, a versão geral acrescenta provisionamento com AWS CloudFormation, Terraform e AWS CDK. Também incorpora tags, compartilhamento entre contas pelo AWS Resource Access Manager e detecção, dentro da organização, de agentes no AgentCore Runtime e de recursos expostos pelo AgentCore Gateway.

A disponibilidade em cinco regiões não inclui São Paulo. Uma operação voltada ao Brasil, portanto, precisa escolher entre as localidades oferecidas e avaliar latência, residência de dados e regras internas de governança; o status de uso geral não representa disponibilidade automática em todas as regiões da AWS.

O prazo de 17 de setembro é um corte de acesso

O novo namespace agent-registry foi aberto em 6 de agosto. O guia de migração do AWS Agent Registry estabelece que o namespace de prévia será desligado em 17 de setembro de 2026, quando usuários perderão o acesso de leitura e gravação ao serviço e aos dados que ainda permanecerem em bedrock-agentcore.

A convivência temporária dos dois namespaces vale para contas que já possuíam registries ou records em 6 de agosto. Clientes sem esses recursos naquela data devem começar diretamente em agent-registry. O risco operacional, portanto, está concentrado nas implantações de prévia que ainda mantêm catálogos, automações ou processos de aprovação ligados às interfaces anteriores.

Não se trata de trocar apenas o nome usado no SDK. Mudam os endpoints dos planos de dados e controle, os comandos da AWS CLI, o prefixo das ações IAM, o principal do serviço e os ARNs. Também precisam ser revistos eventos do EventBridge, consultas do CloudTrail, métricas e alarmes do CloudWatch, limites do serviço e qualquer automação que armazene ou interprete os identificadores antigos.

O modelo da API também rompe compatibilidade. Há campos obrigatórios novos nos records, reestruturação de descritores, filtros diferentes e operações de descoberta renomeadas. Sem essas adaptações, uma aplicação pode migrar os dados e ainda assim falhar ao criar, listar, aprovar ou localizar registros no novo ambiente.

Checklist mínimo para migrar sem perder descoberta

O caminho mínimo começa com um inventário por conta e região. A equipe precisa localizar registries, records, estados de aprovação, consumidores do catálogo e todas as referências técnicas ao namespace antigo, incluindo pipelines que escrevem continuamente e aplicações que apenas consultam registros aprovados.

1. Inventariar dependências: mapear endpoints, clientes do SDK, comandos da CLI, políticas IAM, SCPs, limites de permissão, ARNs, regras do EventBridge, consultas do CloudTrail, painéis, alarmes e configurações de clientes MCP.
2. Escolher o modo de migração: executar a ferramenta localmente para uma transferência única; usar jobs no AWS Glue para execução sem terminal e cargas incrementais; ou manter escrita nos dois namespaces durante uma validação ativa-ativa.
3. Atualizar código e acesso: direcionar os clientes para agent-registry e agent-registry-control, adotar os endpoints no domínio api.aws e substituir permissões específicas do Registry pelo prefixo agent-registry.
4. Transferir os dados: extrair os recursos da prévia, transformar o esquema e criar os novos registries e records na mesma conta e região.
5. Validar e cortar o tráfego: comparar as quantidades de recursos, inspecionar descritores transformados, testar leitura, gravação, aprovação e descoberta e, por fim, mover todo o tráfego de produção.

A ferramenta cria recursos novos no namespace de destino; ela não converte os objetos antigos em aliases. Por isso, os ARNs mudam, e sistemas que guardam esses valores — bancos de configuração, políticas, esteiras ou índices — precisam receber os novos identificadores. Em ambientes com gravações contínuas, uma carga incremental imediatamente antes do corte evita que alterações feitas após a primeira cópia fiquem para trás.

Identidade, sincronização e aprovação precisam de testes próprios

Uma substituição global de bedrock-agentcore seria incorreta. A mudança alcança as APIs do Registry, mas workload identities e provedores de credenciais OAuth do AgentCore Identity continuam no namespace anterior. Registros sincronizados por URL podem precisar, ao mesmo tempo, de permissões agent-registry para o catálogo e de ações bedrock-agentcore relacionadas à identidade.

Se a sincronização usa uma função IAM, a política de confiança deve aceitar o novo principal agent-registry.amazonaws.com antes da carga definitiva. A ferramenta de migração não identifica sozinha essa dependência, pois é o serviço que assume a função de maneira assíncrona. Uma confiança desatualizada pode deixar o record em CREATE_FAILED; nesse caso, é necessário corrigir a política, excluir o item com falha e repetir a carga.

A aprovação também mudou no modelo da API. O booleano autoApproval foi substituído pela lista autoApprovalRules: APPROVE_ALL preserva a aprovação automática, enquanto uma lista vazia exige análise manual. A validação precisa confirmar não apenas que os records existem, mas que aqueles destinados à descoberta alcançaram o estado APPROVED.

O que precisa estar concluído até o corte

A migração não termina quando a ferramenta copia os dados. O corte só está completo depois que clientes, permissões, eventos, observabilidade, sincronização e aprovações funcionam sob agent-registry, com leituras e gravações de produção afastadas do caminho anterior.

O marco confirmado continua sendo 17 de setembro de 2026, sem transferência automática dos dados da prévia. Até essa data, as equipes afetadas precisam concluir a cópia, resolver incompatibilidades da API e validar o catálogo novo; depois do desligamento, os recursos deixados apenas em bedrock-agentcore não permanecerão acessíveis para leitura ou gravação.

Leia também:

• Gemini chega aos bancos com mais de 50 habilidades — mas ainda em prévia
• Agent Toolkit da AWS em um comando — limite o que a IA pode executar
• Telescópio Roman chega ao foguete — o céu que ele verá é 100 vezes maior