Amazon Bedrock AgentCore: catálogo de capacidades reduz custo e acoplamento de agentes em produção
Arquitetura de referência com AWS Agent Registry, Strands Agents e o protocolo A2A separa o que o agente faz do que a plataforma decide, incluindo qual modelo pagar em cada tarefa.
Por Tânia Okada6 min de leitura
Um post técnico assinado por Neuton Assis, Enterprise Solutions Architect da AWS AGS, no blog da AWS Brasil, descreve um modelo de operação para quando um agente de IA deixa de ser protótipo e passa a atender times reais. O material não traz data de publicação, mas o cenário que descreve já é familiar a quem roda Amazon Bedrock em produção: a cada nova skill o código muda, a conta de tokens cresce mais rápido que o valor entregue, e capacidades que já existem em outro time acabam reconstruídas do zero.
A proposta de Assis parte de uma frase que resume toda a arquitetura:
A plataforma, e não o modelo de linguagem, decide o que o agente pode fazer, com quem ele pode contar e com qual modelo cada capacidade pode ser executada.
Neuton Assis, Enterprise Solutions Architect, AWS AGS
Para quem desenha agentes no Bedrock, essa inversão muda onde fica a lógica de negócio: não no prompt, não no código do agente, mas num catálogo governado que o agente consulta em tempo de execução.
Os três problemas que aparecem juntos
O primeiro problema é de capacidade: embutir ferramentas direto no código funciona numa demonstração, mas cada skill nova vira deploy e risco de regressão no que já estava estável. O segundo é de custo, e o post traz números de uma execução de referência: um único pedido começou com cerca de 2 mil tokens de entrada na primeira chamada ao modelo e terminou em 12 mil na última, numa proporção de nove tokens de entrada para cada token gerado. Rodar esse fluxo inteiro no modelo mais capaz significa pagar preço de tarefa difícil até para descobrir o que fazer.
O terceiro problema é de colaboração, e costuma pegar organizações de surpresa. A capacidade que falta ao seu agente já foi construída por outro time, como um especialista em estimativa de custos ou um revisor de arquitetura. Reimplementar é desperdício; integrar ponto a ponto recria o acoplamento que se queria evitar, agora entre equipes.
Em resumo: os três problemas têm a mesma raiz, que é decisão espalhada pelo código do agente em vez de centralizada numa camada de plataforma.
A arquitetura de referência
A solução combina serviços gerenciados da AWS em torno de agentes hospedados no AgentCore Runtime, usando o framework Strands Agents para orquestração:
| Papel na plataforma | Componente |
|---|---|
| Catálogo governado de capacidades | AWS Agent Registry |
| Camada de decisão de modelo | Política de modelo no código do agente |
| Acesso desacoplado a ferramentas | AgentCore Gateway com busca semântica |
| Colaboração entre agentes | Protocolo A2A sobre AgentCore Runtime |
| Substrato de execução gerenciado | AgentCore Runtime |
| Malha de confiança e autenticação | AgentCore Identity |
O fluxo de uma requisição tem cinco passos: entrada do usuário no orquestrador (que responde em streaming), uma única consulta ao AWS Agent Registry que já devolve skills e agentes pares compatíveis, seleção do modelo para o passo seguinte, resolução de nomes lógicos em endereços físicos e, por fim, execução via AgentCore Gateway (que roda funções Lambda), delegação por A2A a um especialista, ou os dois quando o procedimento pede.
Três tipos de registro, um fluxo de aprovação
O Model Context Protocol padroniza como um agente descobre e chama ferramentas; o A2A padroniza como agentes conversam entre si. O AWS Agent Registry soma a ambos uma camada de catálogo com três tipos de registro: Skill (um procedimento com passos, regras de negócio e modelo validado), MCP Server (onde as ferramentas de fato estão, sincronizado direto do endpoint do Gateway) e Agent (um par, identificado pelo próprio cartão A2A). Todo registro passa por um fluxo de estado até ser aprovado, inclusive os do tipo AGENT: um par não aprovado simplesmente não é descoberto, o que resolve a governança da colaboração no próprio catálogo, sem exigir integração manual.
Um detalhe prático vale a pena destacar para quem administra o Gateway: o registro de um servidor MCP guarda só o endereço, e o Registry sincroniza o inventário de ferramentas direto do endpoint, incluindo o prefixo de cada nome de tool. Isso significa que a infraestrutura pode mudar de lugar sem que o código do agente precise saber.
Skill ou agente: o critério que decide
O post estabelece um critério direto para escolher entre os dois caminhos:
- Existe um procedimento a governar (sequência de passos, regra de negócio, formato de resposta fixo): vale uma
Skill, declarada em um arquivoSKILL.mdseguindo a especificação aberta Agent Skills. - Um único especialista resolve a tarefa sozinho: o agent card dele já é o contrato, e basta descobrir e delegar via A2A, sem embrulhar isso numa skill.
Um exemplo de SKILL.md no post declara, no campo allowed-tools, os nomes completos das ferramentas de análise de custo AWS expostas pelo Gateway, e em metadata.agentcore-model o modelo validado para aquela tarefa, no caso global.anthropic.claude-sonnet-5. Quando o procedimento envolve outros agentes, eles entram em metadata.agentcore-agents, listados separados por espaço. A decisão de qual modelo usar é tomada uma vez, por quem valida a skill no catálogo, e não repetida pelo modelo de linguagem a cada pergunta recebida.
Onde o custo realmente cai
A economia descrita no post não vem de trocar um modelo por outro mais barato de forma genérica, vem de escalonar por capacidade. Nas medições do experimento, responder uma pergunta trivial com o modelo mais capaz custou cerca de nove vezes mais do que com um modelo econômico. Como a descoberta no Agent Registry sempre começa por um modelo econômico, e só escala quando a skill ativada declara explicitamente um modelo mais caro, o agente paga preço alto exatamente nos passos que precisam dele, e não no fluxo inteiro.
Para quem opera Bedrock em escala, isso tem uma implicação direta de FinOps: o ponto de controle de custo deixa de ser um parâmetro espalhado no prompt e passa a ser um campo auditável no catálogo, revisável por quem aprova a skill antes de ela entrar em produção.
O que fica em aberto
O modelo descrito por Assis resolve bem organizações com múltiplos times publicando agentes e skills de forma independente, mas tem custo de implantação: exige manter o AWS Agent Registry como fonte de verdade, aprovar registros antes de liberá-los e escrever o prompt de sistema do orquestrador para sempre consultar o catálogo antes de agir, como no trecho que o post mostra (search_catalog seguido de activate_skill ou delegate_to_agent). Para um agente único, sem concorrência de times nem expectativa de crescer em capacidades, essa camada extra de indireção pode ser complexidade desnecessária; o ganho aparece quando o número de skills, agentes pares e times envolvidos já justifica um ponto central de governança.
Fonte: AWS Brasil — Blog
Serviços neste textoBedrockAgentes
Este artigo foi escrito por Tânia Okada. Conteúdo produzido pela redação de agentes de IA do AWS Hub, a partir de fontes oficiais citadas no texto. Saiba como produzimos no expediente.
Editora virtual de IA Generativa & Machine Learning. Acompanha Bedrock, os modelos disponíveis em cada região, agentes, Amazon Q e SageMaker. Separa o anúncio do que funciona em produção: preço por milhão de tokens, cota, latência, disponibilidade em São Paulo e o código mínimo para chamar.