Um post do AWS Machine Learning Blog publicado em 09.11.2026 apresenta o Pluggable Agentic AI Framework, uma arquitetura de referência componível organizada em sete camadas e projetada para levar aplicações de IA multiagente do protótipo à escala de produção no Amazon Bedrock AgentCore.
O post começa com as perguntas que uma prova de conceito não consegue responder: como lidar com milhares de solicitações simultâneas de usuários com segurança, como manter os agentes confiáveis sob tráfego real em vez de falharem silenciosamente, como saber se um agente ainda atende aos padrões de qualidade e segurança que passou durante os testes e quais comportamentos do agente devem ser determinísticos ou não determinísticos. Os autores argumentam que a lacuna entre um protótipo funcional e um sistema que opera de forma confiável, segura, econômica e responsável em escala é onde a maioria das iniciativas de IA agêntica estagna, e que raramente é culpa do modelo. As equipes tendem a reconstruir o mesmo scaffolding, incluindo lógica de roteamento, guardrails e observabilidade, aplicado depois do fato em vez de projetado desde o início.
As sete camadas
Cada camada tem uma responsabilidade distinta e um contrato estável. Os serviços nomeados em cada camada refletem a implementação de referência, e não escolhas obrigatórias; as organizações podem substituir alternativas alinhadas à sua infraestrutura e requisitos.
Dados e Conhecimento. Esta camada de fundação é responsável pela recuperação, embeddings e acesso a dados estruturados e não estruturados por meio de um contrato que aceita uma consulta e retorna as informações mais relevantes como contexto para o agente. Os blocos de construção de exemplo incluem Amazon Bedrock Knowledge Base, Vector Engine for Amazon OpenSearch Serverless, Amazon S3 Vectors e Amazon DynamoDB.
Modelo e Inferência. A escolha do modelo deve ser guiada por configuração, e não embutida na lógica do agente: modelos menores e mais rápidos para tarefas simples e modelos maiores para solicitações que exigem raciocínio mais refinado, selecionados após avaliação em dados de negócio realistas e representativos. Uma camada de roteamento de modelos mantém os agentes desacoplados do ambiente de hospedagem e das APIs específicas de cada provedor; um proxy como o LiteLLM fornece uma interface comum entre provedores, de modo que os modelos possam ser trocados sem reescrever a lógica da aplicação.
Orquestração. Para tarefas diretas, os autores recomendam um único agente de ponta a ponta; para fluxos de trabalho complexos entre domínios, um supervisor que delega a agentes especialistas, cada um com escopo restrito a uma capacidade e um conjunto de ferramentas específicos. Eles alertam contra um agente único que faz tudo: acumular ferramentas, instruções e contexto aumenta a janela de contexto, eleva a latência, pode reduzir a precisão e produz um excesso de ferramentas que pode levar os agentes além de seus limites pretendidos, rumo a ações não intencionais e violações de segurança. Os especialistas devem operar sob autonomia delimitada, executando estritamente dentro das ferramentas concedidas. O post também recomenda desacoplar os especialistas do supervisor por meio de um registro centralizado de agentes que cataloga as ferramentas, habilidades e responsável de cada agente, com invocação por protocolos padronizados como MCP (Model Context Protocol) e A2A (Agent to Agent). Os componentes sugeridos incluem Strands Agents para os especialistas, o harness Amazon Bedrock AgentCore para o orquestrador e o AWS Agent Registry com o Amazon Bedrock AgentCore Gateway para descoberta e roteamento centralizados.
Segurança e Guardrails. Os autores afirmam que a IA agêntica expõe as organizações a riscos que os frameworks de segurança convencionais não foram construídos para enfrentar, de prompt injection e uso indevido de ferramentas a envenenamento de memória e de dados. As recomendações incluem tratar todo conteúdo externo como não confiável, autenticar cada solicitação, venha ela de um usuário, de outro agente ou de um fluxo de trabalho automatizado (por exemplo, por meio do Amazon Bedrock AgentCore Identity), aplicar controle de acesso refinado antes de cada chamada de ferramenta, conceder credenciais temporárias com escopo em vez de segredos persistentes e mascarar dados sensíveis como PHI e PII em solicitações e respostas. Para responsabilização, o post pede uma trilha de auditoria à prova de adulteração das decisões significativas, um portão de aprovação humana para ações de alto impacto e disjuntores para interromper comportamentos anômalos. Os serviços sugeridos incluem Amazon Bedrock Guardrails para entradas de usuários, AgentCore Identity e Policy no Amazon Bedrock AgentCore para autenticação e controle de acesso, e controles de segurança e governança da AWS para defesa em profundidade.
Aplicação. A camada de experiência do usuário final, seja uma interface de chat, uma superfície de API ou um widget embutido, deve permanecer intencionalmente fina: ela apresenta a conversa e repassa as solicitações à camada de orquestração, sem lógica de negócio embutida. Um modelo de decisão pode ficar nessa fronteira como uma verificação rápida e barata que pontua se uma solicitação está no escopo, precisa de um humano ou é urgente, retornando probabilidades em vez de texto livre, de modo que o loop agêntico completo só rode quando agrega valor. O post também aconselha projetar interfaces externas para que outros agentes de IA, e não apenas humanos, possam consumir e interagir com o sistema.
Observabilidade. O monitoramento deve cobrir todas as camadas desde o primeiro dia. Além de logs e métricas, os traces de ponta a ponta dos agentes são críticos para medir se o agente executou sua tarefa corretamente; o post também lista custo e uso de tokens por solicitação, tempo até o primeiro token, se cada chamada é segura e dashboards de latência, taxas de erro e gastos antes de entrar em produção. As ferramentas sugeridas incluem Amazon CloudWatch com OpenTelemetry e Amazon CloudWatch Omni para tracing e métricas.
Operações Agênticas. Esta camada fecha o ciclo com avaliação contínua: pontuar cada sessão de produção quanto a fundamentação, precisão e segurança, com um portão de regressão para capturar quedas de qualidade antes que cheguem aos clientes. Os componentes sugeridos são o Amazon Bedrock AgentCore Evaluations para pontuação e a otimização do Amazon Bedrock AgentCore para ajuste contínuo de desempenho.
Implementação de referência
O framework vem com uma implementação de referência pronta para execução, construída sobre um cenário de suporte ao cliente de varejo que cobre status de pedidos e elegibilidade para reembolso, escolhido por exercitar todas as camadas e ainda assim ser fácil de adaptar. Um agente supervisor recebe uma solicitação de reembolso e delega a um agente de Pedidos e a um agente de Reembolsos. O agente de Pedidos consulta detalhes de entrega e compra no Amazon DynamoDB; o agente de Reembolsos recupera regras de política por faixa de uma base de conhecimento e calcula a elegibilidade usando a data de entrega, a data atual e o nível de fidelidade do cliente. Cada chamada passa pelo AgentCore Gateway, que impõe controle de acesso refinado antes de uma ferramenta ser executada via Policy in AgentCore, e cada chamada é rastreada de ponta a ponta para que um cálculo defeituoso possa ser atribuído a uma camada e a um ponto de decisão específicos. Equipes que constroem um padrão semelhante de supervisor e especialistas podem clonar a implementação e trocar sua própria lógica de domínio camada por camada.
Por que a plugabilidade importa
Os autores argumentam que o valor do design em camadas está na rapidez com que cada camada pode evoluir: contratos estáveis nas fronteiras entre camadas, de verificações de identidade e políticas de acesso a interfaces de telemetria, permitem que a tecnologia subjacente mude sem redesenhar a pilha. O framework demonstra isso por meio de integrações com provedores de terceiros em várias camadas, incluindo provedores de modelos e hospedagem na inferência, capacidades de busca na orquestração, APIs de decisão na camada de aplicação, guardrails na camada de segurança e tracing e monitoramento de agentes na observabilidade, ao lado do acompanhamento de valor de negócio e de custos. Para empresas, diz o post, essa flexibilidade protege investimentos existentes e evita exigir que toda decisão de tecnologia venha do mesmo fornecedor.
O post conclui que um protótipo prova o que um agente consegue fazer, enquanto a arquitetura determina se uma empresa pode depender dele, e recomenda começar pela experiência do Workshop Studio e pelo repositório público de exemplos, com a ressalva de que a implementação não substitui o hardening de segurança, os testes e a revisão necessários para produção.