AWS propõe arquitetura de sete camadas para agentes: do protótipo à produção

O protótipo de um agente quase sempre parece convincente. Ele responde a perguntas, chama ferramentas e fica ótimo na demonstração. Depois chegam o tráfego real, a fatura de tokens e a revisão do time de segurança, e o projeto trava. Segundo a AWS, a culpa raramente é do modelo. A culpa é da infraestrutura ao redor, que cada equipe escreve do zero e, em geral, depois do lançamento, não antes.

No blog AWS Machine Learning foi publicada uma análise do Pluggable Agentic AI Framework. Trata-se de uma arquitetura de referência de sete camadas para aplicações multiagente. Cada camada tem sua própria área de responsabilidade e um contrato estável com as vizinhas. Os serviços concretos no diagrama são apenas um exemplo de implementação, e não uma escolha obrigatória.

Sete camadas sem mágica

A primeira camada é a de dados e conhecimento. Ela recebe a consulta e devolve o contexto relevante para o agente. No exemplo, são usados Bedrock Knowledge Base, OpenSearch Serverless, S3 Vectors e DynamoDB.

A segunda camada é a de modelos e inferência. A escolha do modelo deve ficar na configuração, e não no código do agente. Tarefas simples vão para um modelo pequeno e rápido; raciocínios complexos, para um modelo grande. Entre os agentes e os provedores fica um proxy como o LiteLLM, com interface única. É possível trocar de modelo após uma nova avaliação sem mexer na lógica da aplicação.

A terceira camada é a de orquestração. Para uma tarefa simples, um único agente basta. Para cenários complexos que cruzam domínios, são necessários um supervisor e especialistas focados, cada um com seu próprio conjunto de ferramentas. Um agente universal único, com o tempo, acumula instruções e ferramentas, o contexto incha, a latência aumenta e a precisão cai. Os especialistas são registrados em um registro único, e o supervisor os encontra e os chama por meio dos protocolos padrão MCP e A2A. O registro, com a descrição das ferramentas, das habilidades e do responsável por cada agente, é necessário também para governança e para não escrever a mesma coisa duas vezes.

A quarta camada é a de segurança e limitadores. Todo conteúdo externo é considerado não confiável. Cada requisição é autenticada, seja de um usuário, de outro agente ou de um processo automático. As permissões para cada chamada de ferramenta são verificadas antes da execução, e, em vez de segredos permanentes, o agente recebe credenciais temporárias e restritas. Dados pessoais e médicos são mascarados em requisições e respostas. As decisões-chave são registradas em um log de auditoria, ações arriscadas passam por confirmação humana, e disjuntores de emergência interrompem comportamentos anômalos.

A quinta camada é a de aplicação. Recomenda-se mantê-la enxuta: chat, API ou widget apenas repassam a requisição ao orquestrador, e só. Lógica de negócio não tem lugar aqui. Na borda, é possível colocar um modelo classificador barato e rápido. Em uma única chamada, ele avalia se a requisição se enquadra no tema, se é necessário um humano e qual a urgência. O modelo devolve probabilidades, e não texto, e um código comum, com base em limiares, decide se o ciclo agêntico completo deve ser iniciado.

A sexta camada é a de observabilidade. Traces de ponta a ponta, custo e tokens por requisição, tempo até o primeiro token e dashboards de latência e erros são necessários antes do lançamento, e não depois do primeiro incidente. A sétima camada é a de operações: avaliação contínua de cada sessão de produção quanto a fundamentação, precisão e segurança. Além disso, um gate de regressão que impede que chegue aos clientes uma versão com qualidade degradada.

Como isso fica na prática

A implementação de referência é um atendimento ao cliente no varejo: status do pedido e possibilidade de devolução. O supervisor recebe um pedido de devolução e o repassa a dois especialistas. O agente de pedidos busca no DynamoDB os dados de entrega e de compra. O agente de devoluções obtém da base de conhecimento as regras por nível de fidelidade e calcula a elegibilidade com base na data de entrega, na data atual e no nível do cliente. Cada chamada passa pelo AgentCore Gateway, que verifica as permissões. Cada chamada é rastreada e, se o cálculo estiver errado, o trace mostra em qual camada e em qual decisão ocorreu o erro.

O que tirar disso

A ideia central: primeiro a arquitetura, depois as tecnologias. Se os limites das camadas são definidos por contratos, trocar o modelo, os guardrails ou o sistema de monitoramento não se transforma em reescrever a pilha. Para as empresas, é também a possibilidade de manter as ferramentas que já funcionam e adicionar o novo gradualmente.

Também convém enxergar as limitações. O artigo foi escrito por um fornecedor e é orientado à pilha da AWS: AgentCore, Bedrock, CloudWatch. A substituibilidade dos componentes é declarada, mas será preciso verificá-la por conta própria na sua infraestrutura. Os próprios autores ressalvam que o exemplo não substitui hardening de segurança, testes e revisão.

A conclusão prática é simples. Mesmo que você não use a AWS, a lista de sete camadas funciona como um checklist de planejamento. Você tem um registro de agentes? As permissões são verificadas antes da chamada da ferramenta ou depois? Você consegue provar que o agente funciona tão bem quanto no dia do lançamento? Se a resposta for «não» a ao menos uma dessas perguntas, você descobriu onde seu projeto corre o risco de ficar preso entre o protótipo e a produção.