A AWS publicou, em 1º de outubro de 2026, em seu blog de machine learning, um guia técnico que transforma o Amazon S3 Vectors na camada de memória persistente do NVIDIA NeMo Agent Toolkit (NAT), com a pilha implantada no Amazon Elastic Kubernetes Service (Amazon EKS). A proposta é sair da discussão arquitetural e entrar na implementação: o texto explica como funciona o subsistema de memória do NAT e ensina a construir um provedor de memória customizado apoiado no serviço de vetores da AWS.
O fio condutor do tutorial é um caso de pesquisa de investimentos conduzido por múltiplos agentes.
O que é o NVIDIA nemo agent toolkit
O NAT é descrito como um framework aberto para construir, analisar e otimizar agentes de IA. Ele é agnóstico de framework: funciona com Strands Agents, LangChain, LlamaIndex, CrewAI e implementações próprias.
O material destaca quatro capacidades relevantes para sistemas de agentes em produção. A primeira é a orquestração, que permite definir agentes como fluxos compostos com modelos de linguagem, ferramentas e prompts configuráveis, executados localmente com o comando nat run ou como serviços persistentes via nat serve.
A segunda é a criação de perfis, com acompanhamento de consumo de tokens, latência, throughput e tempos de execução por agente e por ferramenta, o que ajuda a localizar gargalos em fluxos multiagente.
As outras duas capacidades são a avaliação e a otimização. No lado da avaliação, o toolkit traz avaliadores prontos para precisão de respostas, relevância de contexto, fundamentação da resposta e trajetória do agente, além de suporte a avaliadores personalizados.
Na otimização, o foco é o ajuste automatizado de hiperparâmetros como temperature, top_p e max_tokens, buscando maximizar qualidade enquanto se reduz custo e latência.
Como funciona o subsistema de memória
O NAT inclui um módulo dedicado a armazenar e recuperar histórico de conversas, preferências do usuário e conhecimento de longo prazo entre invocações de agentes. Esse módulo é extensível: provedores de memória são criados ao se implementar a interface de plugin do toolkit.
O texto detalha quatro componentes centrais. O MemoryEditor é a interface abstrata que todo backend precisa implementar, com três métodos: add_items(), search() e remove_items().
O MemoryItem é o modelo de dados de um pedaço de memória, com campos para histórico de conversa, tags, metadados, user_id e uma string textual opcional. O MemoryBaseConfig é uma classe base Pydantic que as configurações customizadas estendem, e o NAT descobre provedores pelo campo _type no arquivo YAML.
Já o auto_memory_agent é o tipo de workflow que envolve agentes com captura e recuperação autom áticas de memória, sem exigir que o modelo invoque ferramentas de memória explicitamente.
O NAT traz provedores de memória embutidos: Mem0, MemMachine, Redis e Zep. Segundo a AWS, eles cobrem casos comuns, mas sistemas multiagente de produção que exigem armazenamento vetorial elástico, consistência forte de escrita e escala economicamente viável para bilhões de vetores pedem um provedor customizado apoiado no Amazon S3 Vectors.
Por que o amazon s3 vectors entra como backend
O post lista os requisitos de memória de agentes e como o S3 Vectors responde a cada um. Para recuperação semântica, há busca por similaridade vetorial com métricas de distância configuráveis, como cosseno e euclidiana.
Para consultas com escopo, cada vetor carrega metadados filtráveis dos tipos string, número, booleano e lista. Para coordenação entre múltiplos agentes, o serviço oferece consistência forte de escrita: as memórias ficam visíveis imediatamente após a inserção.
Em escala, o limite informado é de até 2 bilhões de vetores por índice, sem planejamento de capacidade. No custo, paga-se apenas por armazenamento, escritas e consultas, sem computação ociosa.
No controle de acesso, políticas do AWS Identity and Access Management (IAM) podem ser aplicadas por bucket e por índice, com índices por inquilino para isolamento rígido.
O que muda na prática
O tutorial vai além da teoria e mostra como implantar o conjunto no Amazon EKS, o que dá controle operacional completo sobre a infraestrutura. Entre os pré-requisitos listados estão uma conta da AWS com permissões para criar recursos do Amazon S3 Vectors e clusters do Amazon EKS, além de um cluster EKS já existente.
O caso de uso que amarra o percurso é o de pesquisa de investimentos com múltiplos agentes, cenário em que histórico, preferências e conhecimento acumulado precisam sobreviver a cada nova chamada de agente.
O material se apresenta como continuação de um post anterior sobre memória persistente para sistemas multiagente, que discutia por que a engenharia de memória é tratada como disciplina fundamental nesse tipo de arquitetura. A novidade agora é o caminho concreto de implementação dentro de um framework aberto da NVIDIA, combinado com armazenamento vetorial gerenciado da AWS.
Fontes e links
- AWS
- Building persistent memory for multi-agent AI systems with Amazon S3 Vectors
- Documentação do Amazon S3 Vectors
- Documentação do NVIDIA NeMo Agent Toolkit
