# ADR: levar agentes governados para o Amazon Quick

A integração entre Amazon Quick e AWS Agent Registry muda o ponto de controle: o problema deixa de ser conectar cada MCP manualmente e passa a ser governar um catálogo consumível por usuários de negócio. Eu trataria isso como uma decisão de plataforma, não como uma conveniência de console.

- URL: https://fernando.moretes.com/blog/adr-levar-agentes-governados-para-o-amazon-quick-aws-agent-re

- Markdown: https://fernando.moretes.com/blog/adr-levar-agentes-governados-para-o-amazon-quick-aws-agent-re/article.md?lang=pt

- Published: 2026-09-01T20:19:15.371Z

- Category: IA & Agentes

- Tags: AWS, Agent Registry, Amazon Quick, MCP, Bedrock AgentCore, Governance, ADR, Enterprise AI

- Reading time: 7 min

- Source: [AWS Agent Registry agents and MCP servers now available in Amazon Quick](https://aws.amazon.com/about-aws/whats-new/2026/08/aws-agent-registry-agents-mcp-servers-quick/)

---

Minha decisão seria adotar o AWS Agent Registry como o catálogo governado para agentes e servidores MCP expostos ao Amazon Quick, mas somente depois de separar com clareza três responsabilidades: publicação técnica, curadoria de risco e consumo por usuários de negócio. O anúncio de 31 de agosto de 2026 parece pequeno porque fala de descoberta e configuração preenchida automaticamente. Na prática, ele desloca a arquitetura de agentes de um modelo artesanal, onde cada time cola uma URL MCP em uma ferramenta, para um modelo de plataforma, onde o catálogo passa a ser o plano de controle operacional.

## Contexto: o acoplamento saiu do código e foi para o catálogo

Em ambientes financeiros, o primeiro ciclo de agentes costuma ser produtivo e perigoso ao mesmo tempo. Um time cria um servidor MCP para consultar tickets, outro publica uma ferramenta para buscar contratos, um terceiro conecta uma API interna de risco de crédito, e logo existe uma coleção de endpoints com donos, escopos, credenciais e versões pouco visíveis. O problema não é MCP em si. O problema é a ausência de inventário confiável quando esses servidores começam a virar superfície operacional.

A novidade do Amazon Quick é tornar esse inventário diretamente consumível por usuários no mesmo espaço onde eles conversam, constroem apps, automatizam fluxos e fazem pesquisa. O AWS Agent Registry já oferecia catálogo, busca híbrida, aprovação, registros de MCP, agentes, skills e recursos customizados. A integração com Quick adiciona o último metro: um usuário pode encontrar um recurso aprovado e criar um conector com detalhes já preenchidos, em vez de depender de um wiki, de uma issue ou de uma mensagem de Slack com a URL certa.

A força arquitetural principal é governança sem atrito excessivo. Se eu deixar cada área conectar MCPs diretamente no Quick, ganho velocidade local e perco rastreabilidade. Se eu centralizar demais, crio fila e incentivo bypass. O registro governado é o meio-termo: publicação distribuída, descoberta centralizada, aprovação explícita e consumo próximo do trabalho.

## Opções consideradas

### Conectar MCPs diretamente no Quick por time

**Pros**
- Menor tempo inicial para protótipos e automações locais.
- Baixa dependência de um time central de plataforma.

**Cons**
- Inventário fraco, donos pouco claros e duplicação de conectores.
- Difícil provar quem aprovou um MCP, qual versão estava ativa e qual escopo foi compartilhado.

**Verdict:** Aceitável para laboratório; inadequado para uso regulado.

### Bloquear Quick e consumir agentes apenas por aplicações internas

**Pros**
- Controle máximo sobre UX, autenticação, telemetria e fluxo de aprovação.
- Permite políticas específicas por domínio crítico.

**Cons**
- Aumenta custo de produto interno e reduz adoção por usuários de negócio.
- Duplica recursos que Quick já oferece: chat, apps, flows, research e compartilhamento.

**Verdict:** Útil para fluxos de altíssimo risco, mas caro como padrão corporativo.

### Usar AWS Agent Registry como catálogo aprovado para Quick

**Pros**
- Mantém um ponto de verdade para MCPs e agentes descobertos no Quick.
- Aproveita aprovação, busca, CloudTrail, tags, IaC e compartilhamento por AWS RAM onde aplicável.
- Reduz configuração manual sem remover a necessidade de autenticação e permissão por usuário.

**Cons**
- Exige maturidade de curadoria, versionamento e descontinuação de registros.
- Quick suporta apenas certos descritores MCP nessa integração, então A2A e endpoints locais ficam fora.

**Verdict:** Minha escolha para uma plataforma corporativa de agentes.

## Decisão: tratar o registro como plano de controle, não como lista de links

Eu decidiria por um registro por ambiente operacional relevante, começando com produção e não com dezenas de catálogos por squad. O AWS Agent Registry permite organizar registros por tipo, estágio, time ou unidade de negócio, mas em uma organização grande a fragmentação cedo demais destrói a descoberta. Para Quick, eu começaria com um registro regional e de conta alinhado ao próprio Quick, porque a documentação da integração exige mesma conta e mesma Região, registro em estado READY, autorização AWS_IAM com SigV4, namespace agent-registry e apenas um registro ativo por conta Quick.

Isso tem uma consequência importante: se a empresa tem múltiplas contas produtoras de agentes, a decisão não é simplesmente técnica. É uma decisão de governança multi-conta. A disponibilidade geral do Agent Registry menciona compartilhamento com AWS RAM e detecção automática de AgentCore Runtime e Gateway pela organização, mas a integração do Quick impõe o limite prático do consumo na conta e Região do Quick. Eu desenharia a topologia com uma conta de plataforma para curadoria e uma conta Quick por domínio somente quando houver justificativa regulatória ou de segregação de dados.

O registro não deve ser preenchido por entusiasmo. Cada registro precisa carregar nome estável, versão, dono, classe de dado, política de autenticação, runbook, SLO esperado e tags de domínio. Sem isso, o catálogo vira uma vitrine bonita para acoplamento invisível.

## Fluxo decidido: publicar, aprovar, descobrir e compartilhar

O desenho centraliza descoberta e aprovação no Agent Registry, enquanto o Quick continua sendo a experiência de consumo para chat, agents, apps, flows e research.

### 🛠️ Engenharia — Publicação

- Servidor MCP remoto API interna ou AgentCore Gateway (compute)
- Registro versionado mcpServer descriptor (data)

### 🟧 AWS — Catálogo governado

- AWS Agent Registry READY, AWS_IAM, SigV4 (ai)
- Curadoria aprovar, rejeitar, depreciar (security)
- CloudTrail + tags trilha e ownership (security)

### 💼 Amazon Quick — Consumo

- Admin Quick vincula um registry (user)
- Custom MCP connector detalhes pré-preenchidos (frontend)
- Times de negócio chat, agents, apps, flows, research (user)

### Fluxos

- mcp -> record: descreve endpoint e ferramentas
- record -> registry: publica versão
- registry -> approval: submete para aprovação
- approval -> registry: torna descobrível
- registry -> audit: registra APIs
- admin -> registry: vincula na mesma conta e Região
- registry -> connector: carrega MCPs aprovados
- connector -> team: compartilha uso governado

## Forças: identidade, escopo e o risco de automação invisível

A decisão mais sensível não é a busca semântica no catálogo; é o caminho de autorização entre usuário, Quick, conector e servidor MCP. A documentação do Quick indica que o Agent Registry não armazena credenciais de autenticação do conector; cada usuário autentica ou fornece credenciais conforme o setup do conector. Isso é correto para ambientes onde uma consulta de conta, uma atualização de ticket ou uma geração de relatório precisa refletir a identidade real do usuário, não uma identidade genérica de automação.

Eu evitaria conectores de serviço para operações mutáveis em domínios financeiros, salvo quando houver uma camada explícita de autorização de negócio por trás. Para leitura, ainda exigiria escopos mínimos e segmentação por domínio. Para escrita, eu colocaria idempotency key obrigatória, validação de payload, limite de taxa por usuário e confirmação humana nos comandos que movem dinheiro, alteram cadastro crítico, mudam parâmetros de risco ou impactam atendimento regulado.

O design do servidor MCP precisa ser tão rigoroso quanto uma API pública interna. Tool names devem ser estáveis; schemas devem rejeitar campos extras; respostas devem carregar correlation id; timeouts devem ser menores que o tempo máximo de interação aceitável no Quick. Como referência operacional, eu miraria p95 abaixo de 2 segundos para leitura simples, 5 a 10 segundos para agregações, e execução assíncrona com Step Functions ou fila para qualquer trabalho que ultrapasse isso.

## Modelo operacional: versionar agentes como produtos internos

Um catálogo de agentes só funciona se o ciclo de vida for explícito. Eu definiria estados parecidos com draft, approved, deprecated e revoked, mesmo quando parte disso já aparece como fluxo nativo do registro. Draft é publicação técnica ainda não consumível. Approved exige revisão de segurança, dono de negócio, evidência de teste e classificação de dados. Deprecated mantém compatibilidade por janela definida. Revoked remove descoberta imediatamente quando há incidente, perda de owner ou mudança de escopo.

A versão do registro precisa significar contrato, não release notes decorativas. Se um MCP muda o schema de uma ferramenta, altera semântica de autorização ou passa a executar uma escrita onde antes só lia, isso é nova versão e nova aprovação. Eu usaria nomes como domain/capability e versões semânticas quando o contrato é consumido por vários agentes. Tags devem carregar domain, data-classification, environment, owner, cost-center e criticality. Em contas AWS, isso conversa com IAM conditions e com relatórios de governança, mesmo quando o usuário final só enxerga um conector no Quick.

Para observabilidade, eu exigiria três trilhas. CloudTrail para APIs de controle do Registry. Logs estruturados do MCP com tenant, user-subject pseudonimizado, tool, registry-record-version, latency, outcome e correlation id. Métricas por ferramenta no CloudWatch ou Datadog: invocation count, error rate, p95, timeout rate, auth failures e deny decisions. Sem essas trilhas, a plataforma não consegue diferenciar adoção saudável de automação fora de controle.

> **Consequência arquitetural:** A integração não transforma todo agente registrado em um recurso automaticamente seguro para negócio. A documentação do Quick limita o suporte a registros MCP com descritor mcpServer, servidores remotos com URL e requisitos específicos de conta, Região, namespace, estado READY e autorização AWS_IAM. Skills, registros customizados, descritores A2A, endpoints locais como stdio, docker ou npx, e registries com JWT não devem ser tratados como disponíveis nessa trilha. Eu também validaria a Região no console antes de rollout, porque as páginas públicas de lançamento do mesmo dia apresentam listas regionais com diferença entre o anúncio geral do Registry e o anúncio específico do Quick.

## Implementação de referência para uma organização regulada

Minha implementação de referência começaria pequena: um registro de produção na Região onde Quick e AgentCore estão disponíveis para o domínio, vinculado por um administrador no caminho Manage account, Permissions, AWS Agent Registry. A política mínima para o papel gerenciado ou customizado do Quick precisa permitir leitura e busca de registros descobríveis, incluindo agent-registry:SearchDiscoverableRegistryRecords e agent-registry:GetDiscoverableRegistryRecord; administradores também precisam listar e visualizar registries para o setup aparecer.

Os servidores MCP ficariam atrás de AgentCore Gateway quando houver necessidade de transformar APIs, Lambda ou serviços existentes em ferramentas com autenticação de entrada e saída mais governada. Para APIs internas sensíveis, eu preferiria VPC, PrivateLink ou conectividade privada quando suportada pelo padrão de integração. A documentação do Quick MCP também permite servidores privados alcançáveis por conexão VPC do Quick, mas exige que endpoints OAuth usados pelo MCP sejam públicos; isso precisa entrar na revisão de segurança, porque muitas empresas assumem erroneamente que todo o caminho de autenticação pode ficar privado.

No backend, DynamoDB pode armazenar estado de idempotência com partition key userId#toolName e sort key idempotencyKey, TTL de 24 a 72 horas e condição attribute_not_exists na primeira execução. Step Functions deve orquestrar operações longas com retries explícitos, backoff e compensação. S3 com SSE-KMS guarda evidências não sensíveis de execução. O segredo é não colocar lógica de risco no prompt: autorização, validação e trilha ficam em código e política.

## Leitura Well-Architected

- **security**: Use identidade do usuário sempre que a ação representar privilégio humano. Restrinja IAM do Quick ao mínimo necessário para descoberta, valide escopos OAuth no MCP, separe leitura de escrita e registre decisões de negação. O catálogo reduz shadow AI, mas só vira controle real quando aprovação, tags, CloudTrail e logs de ferramenta são obrigatórios.
- **reliability**: Trate cada tool call como uma chamada distribuída falível. Defina timeouts, retry com jitter, idempotência, circuit breaker para dependências instáveis e resposta degradada quando o sistema de origem estiver indisponível. Um conector compartilhado no Quick pode multiplicar tráfego rapidamente.

## Antipadrões que eu bloquearia

- Registrar MCP sem owner técnico e owner de negócio.
- Expor operações de escrita com credencial compartilhada e sem idempotência.
- Usar descrição de ferramenta como substituto de política de autorização.
- Aprovar conectores por conveniência sem classificar dados e impacto operacional.
- Manter versões antigas descobríveis sem data de descontinuação.

> **Nota de curadoria:** Eu adotaria essa integração, mas começaria com três conectores de leitura e um único fluxo de escrita de baixo risco. Minha experiência é que catálogos corporativos falham quando tentam catalogar tudo antes de provar o modelo operacional. O primeiro objetivo não é quantidade de agentes; é provar que publicação, aprovação, observabilidade e revogação funcionam sem reunião emergencial. Depois disso, escalar vira engenharia, não esperança.

## Referências

- [AWS What's New: AWS Agent Registry agents and MCP servers now available in Amazon Quick](https://aws.amazon.com/about-aws/whats-new/2026/08/aws-agent-registry-agents-mcp-servers-quick/)
- [Amazon Quick User Guide: Amazon Agent Registry integration](https://docs.amazonaws.cn/en_us/quick/latest/userguide/aws-agent-registry-integration.html)
- [Amazon Bedrock AgentCore: AWS Agent Registry overview](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/registry.html)
- [Amazon Bedrock AgentCore: Using the Registry MCP endpoint](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/registry-mcp-endpoint.html)
- [AWS What's New: AWS Agent Registry generally available](https://aws.amazon.com/about-aws/whats-new/2026/08/aws-agent-registry-generally-available/)
- [AWS Machine Learning Blog: Manage agents, tools and skills at scale with AWS Agent Registry](https://aws.amazon.com/blogs/machine-learning/manage-agents-tools-and-skills-at-scale-with-aws-agent-registry/)
- [Amazon Quick User Guide: Model Context Protocol integration](https://docs.aws.amazon.com/quick/latest/userguide/mcp-integration.html)
- [Amazon Bedrock AgentCore: Use an AgentCore gateway](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-using.html)

## Veredito

Minha recomendação é aprovar o uso do AWS Agent Registry como catálogo governado para recursos consumidos no Amazon Quick, com rollout controlado por domínio, registros versionados, curadoria obrigatória e telemetria por ferramenta. Eu não aprovaria a adoção como simples atalho de configuração de MCP. O valor real está em transformar agentes e servidores MCP em produtos internos descobríveis, auditáveis e revogáveis, sem afastar o usuário de negócio do ambiente onde ele trabalha.

**Rating:** adopt-with-guardrails