AWS Bedrock AgentCore Registry: Primeiras Impressões do Preview

Veja o código fonte aqui: bedrock-agentcore-registry-demo

Visão Geral

Em novembro de 2024, a Anthropic tornou o MCP open source e a maioria dos times descartou como mais um protocolo que morreria em comitê. Hoje o MCP tem 97 milhões de downloads mensais do SDK e apoio da Anthropic, OpenAI, Google e Microsoft. Em dezembro de 2025, agent skills surgiram como um padrão aberto adotado pelo Claude Code, GitHub Copilot, Cursor, Gemini CLI e outros. O ritmo é implacável: novas camadas de interoperabilidade, novos frameworks de agentes, novos protocolos. Cada um adiciona capacidade. Cada um também adiciona mais uma coisa para rastrear, governar e proteger.

A realidade organizacional alcançou. Pesquisa da OutSystems publicada em 7 de abril de 2026 revelou que 94% das empresas estão preocupadas com o crescimento descontrolado de agentes aumentando complexidade, dívida técnica e risco de segurança. Apenas 12% têm uma plataforma centralizada para gerenciar isso.

Agentes proliferam muito mais rápido que aplicações tradicionais porque são mais fáceis de construir. A propriedade se torna ambígua, capacidades se sobrepõem, e ninguém sabe o que existe. Se você viveu o crescimento descontrolado de microservices em 2018, esse padrão deve parecer familiar.

AWS Agent Registry, lançado em preview em 9 de abril de 2026, é a resposta da AWS para esse problema. É um catálogo privado e governado para agentes, tools, skills, MCP servers e recursos customizados, parte do Amazon Bedrock AgentCore. Times podem registrar recursos manualmente ou apontar o registry para um endpoint MCP ou A2A ativo para descoberta automática de metadados. Registros passam por um workflow de aprovação antes de se tornarem descobríveis. A busca combina entendimento semântico com correspondência por palavras-chave, então uma consulta por “billing tools” pode encontrar uma entrada registrada como “invoicing agent.” O registry em si expõe um endpoint MCP, o que significa que desenvolvedores podem consultá-lo diretamente da IDE sem tocar no AWS SDK.

O AgentCore compreende nove serviços (Runtime, Gateway, Policy, Memory, Identity, Browser, Code Interpreter, Observability e Evaluations), mais o Agent Registry, agora em preview. O registry é a camada de catálogo: ele diz o que existe, quem construiu e se está aprovado. Os outros serviços lidam com execução, segurança e monitoramento.

Neste post, eu percorro o ciclo de vida completo: criar um registry, registrar diferentes tipos de recursos, executar o workflow de aprovação e testar a busca semântica. O objetivo é ver se a experiência justifica o posicionamento de “painel único de controle”, e onde estão as lacunas.

Setup

Configurar o Agent Registry leva cerca de 10 minutos, incluindo aproximadamente um minuto para o registry ficar pronto. Você pode usar tanto o console do AgentCore quanto a CLI. Eu mostro ambos abaixo.

Clone o repositório complementar para acompanhar com os scripts:

git clone https://github.com/fabiodouek/my2centsai-blog-samples.git
cd my2centsai-blog-samples/bedrock-agentcore-registry-demo

Pré-requisitos

• Uma conta AWS em uma região suportada. Eu usei us-east-1. No momento da escrita, as cinco regiões do preview são: US East (N. Virginia), US West (Oregon), Asia Pacific (Sydney), Asia Pacific (Tokyo) e Europe (Ireland).
• AWS CLI v2.34.29+ (suporte para bedrock-agentcore registry)
• Permissões IAM para gerenciar recursos bedrock-agentcore
• jq instalado para parsing de JSON (usado por todos os scripts).
• Python 3.10+ e boto3 1.42.85+ (para rodar o script Python de busca).

Passo 1: Criar um Registry

Um registry é o container de nível superior. Você pode organizar por tipo de recurso, por time, por ambiente (dev/staging/prod) ou manter um único registry para toda a organização.

Opção A: Console

Navegue até o console do AgentCore e selecione Registry na navegação à esquerda. Clique em Create registry e preencha:

• Registry name: Algo descritivo. Eu usei my2cents-demo. Nomes são limitados a 64 caracteres, alfanuméricos com _-./.
• Description: Uma frase sobre o que este registry cobre.
• Authorization type: Selecione Use IAM permissions para autenticar consumidores com credenciais IAM. O registry também suporta autenticação baseada em JWT (via Cognito ou um provedor OAuth 2.0 externo como Okta ou Azure AD) para cenários onde consumidores estão fora da sua organização AWS. Usamos IAM neste walkthrough. Essa escolha não pode ser alterada após a criação.
• Approval settings: Desative a aprovação automática para governança de produção. Quando desativada, um curador deve aprovar cada registro antes que ele se torne descobrível. Ative para ambientes de desenvolvimento onde a fricção é contraproducente.

Clique em Create. O registry transiciona de CREATING para READY em cerca de um minuto.

Opção B: CLI

O script scripts/create-registry.sh encapsula a criação e aguarda o registry ficar pronto:

./scripts/create-registry.sh my2cents-demo IAM us-east-1

O script faz polling de get-registry até o status ser READY e exibe o registry ID que você precisará para os próximos passos. Espere cerca de um minuto de entradas CREATING antes de mudar:

============================================
  Creating Agent Registry
============================================

Registry name: my2cents-demo
Region:        us-east-1
Auth type:     AWS IAM
Auto-approve:  false

[1/2] Creating registry...
  Registry ARN: arn:aws:bedrock-agentcore:us-east-1:123456789012:registry/fOjrUpcMzsFL0lvd
  Registry ID:  fOjrUpcMzsFL0lvd

[2/2] Waiting for registry to become READY...
  Status: CREATING (waiting...)
  ...
  Status: READY

============================================
  Registry created successfully!
============================================

Registry ID: fOjrUpcMzsFL0lvd

Next step: register resources with:
  ./scripts/register-resources.sh fOjrUpcMzsFL0lvd us-east-1

Exporte o registry ID da saída acima para que todos os comandos subsequentes possam referenciá-lo sem copiar e colar:

export REGISTRY_ID=<your-registry-id>  # substitua pelo Registry ID da saída acima

Isso é tudo para o setup. O registry está pronto para receber registros.

Testes: O Ciclo de Vida Completo

Aqui está o plano: registrar três tipos diferentes de recursos (um MCP server, um agente A2A e um skill), passá-los pelo workflow de aprovação, testar auto-sync baseado em URL contra um endpoint MCP ativo, e então testar se a busca semântica consegue de fato encontrá-los.

Registrando Recursos

O script scripts/register-resources.sh registra três tipos de recursos em uma única execução, cada um com schemas específicos do protocolo:

./scripts/register-resources.sh $REGISTRY_ID us-east-1

O script registra:

1. Um MCP server (weather-forecast-mcp): O descriptor segue o schema server.json do MCP Registry (não o InitializeResult do protocolo MCP), com duas definições de tools (get_forecast e get_historical). Veja mcp-server.json e mcp-tools.json.

2. Um agente A2A (invoice-processing-agent): Usa um A2A AgentCard (v0.3) com capabilities, modos de entrada/saída e três skills para extração de invoices, correspondência de ordens de compra e roteamento de aprovação. Veja a2a-agent-card.json.

3. Um agent skill (code-review-skill): Usa documentação em markdown descrevendo um skill de code review automatizado com detecção OWASP Top 10, enforcement de estilo e análise de cobertura de testes. Veja skill-code-review.md.

Cada tipo de recurso usa um tipo de descriptor diferente (MCP, A2A, AGENT_SKILLS), validado contra o schema do protocolo correspondente. O script lê os payloads dos descriptors de scripts/data/, constrói o JSON com jq e chama create-registry-record para cada recurso. Veja o script completo: scripts/register-resources.sh.

Todos os três registros são criados com status DRAFT. Eles ainda não são descobríveis. O script exibe os record IDs que você precisará para o próximo passo:

============================================
  Registering Resources
============================================

Registry ID: fOjrUpcMzsFL0lvd
Region:      us-east-1

[1/3] Registering MCP server: weather-forecast-mcp...
  Record ID: 2OrkdwpJRToD
  Status:    CREATING

[2/3] Registering A2A agent: invoice-processing-agent...
  Record ID: 6hupL9jBddbr
  Status:    CREATING

[3/3] Registering skill: code-review-skill...
  Record ID: l5edOghrKlUd
  Status:    CREATING

============================================
  All resources registered (DRAFT status)
============================================

Record IDs:
  MCP Server: 2OrkdwpJRToD
  A2A Agent:  6hupL9jBddbr
  Skill:      l5edOghrKlUd

Next step: submit for approval with:
  ./scripts/approval-workflow.sh fOjrUpcMzsFL0lvd us-east-1

Navegue até o registry no console do AgentCore e você pode ver os três registros criados, todos em status DRAFT e aguardando aprovação:

O Workflow de Aprovação

O ciclo de vida segue: DRAFT para PENDING_APPROVAL para APPROVED (ou REJECTED). Se a aprovação automática estiver ativada, registros pulam a etapa de pendência e vão direto para APPROVED. Você pode gerenciar aprovações pelo console do AgentCore (selecione um registro e atualize seu status) ou programaticamente via CLI.

O script scripts/approval-workflow.sh lida com submissão e aprovação em uma única execução:

./scripts/approval-workflow.sh $REGISTRY_ID us-east-1

============================================
  Approval Workflow
============================================

Registry ID: fOjrUpcMzsFL0lvd
Region:      us-east-1

[1/3] Listing records in DRAFT status...
  Found 3 records in DRAFT status.

[2/3] Submitting records for approval...
  Submitting: weather-forecast-mcp (2OrkdwpJRToD)...
    Status: PENDING_APPROVAL
  Submitting: invoice-processing-agent (6hupL9jBddbr)...
    Status: PENDING_APPROVAL
  Submitting: code-review-skill (l5edOghrKlUd)...
    Status: PENDING_APPROVAL

[3/3] Approving records...
  Approving: weather-forecast-mcp (2OrkdwpJRToD)...
    Status: APPROVED
  Approving: code-review-skill (l5edOghrKlUd)...
    Status: APPROVED
  Approving: invoice-processing-agent (6hupL9jBddbr)...
    Status: APPROVED

============================================
  All records approved and discoverable!
============================================

Next step: test discovery with:
  ./scripts/discovery.sh fOjrUpcMzsFL0lvd us-east-1

O script faz três coisas:

1. Lista todos os registros em status DRAFT usando list-registry-records
2. Submete cada um para aprovação usando submit-registry-record-for-approval, movendo-os para PENDING_APPROVAL
3. Aprova cada registro usando update-registry-record-status, movendo-os para APPROVED com uma razão de status armazenada como parte da trilha de auditoria

O script também é idempotente: se você executá-lo depois que os registros já estão em PENDING_APPROVAL (por exemplo, se a primeira execução falhou no meio do caminho), ele pula a etapa de submissão e vai direto para a aprovação.

Quando um registro é submetido para aprovação, um evento EventBridge é disparado para o barramento padrão na conta e região. Em um workflow real, você rotearia isso para Lambda, SNS, SQS ou Step Functions para integrar com seu pipeline de aprovação existente. Por exemplo, uma função Lambda poderia postar no Slack com os detalhes do registro e um link de aprovar/rejeitar, ou alimentar um ticket no ServiceNow.

Auto-Sync Baseado em URL

Em vez de registrar metadados manualmente, você pode apontar o registry para um endpoint MCP ativo. O registry busca o descriptor do servidor e as definições de tools automaticamente, e sincroniza novas revisões quando o servidor atualiza.

O script scripts/register-url-sync.sh demonstra isso usando o AWS Knowledge MCP Server, um MCP server remoto publicamente acessível que expõe documentação AWS, exemplos de código e disponibilidade regional via seis tools:

./scripts/register-url-sync.sh $REGISTRY_ID us-east-1

O script chama create-registry-record com --synchronization-type URL e aponta para https://knowledge-mcp.global.api.aws. Como este servidor não requer autenticação, a configuração de sincronização é direta. Nenhum OAuth ou provedor de credenciais é necessário. Para MCP servers privados, você adicionaria um bloco credentialProviderConfigurations com o ARN do seu provedor OAuth. Veja o script completo: scripts/register-url-sync.sh.

============================================
  URL-Based Auto-Sync Registration
============================================

Registry ID: fOjrUpcMzsFL0lvd
Region:      us-east-1

Registering AWS Knowledge MCP Server via URL sync...
  Record ID: 83nOTyuupjEz
  Status:    CREATING

============================================
  URL-sync record created
============================================

The registry will fetch the server descriptor and tool definitions
from https://knowledge-mcp.global.api.aws automatically.

Next step: submit for approval with:
  ./scripts/approval-workflow.sh fOjrUpcMzsFL0lvd us-east-1

O registro é criado em status DRAFT como os recursos registrados manualmente. Execute o workflow de aprovação novamente para submeter e aprovar:

./scripts/approval-workflow.sh $REGISTRY_ID us-east-1

Este é o caminho para escalar. Em vez de copiar metadados manualmente toda vez que um MCP server atualiza suas tools, o registry puxa a definição mais recente e cria uma nova revisão do registro.

Testando a Descoberta

Agora o teste real. Executamos cinco consultas de busca contra o registry para exercitar busca por palavras-chave, semântica e filtrada:

Filtros suportam operadores $eq, $ne, $in, $and e $or nos campos name, descriptorType e version. Isso permite limitar buscas apenas a MCP servers, apenas a agentes ou apenas a skills.

AWS Console

O console do AgentCore inclui uma aba Search records onde você pode executar consultas semânticas ou por palavras-chave, filtrar por tipo de registro e inspecionar resultados inline. Selecionar um registro mostra seus detalhes completos: tipo de descriptor, versão, ARN do registry, tools disponíveis e a definição raw do schema.

CLI

O script scripts/discovery.sh executa todos os cinco testes em uma única execução:

./scripts/discovery.sh $REGISTRY_ID us-east-1

============================================
  Testing Registry Discovery
============================================

Registry ID:  fOjrUpcMzsFL0lvd
Registry ARN: arn:aws:bedrock-agentcore:us-east-1:123456789012:registry/fOjrUpcMzsFL0lvd
Region:       us-east-1

--- Test 1: Keyword Search ---
Query: "weather"

{
  "name": "weather-forecast-mcp",
  "descriptorType": "MCP",

  "description": "MCP server providing weather forecast and historical weather data tools"
}

--- Test 2: Semantic Search ---
Query: "I need something that handles billing and payments"
(No record uses the words 'billing' or 'payments' directly)

{
  "name": "AWSDocumentationMCPProdGateway",
  "descriptorType": "MCP",

  "description": "AWS Knowledge MCP Server - provides AWS documentation, code samples, and regiona"
}
{
  "name": "invoice-processing-agent",
  "descriptorType": "A2A",

  "description": "Autonomous agent that processes invoices, extracts line items, and routes for ap"
}
{
  "name": "code-review-skill",
  "descriptorType": "AGENT_SKILLS",

  "description": "Agent skill for performing automated code reviews with security and style checks"
}
{
  "name": "weather-forecast-mcp",
  "descriptorType": "MCP",

  "description": "MCP server providing weather forecast and historical weather data tools"
}

--- Test 3: Natural Language Query ---
Query: "find tools that help with code quality and security"

{
  "name": "code-review-skill",
  "descriptorType": "AGENT_SKILLS",

  "description": "Agent skill for performing automated code reviews with security and style checks"
}
{
  "name": "AWSDocumentationMCPProdGateway",
  "descriptorType": "MCP",

  "description": "AWS Knowledge MCP Server - provides AWS documentation, code samples, and regiona"
}
{
  "name": "weather-forecast-mcp",
  "descriptorType": "MCP",

  "description": "MCP server providing weather forecast and historical weather data tools"
}
{
  "name": "invoice-processing-agent",
  "descriptorType": "A2A",

  "description": "Autonomous agent that processes invoices, extracts line items, and routes for ap"
}

--- Test 4: Filtered Search (MCP servers only) ---
Query: "forecast" with filter: descriptorType = MCP

{
  "name": "weather-forecast-mcp",
  "descriptorType": "MCP",

  "description": "MCP server providing weather forecast and historical weather data tools"
}

--- Test 5: Filtered Search (skills only) ---
Query: "security review" with filter: descriptorType = AGENT_SKILLS

{
  "name": "code-review-skill",
  "descriptorType": "AGENT_SKILLS",

  "description": "Agent skill for performing automated code reviews with security and style checks"
}

============================================
  Discovery tests complete
============================================

Um detalhe importante: o comando de busca usa o data plane (bedrock-agentcore), não o control plane (bedrock-agentcore-control).

Python

Se você está escrevendo em Python, os planos de controle e dados são clientes boto3 separados. O repositório complementar inclui scripts/search_registry.py que executa os mesmos cinco testes usando o Python SDK:

python scripts/search_registry.py $REGISTRY_ID us-east-1

Registry ARN: arn:aws:bedrock-agentcore:us-east-1:123456789012:registry/fOjrUpcMzsFL0lvd

============================================================
  Test 1: Keyword Search
  Query: "weather"
  Results: 1
============================================================
  - weather-forecast-mcp (MCP)
    MCP server providing weather forecast and historical weather data tools


============================================================
  Test 2: Semantic Search
  Query: "I need something that handles billing and payments"
  Results: 4
============================================================
  - AWSDocumentationMCPProdGateway (MCP)
    AWS Knowledge MCP Server - provides AWS documentation, code samples, and regiona
  - invoice-processing-agent (A2A)
    Autonomous agent that processes invoices, extracts line items, and routes for ap
  - code-review-skill (AGENT_SKILLS)
    Agent skill for performing automated code reviews with security and style checks
  - weather-forecast-mcp (MCP)
    MCP server providing weather forecast and historical weather data tools


============================================================
  Test 3: Natural Language Query
  Query: "find tools that help with code quality and security"
  Results: 4
============================================================
  - code-review-skill (AGENT_SKILLS)
    Agent skill for performing automated code reviews with security and style checks
  - AWSDocumentationMCPProdGateway (MCP)
    AWS Knowledge MCP Server - provides AWS documentation, code samples, and regiona
  - weather-forecast-mcp (MCP)
    MCP server providing weather forecast and historical weather data tools
  - invoice-processing-agent (A2A)
    Autonomous agent that processes invoices, extracts line items, and routes for ap


============================================================
  Test 4: Filtered Search (MCP only)
  Query: "forecast"
  Results: 1
============================================================
  - weather-forecast-mcp (MCP)
    MCP server providing weather forecast and historical weather data tools


============================================================
  Test 5: Filtered Search (skills only)
  Query: "security review"
  Results: 1
============================================================
  - code-review-skill (AGENT_SKILLS)
    Agent skill for performing automated code reviews with security and style checks

O padrão chave no Python SDK é a separação de clientes:

import boto3

# Control plane client: for CRUD operations on registries and records
control = boto3.client('bedrock-agentcore-control', region_name='us-east-1')

# Data plane client: for search operations
data = boto3.client('bedrock-agentcore', region_name='us-east-1')

results = data.search_registry_records(
    registryIds=[registry_arn],
    searchQuery='tools for processing financial documents',
    maxResults=10,
    filters={'descriptorType': {'$eq': 'MCP'}}  # optional
)

O script também demonstra como buscar o ARN completo do registry a partir de um registry ID usando a chamada get_registry do control plane, e como passar filtros de busca programaticamente.

Acesso via MCP Server a partir de IDEs

Cada registry expõe um endpoint MCP que suporta autenticação tanto via IAM quanto OAuth. Isso significa que clientes compatíveis com MCP como Claude Code ou Kiro podem consultar o registry diretamente, sem a AWS CLI ou SDK. Um desenvolvedor pode buscar tools e agentes disponíveis a partir da IDE, descobrir o que já existe e evitar reconstruir capacidades que outro time já publicou.

Para registries baseados em IAM, adicione o seguinte ao seu arquivo de configuração .mcp.json. Ele usa mcp-proxy-for-aws para lidar com a assinatura SigV4. Substitua <REGISTRY_ID> pelo seu registry ID:

{
  "mcpServers": {
    "agentcore-registry": {
      "disabled": false,
      "type": "stdio",
      "command": "uvx",
      "args": [
        "mcp-proxy-for-aws@latest",
        "https://bedrock-agentcore.us-east-1.amazonaws.com/registry/<REGISTRY_ID>/mcp",
        "--service",
        "bedrock-agentcore",
        "--region",
        "us-east-1"
      ]
    }
  }
}

Este é o “painel único de controle” na prática: não um dashboard que você precisa ir olhar, mas um serviço que encontra os desenvolvedores onde eles já trabalham.

Uma vez configurado, você pode pedir ao Claude Code para buscar no registry usando linguagem natural. Ele invoca a tool search_registry_records através do proxy MCP, aplica filtros como descriptorType e retorna os registros correspondentes com suas tools, descrições e status de aprovação, tudo sem sair do terminal:

Preços

Durante o período de preview, Agent Registry é gratuito. Sem cobranças para criar registries, registrar records ou executar buscas.

Veredito

O Que Funciona

O workflow de aprovação é a primitiva correta. Draft para pendente para aprovado é simples o suficiente para entender e flexível o suficiente para integrar com sistemas existentes via EventBridge. Aprovação automática para dev, revisão manual para produção. É assim que governança deveria funcionar: fricção configurável, não burocracia generalizada.

Busca semântica é um diferencial genuíno. Consultar “billing tools” e encontrar um “invoicing agent” é mais útil do que correspondência apenas por palavras-chave. Para organizações com centenas de recursos registrados, isso previne o registry de se tornar mais uma planilha impossível de buscar.

Endpoint MCP por registry é inteligente. Tornar o registry em si consultável via MCP significa que ele encontra os desenvolvedores na IDE. Sem trocar de aba no console, sem encantamento de AWS CLI. Este é o detalhe que torna o posicionamento de “painel único de controle” acreditável.

O modelo de recursos é flexível. Suportar MCP servers, agentes A2A, skills e recursos customizados no mesmo catálogo significa que você não precisa de sistemas de rastreamento separados para diferentes padrões de agentes. Conforme o ecossistema muda entre protocolos e abordagens, o registry pode absorver o que vier a seguir.

Gratuito durante o preview com suporte real de CLI/SDK. Doze comandos de control plane e uma API de busca totalmente funcional no primeiro dia. Este não é um preview apenas de console onde você clica em um wizard e espera por uma API. Você pode scriptizar e automatizar tudo.

O Que Não Funciona

Sem suporte a Infrastructure-as-Code. Sem CloudFormation, sem Terraform, sem suporte CDK para registries ou registry records. Se seu time usa workflows GitOps, você não pode declarar registries como código hoje. A API existe no boto3 e na CLI, mas a lacuna de IaC bloqueia padrões de adoção enterprise. Esta é uma limitação do preview que deve ser resolvida antes do GA.

Cinco registries por conta por região. A cota padrão é de 5 registries, e embora ajustável, isso força planejamento cuidadoso para organizações com muitos times. Um modelo de um registry por time quebra rapidamente em escala.

Busca limitada a um registry por chamada. O comando search-registry-records aceita um parâmetro registry-ids mas atualmente limita a um único ARN de registry. Busca cross-registry, crítica para organizações que dividem registries por time ou ambiente, não está disponível ainda.

Busca semântica carece de transparência. A API de busca não retorna um score de relevância, e nos nossos testes ela retornou registros que parecem não ter relação com a consulta. Uma busca por “billing and payments” trouxe um MCP server de previsão do tempo junto com o esperado agente de processamento de invoices. Sem um score ou um limiar mínimo de relevância, consumidores não conseguem distinguir correspondências fortes de ruído. Isso enfraquece o posicionamento de “busca semântica como diferencial” até que a AWS adicione scoring ou filtragem por relevância.

Afirmações de cloud-agnostic precisam de um asterisco. A AWS posiciona o registry como capaz de catalogar agentes de qualquer cloud ou ambiente on-premises. Na prática, agentes que não expõem endpoints MCP ou A2A requerem registro manual. Dewan da Avasant alerta que capacidades de descoberta cross-cloud “ainda não estão claramente estabelecidas.” O registry pode armazenar metadados sobre qualquer coisa, mas a descoberta automática é limitada a endpoints compatíveis com padrões.

Quem Deveria Usar

Organizações com uma frota crescente de agentes, MCP servers, skills e tools espalhados entre múltiplos times. Se você já está na AWS e ninguém consegue responder “quantos agentes temos em produção?” vale a pena avaliar. O período de preview gratuito elimina o risco financeiro. O suporte de CLI/SDK significa que você pode automatizar a avaliação.

Funcionalidades Que Eu Gostaria de Ver Implementadas

O registry resolve bem a pergunta “o que existe?”. Mas usá-lo por algumas horas revela uma lista de funcionalidades que o transformariam de um catálogo útil em algo que empresas realmente padronizariam:

Um console web rico. O console do AgentCore permite criar um registry e navegar nos registros, mas a experiência é funcional no máximo. Eu quero um dashboard dedicado do registry: contagens de registros por tipo, status da fila de aprovação, registros recentes, tendências de uso de busca. Algo que faça “painel único de controle” parecer literal, não aspiracional.

Avaliações e analytics de uso. Quando você registra 50 agentes, alguém vai perguntar “quais são realmente bons?” O registry não tem mecanismo para consumidores avaliarem recursos, deixarem reviews ou sinalizarem qualidade. Combine isso com analytics de uso (quais registros são buscados, quais são recuperados) e você tem um flywheel: recursos populares aparecem naturalmente, os abandonados são sinalizados para depreciação.

Conformidade de marketplace para agentes de código. Claude Code, GitHub Copilot e Cursor todos têm especificações de marketplace de plugins com metadados estruturados (capabilities, verificação de autor, fixação de versão). Os tipos de descriptor CUSTOM e AGENT_SKILLS do registry podem armazenar esses metadados, mas não há validação embutida de que um registro está em conformidade com uma spec de marketplace. Eu quero enforcement de schema no nível do registry: se um registro afirma ser um plugin de Claude Code, verificar se tem os campos obrigatórios antes de aprová-lo.

Sincronização com GitHub para repositórios de marketplace. Auto-sync baseado em URL funciona para endpoints MCP e A2A ativos, mas os ecossistemas de plugins de crescimento mais rápido vivem em repositórios Git com diretórios .claude-plugin/ ou .cursor-plugin/. Eu quero apontar o registry para um repositório de marketplace no GitHub e ter ele auto-descobrindo e registrando cada plugin, atualizando registros quando novas versões são tagueadas. Isso é alcançável com um script Python que lê metadados de plugins de um repositório Git e chama create-registry-record para cada plugin descoberto, mas deveria ser uma funcionalidade nativa do registry.

Controle de acesso granular para descoberta. Hoje, todo registro aprovado é descobrível por todo usuário autorizado. Na prática, o agente scanner de vulnerabilidades interno do time de segurança não deveria aparecer nos mesmos resultados de busca que o gerador de conteúdo do time de marketing. Eu quero busca com escopo RBAC: taguear registros com times, projetos ou níveis de classificação, e ter resultados de busca respeitando as permissões do chamador. Políticas Cedar já lidam com autorização de execução de agentes; estenda-as para descoberta.

Detecção de duplicatas e sobreposições. Organizações rotineiramente acabam com MCP servers sobrepostos e skills duplicados registrados por times diferentes. Busca semântica ajuda, mas é reativa. Eu quero que o registry sinalize duplicatas potenciais durante o registro: “As capacidades deste MCP server se sobrepõem 85% com weather-forecast-mcp registrado pelo Time Alpha. Considere reutilizar aquele registro.”

Semântica de descoberta de versões. Registros suportam um campo de versão, mas a documentação não explica como múltiplas versões coexistem, se clientes podem solicitar um range específico de versões ou o que acontece quando uma nova versão é registrada junto com uma antiga. O npm resolveu isso há uma década. Registries de agentes precisam do mesmo: restrições semver, resolução de latest-stable e timelines claras de depreciação até remoção.

Scanning de vulnerabilidades para recursos registrados. O registry aceita descriptors de MCP servers, agent cards A2A e definições de skills pelo valor de face. Eu quero que o registry escaneie esses descriptors durante o registro: verificar schemas de entrada de tools contra padrões de injeção, sinalizar declarações de capacidade excessivamente permissivas e validar que URLs de endpoints resolvem para domínios esperados. Integrar ao workflow de aprovação para que curadores vejam uma avaliação de segurança junto com cada submissão, não apenas metadados.

Templates de Infrastructure-as-Code. A lacuna de IaC já é um ponto de dor (sem CloudFormation, Terraform ou CDK), mas além de definições básicas de recursos, eu quero templates de registry records. Definir um padrão organizacional para como MCP servers ou skills devem ser registrados (campos obrigatórios, convenções de nomenclatura, políticas de aprovação) e enforcement no momento da criação. É assim que você previne o crescimento descontrolado do registry dentro do próprio registry.

Suporte KMS para criptografia em repouso. O registry armazena metadados sobre o cenário de agentes de uma organização: nomes, descrições, URLs de endpoints e declarações de capacidades. Não há opção para criptografar dados do registry com uma chave KMS gerenciada pelo cliente. Para indústrias reguladas que requerem controle sobre chaves de criptografia, isso é um bloqueador.

Domínios customizados para endpoints do registry. O endpoint MCP do registry usa uma URL gerada pela AWS. Organizações que querem expor o registry sob seu próprio domínio (por exemplo, registry.internal.acme.com) não têm como fazer isso. Domínios customizados fariam o registry parecer um serviço interno em vez de um recurso gerenciado pela AWS, e simplificariam configurações de firewall e DNS.

Namespaces para segregação de times e unidades de negócio. O modelo atual é flat: todos os registros em um registry compartilham o mesmo namespace. Com o limite de cinco registries por conta, organizações não podem realisticamente criar um registry por time. Namespaces dentro de um registry permitiriam que times gerenciem seus próprios registros sem pisar nos dos outros, enquanto ainda possibilitam busca cross-namespace para descoberta organizacional.

Federação de registries. Uma empresa rodando agentes em múltiplas contas AWS, regiões ou provedores de cloud precisa de uma visão única de tudo. Hoje, cada registry é isolado. Não há busca cross-registry e nenhum catálogo compartilhado. Federação permitiria que organizações conectem registries entre si, habilitando consultas que abrangem contas e regiões sem duplicar registros.

Mensagens de erro melhores durante importação de recursos. Quando um descriptor não está em conformidade com o schema esperado (por exemplo, um A2A AgentCard faltando um campo obrigatório), a API retorna um erro genérico de validação. A mensagem de erro não indica qual campo falhou ou qual é o formato esperado. Mensagens de erro específicas e acionáveis economizariam tempo significativo de debugging durante o registro.

Status de saúde para servidores ativos. Registros sincronizados por URL apontam para endpoints MCP e A2A ativos, mas o registry não tem visibilidade sobre se esses endpoints estão realmente rodando. Eu quero que o registry periodicamente verifique a saúde dos endpoints e mostre o status no console e nos resultados de busca. Um registro apontando para um servidor inativo é pior do que nenhum registro.

Melhorias na busca semântica. Como observado na seção de testes, a API de busca não expõe scores de relevância e retorna resultados que parecem não ter relação com a consulta. Adicionar um score à resposta, implementar um limiar mínimo de relevância e fornecer opções para controlar a precisão dos resultados tornariam a busca semântica um mecanismo de descoberta confiável em vez de uma estimativa de melhor esforço.

O Quadro Geral

Governança de agentes está passando pelo mesmo ciclo que gerenciamento de APIs passou há uma década: primeiro você constrói, depois prolifera descontroladamente, depois tenta impor ordem após o fato. O Gartner prevê que mais de 40% dos projetos de IA agêntica serão cancelados até 2027 devido a custos crescentes, valor de negócio incerto ou controles de risco inadequados. As organizações que estabelecerem infraestrutura de governança antes que o crescimento descontrolado se torne ingerenciável terão uma vantagem significativa.

A comunidade de segurança está certa de que um registry sozinho não é suficiente. Saber quais agentes existem não diz o que eles têm permissão para fazer. A AWS parece entender isso: AgentCore Policy (baseado em Cedar, GA desde março de 2026) lida com a camada de enforcement, enquanto o registry lida com descoberta. Juntos eles cobrem “o que existe” e “o que pode fazer.” Separadamente, nenhum é suficiente.

Por $0 durante o preview, o investimento é seu tempo. Cerca de dez minutos para configurar. Algumas horas para registrar seus recursos existentes e ver como é a experiência de busca. Se a busca semântica revelar conexões que você não sabia que existiam no cenário de agentes do seu time, o registry já terá justificado o esforço.

Limpeza

Remova os recursos de demonstração quando terminar:

./scripts/cleanup.sh $REGISTRY_ID us-east-1

O script lista todos os registros no registry, deleta cada um e então deleta o registry em si. Registros devem ser deletados antes do registry, já que um registry com registros existentes não pode ser deletado.