Blog

O problema que todo vendedor conhece

De acordo com dados citados pela própria AWS, representantes de vendas dedicam apenas 40% do seu tempo efetivamente vendendo. O restante do dia é consumido por tarefas necessárias, mas de menor valor: atualizar o sistema de Gestão de Relacionamento com o Cliente (CRM), pesquisar prospects, redigir e-mails e alternar constantemente entre ferramentas. O resultado é previsível — o dia passa e pouco foi feito para fechar negócios ou gerar valor para os clientes.

É nesse contexto que a AWS posiciona o Amazon Quick: um assistente de IA para o ambiente de trabalho que transforma perguntas em respostas, respostas em ações e ações em resultados concretos. O Quick funciona no navegador, no aplicativo de desktop e diretamente dentro do Microsoft 365, Outlook e outras ferramentas do dia a dia.

Empresas como 3M, AWS Global Sales e Amazon já utilizam o Quick para ampliar o potencial de suas equipes comerciais. É possível ver na prática como a AWS Global Sales transforma a entrega de insights, como as equipes de vendas da AWS se mantêm atualizadas sobre novos lançamentos e acompanhar a jornada da Amazon ao implantar o Quick Suite para milhares de usuários.

Cobrindo todo o ciclo de vendas

A proposta do Amazon Quick é cobrir o ciclo de vendas de ponta a ponta — desde a identificação dos prospects de maior prioridade até a manutenção do CRM atualizado à medida que a conta amadurece — tudo isso preservando o recurso mais escasso do vendedor: o tempo.

Pontuação de leads e priorização de prospects

Imagine uma lista de 200 leads no CRM. Alguns preencheram um formulário há seis meses. Outros baixaram um whitepaper na semana passada. Alguns responderam a e-mails frios. Quais merecem atenção hoje? Esse é um desafio recorrente: a maioria das equipes de vendas não tem visibilidade clara sobre quais leads estão realmente prontos para comprar.

O Amazon Quick endereça esse problema conectando-se ao CRM, e-mail, análise web e sistemas de suporte para analisar sinais de engajamento e classificar leads dinamicamente por intenção de compra. Com agentes de chat personalizados que buscam contexto em documentos internos, detalhes de oportunidades e histórico de contas, o Quick ajuda o vendedor a focar nos prospects com maior probabilidade de conversão.

Para começar, é necessário integrar o Quick ao CRM existente. A documentação oficial oferece instruções detalhadas para Salesforce, HubSpot, ServiceNow e outros sistemas. A partir daí, é possível criar um painel usando o Amazon Quick Sight — o serviço de inteligência de negócios dentro do Amazon Quick para construir visualizações interativas a partir das fontes de dados conectadas — e usar o chat para solicitar ao Quick uma lista das negociações mais urgentes.

Um prompt em linguagem natural como “classifique meu pipeline” é suficiente para que o Quick agregue dados de todos os sistemas conectados e produza uma visão priorizada. Negociações com progressão travada, acompanhamentos em atraso ou pressão competitiva aparecem no topo da lista.

Detecção de riscos e próximos passos

Para cada negociação, o Quick identifica sinais de risco específicos — como threads de e-mail paradas, acompanhamentos perdidos e menções a concorrentes — e recomenda ações concretas. O vendedor pode acionar um fluxo de acompanhamento diretamente da conversa, sem precisar trocar de contexto.

Abordagem personalizada e engajamento por e-mail

Depois de identificar o prospect de maior prioridade, chega a hora de entrar em contato. Tradicionalmente, criar uma mensagem suficientemente personalizada exigia pesquisa manual no CRM, em documentos internos e em sinais externos — site da empresa, comunicados recentes, perfil do prospect no LinkedIn. A alternativa era enviar um e-mail genérico, quase sempre ignorado.

O Amazon Quick elimina esse dilema. Ele ajuda a criar mensagens altamente direcionadas que referenciam contexto específico — notícias recentes da empresa, pontos de dor identificados em interações anteriores e casos de uso relevantes — sem horas de pesquisa manual.

Para isso, é possível criar uma skill no Amazon Quick: um fluxo de trabalho automatizado e reutilizável que executa uma série de etapas. No caso de outreach, a instrução seria algo como “pesquise o prospect buscando dados de múltiplas fontes (CRM, threads de e-mail, conversas no Slack, briefings de conta e pesquisa web) e gere uma mensagem de abordagem personalizada”. Essa skill pode ser reutilizada em todas as contas.

Essa etapa requer a integração do Outlook com o Amazon Quick. Após revisar o e-mail e fazer ajustes, é possível enviá-lo diretamente pelo Quick. Com as extensões para Microsoft 365, o vendedor também pode trabalhar dentro do próprio Outlook ou Teams — o Quick aparece como um painel lateral no cliente de e-mail, permitindo gerar abordagens personalizadas, buscar contexto de conta e refinar mensagens sem trocar de aba.

Monitoramento de atividades: clareza desde o início do dia

O Feed de Atividades do Quick exibe as mudanças ocorridas durante a noite no Slack, e-mail e CRM, priorizadas por relevância para as negociações ativas do vendedor. Isso substitui a triagem manual matinal em múltiplas ferramentas por uma visão consolidada em um único lugar.

Inteligência de conta: prepare-se para fechar com confiança

Quando um cliente concorda em se reunir para discutir uma solução proposta, começa a fase de preparação. Tradicionalmente, isso significa horas alternando entre o Salesforce para histórico de negociações, o ServiceNow para tickets de suporte, o cliente de e-mail para conversas anteriores e um buscador para contexto do setor.

Com o Amazon Quick, o vendedor pode solicitar a criação de um documento de preparação de reunião de uma página com snapshot da conta, bios dos participantes, perguntas e riscos. Para isso, basta conectar o Quick Chat a um Quick Space — um repositório centralizado de conhecimento onde documentos, fontes de dados e arquivos ficam organizados para que o Quick os referencie ao responder perguntas ou concluir tarefas.

Para preparações de Revisão Trimestral de Negócios (QBR — Quarterly Business Review), o Quick vai além: ele pode criar e montar uma apresentação completa a partir de arquivos de negociação, incidentes de suporte e threads de e-mail. O vendedor revisa o esboço proposto, seleciona um tema e aprova a construção. O deck resultante inclui snapshot da conta, linha do tempo de incidentes, status da negociação e plano de remediação — tudo construído a partir de dados atuais, sem montagem manual. Minutos de preparação em vez de horas.

Pontuação de transcrições de chamadas

Após uma reunião, o vendedor pode inserir a transcrição da chamada no Quick para pontuação automatizada com base em sua metodologia de vendas — como MEDDPICC, BANT ou um framework personalizado. O Quick identifica o que foi abordado, quais lacunas permanecem e fornece uma avaliação estruturada da saúde da negociação com base na conversa.

Automação de CRM e registro de atividades

Cada interação costuma exigir de 15 a 20 minutos de atualizações no CRM — uma tarefa difícil de priorizar enquanto outras interações com clientes demandam atenção. Com o tempo, o contexto se perde e os detalhes escapam.

Após a análise da chamada, o Quick envia atualizações estruturadas para o Salesforce, incluindo probabilidade de fechamento, próximos passos, sinalizações de risco e um resumo da conversa. Isso mantém o sistema de registro preciso sem exigir entrada manual de dados.

Criação de aplicações personalizadas a partir de linguagem natural

O Quick permite que vendedores e equipes de operações de vendas construam aplicações interativas a partir de um prompt em linguagem natural — o sistema lê automaticamente os schemas de dados conectados e cria uma aplicação funcional sem necessidade de escrever código. A aplicação resultante é ao vivo, compartilhável e iterável: é possível adicionar funcionalidades, alterar layouts ou conectar novas fontes de dados com prompts de acompanhamento.

Grafo de Conhecimento: mapeie relacionamentos em toda a sua carteira

O Grafo de Conhecimento mapeia relacionamentos entre pessoas, contas, negociações e interações que o Quick aprendeu a partir das ferramentas conectadas. Os vendedores podem consultar o histórico de relacionamentos, identificar caminhos para apresentações aquecidas e entender estruturas de conta sem pesquisa manual.

Resumo das capacidades

O Amazon Quick cobre um fluxo de trabalho de vendas completo — da revisão matinal do pipeline à abordagem personalizada, preparação de reuniões, pontuação de chamadas, atualizações de CRM, criação de aplicações e mapeamento de relacionamentos. Cada capacidade se conecta à seguinte, criando um fluxo contínuo que mantém o vendedor em movimento em vez de alternando entre ferramentas.

• Pontuação de pipeline: classifica negociações usando sinais ao vivo do CRM.
• Detecção de riscos: identifica negociações travadas e ameaças competitivas.
• Abordagem personalizada: gera e-mails contextualizados a partir do histórico da negociação.
• Skills personalizadas: codifica e compartilha fluxos de trabalho reutilizáveis.
• Feed de Atividades: monitora mudanças noturnas em todos os sistemas.
• Preparação de reuniões e decks de QBR: constrói apresentações a partir de dados ao vivo.
• Pontuação de chamadas: avalia transcrições com base na metodologia de vendas.
• Atualizações de CRM: envia atualizações estruturadas para o Salesforce.
• Aplicações personalizadas: cria ferramentas interativas a partir de prompts.
• Grafo de Conhecimento: mapeia inteligência de relacionamentos.

Por onde começar

A recomendação da AWS é começar com um único fluxo de trabalho — pontuação de leads, preparação de reuniões ou automação de CRM — e experimentar a diferença na prática. Para saber mais, é possível acessar a página do Amazon Quick para Vendas ou assistir ao demo de vendas e ao walkthrough completo disponibilizados pela AWS.

Fonte

Transform your sales organization with Amazon Quick: your new agentic AI teammate (https://aws.amazon.com/blogs/machine-learning/transform-your-sales-organization-with-amazon-quick-your-new-agentic-ai-teammate/)

O que mudou no HyperPod com Slurm

A AWS anunciou uma atualização relevante para quem trabalha com treinamento distribuído de modelos de IA: o Amazon SageMaker HyperPod agora suporta configuração de topologia de rede no nível de partição em clusters orquestrados pelo Slurm. Na prática, isso significa que um único cluster pode operar com topologias diferentes em partições distintas, cada uma otimizada para o tipo de instância que ela utiliza.

Topologia block e tree: cada partição com a sua

Antes dessa atualização, a configuração de topologia era aplicada de forma mais uniforme ao cluster. Agora, o HyperPod determina automaticamente qual topologia aplicar a cada partição com base nos tipos de instância que compõem seus grupos de computação:

• Partições com instâncias do tipo Amazon EC2 UltraServer — como ml.p6e-gb200.36xlarge — utilizam topologia block.
• Partições com instâncias de interconexão hierárquica — como ml.p5.48xlarge, ml.p5e.48xlarge e ml.p5en.48xlarge — utilizam topologia tree.
• Partições com tipos de instância que não fornecem informações de topologia de rede permanecem totalmente agendáveis, sem restrições adicionais.

Por que isso importa para o treinamento distribuído

A escolha da topologia certa para cada tipo de instância tem impacto direto na eficiência da comunicação entre GPUs. Com o alinhamento correto entre o posicionamento dos jobs e as características de interconexão de cada instância, a AWS aponta ganhos em três frentes:

• Comunicação GPU a GPU mais rápida.
• Operações coletivas NCCL (Biblioteca de Comunicações Coletivas NVIDIA) mais eficientes.
• Maior throughput (vazão) geral no treinamento.

Manutenção automática da topologia

Um ponto importante dessa atualização é que o HyperPod mantém a configuração de topologia de forma automática ao longo do ciclo de vida do cluster. Isso inclui eventos de escalonamento para cima, escalonamento para baixo e substituição de nós — em todos esses casos, a topologia de cada partição é atualizada para refletir o estado atual do cluster, sem necessidade de intervenção manual.

Como começar a usar

Para aproveitar o recurso, basta criar ou atualizar um cluster SageMaker HyperPod com Slurm rodando a versão 25.11 ou superior, utilizando os tipos de instância GPU suportados. O agendamento com consciência de topologia (topology-aware scheduling) é habilitado por padrão e não exige nenhuma configuração adicional.

O recurso está disponível em todas as regiões AWS onde o Amazon SageMaker HyperPod é suportado. Para se aprofundar, a documentação oficial cobre os detalhes de implementação: Usando agendamento com consciência de topologia no Amazon SageMaker HyperPod.

Fonte

Amazon SageMaker HyperPod now supports partition-level topology for Slurm orchestrated clusters (https://aws.amazon.com/about-aws/whats-new/2026/07/hyperpod-partition-topology-slurm/)

A xAI entra no Amazon Bedrock com o Grok 4.3

A AWS anunciou que o Grok 4.3, modelo de Inteligência Artificial (IA) da xAI, está disponível de forma geral no Amazon Bedrock. Com essa chegada, a xAI passa a integrar o catálogo de provedores de modelos da plataforma, ao lado de outras empresas como Anthropic, Meta e Mistral.

O Grok 4.3 foi desenvolvido com foco em cargas de trabalho empresariais que exigem precisão. Segundo a xAI, o modelo foi projetado para trabalhos corporativos onde a acurácia é essencial. Nos próprios benchmarks da empresa no momento do lançamento, o Grok 4.3 ficou em primeiro lugar no benchmark Artificial Analysis Omniscience, com a menor taxa de alucinação entre os modelos de fronteira avaliados. Também liderou o benchmark Artificial Analysis Tau2 Telecom para chamadas de ferramentas em cenários de suporte ao cliente, além dos benchmarks Vals AI Case Law e Corporate Finance para compreensão de documentos.

A xAI posiciona o modelo na fronteira de Pareto entre inteligência e custo, descrevendo uma relação de 2 a 10 vezes mais inteligência por dólar em comparação com outros modelos de fronteira.

O que torna o Grok 4.3 adequado para cargas agênticas

O modelo aceita entrada de texto e imagens, retorna texto e possui uma janela de contexto de 1 milhão de tokens — espaço suficiente para documentos longos e sessões de múltiplos turnos. Ele também suporta chamadas de ferramentas e seguimento de instruções de forma robusta, o que o torna prático para agentes que dependem de chamadas de função para executar ações.

Um diferencial importante é o esforço de raciocínio configurável. A cada requisição, é possível definir o nível de esforço entre quatro opções: none, low, medium e high. Isso permite usar um único modelo para toda a gama de tarefas: chamadas de classificação rodam com esforço none para manter a latência baixa, enquanto análises de contratos ou tarefas jurídicas rodam com esforço high quando a profundidade importa mais do que o tempo de resposta.

Esses atributos se alinham bem com casos de uso como revisão de contratos, análise de acordos de crédito e respostas a perguntas sobre documentos financeiros — cenários em que o modelo precisa raciocinar sobre entradas longas e acionar sistemas de registro externos.

Como o Grok 4.3 é acessado no Amazon Bedrock

O Grok 4.3 roda no Mantle, o mecanismo de inferência de próxima geração do Amazon Bedrock. O acesso ao modelo difere dos modelos que usam a API padrão do Amazon Bedrock Runtime: o Mantle utiliza APIs compatíveis com o padrão OpenAI. É possível invocar o Grok 4.3 com o SDK da OpenAI ou via requisições HTTPS diretas à Chat Completions API ou à Responses API.

A URL do endpoint Mantle segue um padrão específico por região:

Por exemplo, na região us-west-2, a URL base é https://bedrock-mantle.us-west-2.api.aws/openai/v1. Vale observar que a rota da Responses API no endpoint Mantle (/openai/v1/) difere ligeiramente do endpoint Runtime (/v1/responses).

Ao configurar o SDK com o Grok 4.3, é importante saber que os valores padrão divergem da especificação OpenAI padrão em três pontos: temperature padrão é 0.7 (em vez de 1), top_p padrão é 0.95 (em vez de 1) e max_completion_tokens padrão é 131072. Se a aplicação precisar de comportamento diferente, esses valores devem ser definidos explicitamente.

Autenticação e primeira requisição

Há duas formas de autenticar contra o endpoint Mantle. Para produção, a AWS recomenda tokens de curto prazo gerados a partir das credenciais do IAM (Gerenciamento de Identidade e Acesso), pois eles expiram automaticamente e mantêm o acesso vinculado à identidade do IAM. Para exploração inicial, é possível usar uma chave de API de longo prazo do Amazon Bedrock — mas a recomendação é restringir esse tipo de chave a esse propósito, sem incorporá-la em aplicações de produção.

O exemplo abaixo mostra como autenticar com uma chave de API de longo prazo. É possível gerar essa chave pelo console do Amazon Bedrock e, em seguida, instalar o SDK da OpenAI:

pip install openai

Com o cliente apontado para o endpoint Mantle regional e autenticado com a chave de API, o ID do modelo é xai.grok-4.3:

from openai import OpenAI

client = OpenAI(
    api_key="<your Amazon Bedrock API key>",
    base_url="https://bedrock-mantle.us-west-2.api.aws/openai/v1",
)

response = client.chat.completions.create(
    model="xai.grok-4.3",
    messages=[
        {"role": "user", "content": "In one sentence, what is Amazon Bedrock?"}
    ],
)

print(response.choices[0].message.content)

Para aplicações com requisitos de segurança mais elevados, a AWS recomenda credenciais de curto prazo. É possível gerar um token bearer de curto prazo a partir das credenciais AWS existentes usando o gerador de tokens do Amazon Bedrock. Para isso, instale o pacote:

pip install aws-bedrock-token-generator

E use a função provide_token da biblioteca aws_bedrock_token_generator:

from aws_bedrock_token_generator import provide_token
from openai import OpenAI

client = OpenAI(
    api_key=provide_token(region="us-west-2"),
    base_url="https://bedrock-mantle.us-west-2.api.aws/openai/v1",
)

Raciocínio configurável na prática

O controle do esforço de raciocínio é feito pelo parâmetro reasoning na Responses API. Níveis mais altos tendem a ajudar em problemas de múltiplos passos onde uma resposta rápida estaria errada, ao custo de mais tokens de saída. A Chat Completions API não retorna o rastreamento de raciocínio — para isso, é necessário usar a Responses API.

No padrão stateful (com estado), onde store=True e as chamadas são encadeadas com previous_response_id, o serviço retém o raciocínio de cada turno e o alimenta de volta automaticamente. No padrão stateless (sem estado), com store=False, é possível solicitar o raciocínio com include=["reasoning.encrypted_content"] e passá-lo de volta na próxima requisição.

O exemplo abaixo roda um problema clássico com esforço high:

response = client.responses.create(
    model="xai.grok-4.3",
    reasoning={"effort": "high"},  # none, low, medium, or high
    include=["reasoning.encrypted_content"],
    max_output_tokens=4096,
    input=(
        "A bat and ball cost $1.10. The bat costs $1 more than the ball. "
        "How much is the ball? Answer with just the number."
    ),
)

print(response.output_text)
print(response.usage.output_tokens_details.reasoning_tokens)

O modelo trabalha a álgebra em vez de chegar à resposta intuitiva errada de $0,10. Com esforço none, o mesmo campo de tokens de raciocínio reporta 0 — a configuração ideal para chamadas simples e sensíveis a latência.

Um padrão prático: classificação, extração e consultas factuais curtas rodam com none ou low, enquanto etapas de planejamento, matemática e cadeias onde um erro inicial compromete toda a tarefa se beneficiam do esforço high.

Chamadas de ferramentas e saída estruturada

O Grok 4.3 suporta chamadas de ferramentas pela mesma interface compatível com OpenAI. Você descreve as ferramentas disponíveis, o modelo decide quando chamar uma e retorna uma requisição estruturada que o seu código executa e alimenta de volta. O exemplo abaixo oferece uma ferramenta get_weather e faz uma pergunta que deve acioná-la:

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "Get the current weather for a city",
            "parameters": {
                "type": "object",
                "properties": {"city": {"type": "string"}},
                "required": ["city"],
            },
        },
    }
]

response = client.chat.completions.create(
    model="xai.grok-4.3",
    messages=[{"role": "user", "content": "What's the weather in Sydney? Use the tool."}],
    tools=tools,
    tool_choice="auto",  # let the model decide whether to call a tool
)

tool_call = response.choices[0].message.tool_calls[0]
print(tool_call.function.name, tool_call.function.arguments)
# get_weather {"city":"Sydney"}

A partir daqui, você executa a função no seu próprio código, acrescenta uma mensagem com o resultado e chama o modelo novamente para que ele incorpore os dados em uma resposta em linguagem natural. Esse é o bloco de construção para agentes de múltiplos passos com o Grok 4.3.

Para saída estruturada, o Grok 4.3 suporta o formato json_schema com modo estrito, garantindo que a resposta esteja em conformidade com o esquema fornecido:

import json

schema = {
    "type": "object",
    "properties": {
        "name": {"type": "string"},
        "capital": {"type": "string"},
        "population_millions": {"type": "number"},
    },
    "required": ["name", "capital", "population_millions"],
    "additionalProperties": False,
}

response = client.chat.completions.create(
    model="xai.grok-4.3",
    messages=[{"role": "user", "content": "Return facts about the country Australia."}],
    response_format={
        "type": "json_schema",
        "json_schema": {"name": "country_facts", "strict": True, "schema": schema},
    },
    max_completion_tokens=4096,
)

data = json.loads(response.choices[0].message.content)
print(data)
# {'name': 'Australia', 'capital': 'Canberra', 'population_millions': 26.6}

Uma observação operacional relevante: em testes, requisições ocasionalmente retornam erro 400 de uma verificação automatizada de segurança de conteúdo, mesmo em entradas inofensivas. Por isso, vale implementar uma lógica de retry curta em chamadas de produção.

Entrada de imagens e conversas com estado

O Grok 4.3 aceita imagens como entrada e retorna texto, cobrindo casos como compreensão de documentos, leitura de gráficos e resposta a perguntas visuais. A imagem é passada como uma parte de conteúdo com uma URL data: contendo bytes codificados em base64, ou uma URL de imagem pública:

import base64

with open("chart.png", "rb") as f:
    b64 = base64.b64encode(f.read()).decode()

response = client.chat.completions.create(
    model="xai.grok-4.3",
    messages=[
        {
            "role": "user",
            "content": [
                {"type": "text", "text": "Describe this image in one short sentence."},
                {
                    "type": "image_url",
                    "image_url": {"url": f"data:image/png;base64,{b64}"},
                },
            ],
        }
    ],
    max_completion_tokens=4096,
)

print(response.choices[0].message.content)

Para conversas com estado, a Responses API pode manter o histórico de conversa no lado do serviço, eliminando a necessidade de reenviar todo o histórico de mensagens a cada turno. Basta passar store=True, capturar o ID de resposta retornado e referenciá-lo na próxima chamada com previous_response_id:

first = client.responses.create(
    model="xai.grok-4.3",
    input="Remember the number 42. Just acknowledge.",
    store=True,
    max_output_tokens=2048,
)

second = client.responses.create(
    model="xai.grok-4.3",
    previous_response_id=first.id,
    input="What number did I ask you to remember?",
    max_output_tokens=2048,
)

print(second.output_text)
# 42

Um ponto importante antes de ativar esse recurso: armazenar o estado da conversa significa que o serviço retém esses turnos. Vale revisar a documentação de proteção de dados do Amazon Bedrock para entender os detalhes de segurança e privacidade dos dados armazenados, e como desativar a retenção se necessário.

Camadas de serviço e disponibilidade por região

O Amazon Bedrock oferece múltiplas camadas de serviço para adequar custo e throughput a cada carga de trabalho. A camada Standard oferece acesso pay-per-token sem compromisso; a camada Priority oferece tratamento preferencial na fila de processamento por um preço por token mais alto; e a camada Flex oferece acesso de menor custo para cargas de trabalho sem sensibilidade a tempo. O Grok 4.3 pode ser usado com as três camadas. Para detalhes, consulte as camadas de serviço para inferência.

O Grok 4.3 usa inferência dentro da região, então o cliente deve ser fixado a uma região onde o modelo esteja disponível, com a URL base do Mantle correspondente. Inferência geográfica e cross-region global não estão disponíveis para esse modelo no lançamento. Os exemplos utilizam us-west-2. Para a lista atual de regiões suportadas, consulte a documentação de disponibilidade regional, e para preços entre as camadas, veja a página de preços do Amazon Bedrock.

Por onde começar

Para iniciar, vale revisar o model card do Grok 4.3 para a lista atual de regiões e detalhes de parâmetros, e consultar a página de preços do Amazon Bedrock para as taxas por token. A partir daí, algumas direções valem a exploração: montar o loop completo de chamada de ferramentas executando a função retornada e alimentando o resultado de volta; encadear conteúdo de raciocínio criptografado entre turnos da Responses API para dar continuidade ao pensamento de agentes de longa duração; e comparar os níveis de esforço contra suas próprias cargas de trabalho para identificar onde o raciocínio mais alto deixa de compensar o custo em tokens.

Se uma chave de API de longo prazo foi gerada para exploração, o recomendado é excluí-la pelo console do Amazon Bedrock quando não for mais necessária. Uma chave de longo prazo é uma credencial permanente — remover as que não são mais usadas mantém a superfície de ataque da conta reduzida.

Para participar da discussão com a comunidade, acesse o Amazon Bedrock community no AWS re:Post.

Fonte

Introducing Grok on Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/introducing-grok-on-amazon-bedrock/)

O problema: ligações perdidas custam caro para restaurantes

Restaurantes perdem em média 150 ligações por mês em cada unidade. Cerca de 60% dessas chamadas são de clientes tentando fazer um pedido ou reservar uma mesa — e a maioria chega exatamente no horário do jantar, quando a equipe está com as mãos cheias. Tirar alguém do salão para atender o telefone não resolve: piora dois atendimentos ao mesmo tempo.

Aplicativos e sites ajudam quem prefere pedir online, mas não fazem nada pelo cliente que só quer ligar. A AWS publicou um guia técnico detalhado mostrando como resolver esse problema com um sistema de atendimento telefônico com IA — do cumprimento à confirmação do pedido, tudo por voz.

Visão geral da solução

A arquitetura proposta é dividida em três camadas independentes:

• Camada de telefonia: recebe a chamada, identifica o cliente pelo número de telefone e converte o áudio para um formato que o agente consegue processar.
• Camada do agente: executa a conversa usando o Amazon Bedrock AgentCore com o Amazon Nova 2 Sonic para processamento de voz em tempo real.
• Camada de backend: armazena cardápio, carrinhos, pedidos e localizações, acessada pelo agente via Protocolo de Contexto de Modelo (MCP).

Essa separação em camadas é o que torna o sistema prático de operar. Um novo canal — como um aplicativo mobile ou um quiosque — pode se conectar ao mesmo agente sem reescrever o backend. E como o MCP é um padrão aberto, o backend pode evoluir sem tocar no agente.

Componentes principais da arquitetura

A solução utiliza os seguintes serviços da AWS:

• Amazon Chime SDK Voice Connector: fornece o tronco SIP (Protocolo de Iniciação de Sessão) e o número gratuito que recebe as chamadas.
• Amazon Elastic Container Service (Amazon ECS) com AWS Fargate: executa o gateway SIP atrás de um Balanceador de Carga de Rede (Network Load Balancer).
• AgentCore Runtime: hospeda a lógica de conversação, com cada chamada rodando em sua própria microVM isolada.
• AgentCore Gateway: expõe as APIs do backend como ferramentas MCP que o agente pode descobrir e chamar pelo nome.
• Amazon API Gateway: frente REST dos endpoints protegidos por Gerenciamento de Identidade e Acesso da AWS (IAM).
• AWS Lambda: executa a lógica de negócio para cardápio, carrinhos, pedidos e consultas de localização.
• Amazon DynamoDB: armazena os dados, com capacidade sob demanda que escala automaticamente.
• Amazon Location Service: faz geocodificação e cálculo de rotas.
• Amazon Elastic Container Registry (Amazon ECR), AWS CodeBuild e Amazon Simple Storage Service (Amazon S3): constroem e armazenam a imagem de container do agente.
• Amazon CloudWatch: monitoramento centralizado, logs e alertas. Todos os dados em repouso são criptografados com o Serviço de Gerenciamento de Chaves da AWS (AWS KMS).

Fluxo de uma chamada do início ao fim

O fluxo completo de uma chamada segue estas etapas:

1. O cliente disca para o número gratuito e o Amazon Chime SDK Voice Connector atende.
2. O Voice Connector aciona uma função Lambda (Aplicação de Mídia SIP), que calcula um identificador de sessão para a chamada.
3. A Lambda envia uma requisição de aquecimento ao AgentCore Runtime, para que o agente prepare a sessão enquanto o telefone ainda está chamando.
4. A Lambda instrui o Voice Connector a direcionar a chamada ao gateway SIP no AWS Fargate, passando o identificador de sessão.
5. O gateway SIP abre uma conexão WebSocket assinada com SigV4 ao AgentCore Runtime, usando esse mesmo identificador.
6. A chamada se conecta à sessão já aquecida: o áudio do cliente flui para o agente, e o áudio do agente volta para o cliente.
7. O agente conduz a conversa com o Amazon Nova 2 Sonic e chama as ferramentas do backend via AgentCore Gateway quando precisa de dados de cardápio, carrinho, pedido ou localização.

O truque do aquecimento durante o toque

Uma chamada de voz não perdoa silêncio. Se o cliente conecta e não ouve nada por alguns segundos, a chamada parece quebrada — mesmo que o sistema esteja funcionando normalmente. A parte lenta de iniciar uma chamada é a configuração única: resolver o prompt de sistema para aquele cliente, abrir o stream do Amazon Nova 2 Sonic e descobrir as ferramentas MCP disponíveis.

Em vez de fazer o cliente esperar por tudo isso, a Lambda de Aplicação de Mídia SIP dispara esse processo enquanto o telefone ainda está tocando. Quando o gateway SIP abre a conexão WebSocket com o mesmo identificador de sessão, o AgentCore Runtime já roteou para a microVM aquecida — e o agente está pronto para falar imediatamente.

Como o gateway SIP funciona

A camada de telefonia tem uma única responsabilidade: transformar uma chamada telefônica em um stream de mídia que o agente consiga ler e escrever. A rede telefônica entrega áudio como pacotes RTP (Protocolo de Transporte em Tempo Real) via UDP. O agente espera um WebSocket com frames no formato que o Amazon Nova 2 Sonic entende. Sem uma camada de tradução no meio, o agente precisaria conhecer SIP, negociação de codec e roteamento de mídia em nível de rede.

O gateway SIP roda no AWS Fargate e usa o drachtio-server para sinalização SIP, com uma bridge Node.js para o áudio. Para alta disponibilidade, ele executa duas tarefas em duas Zonas de Disponibilidade (AZs), o que garante redundância e um ponto para publicar métricas de contagem de chamadas no Amazon CloudWatch para escalonamento. A sinalização passa pelo Network Load Balancer, mas o áudio flui diretamente entre o Voice Connector e a tarefa Fargate — mantendo o balanceador de carga fora do caminho de mídia.

Armazenamento de dados: cardápio, carrinhos e pedidos

Cinco tabelas do Amazon DynamoDB cobrem o fluxo de pedidos:

• Customers (Clientes): perfis com nome, telefone e informações de fidelidade, usados para reconhecer um cliente recorrente.
• Orders (Pedidos): histórico de pedidos com o local de retirada.
• Menu (Cardápio): itens, preços e disponibilidade, que podem variar por unidade.
• Carts (Carrinhos): carrinhos em andamento com valor de tempo de vida (TTL), para que carrinhos abandonados se limpem automaticamente.
• Locations (Localizações): detalhes das unidades como coordenadas, horários e taxas.

Encontrando o local de retirada por voz

Um cliente que liga não tem navegador para compartilhar localização. O agente pede um CEP ou uma referência de rua e usa o Amazon Location Service para converter isso em coordenadas. A partir daí, o backend pode encontrar os restaurantes mais próximos, ranqueá-los por tempo de deslocamento em vez de distância em linha reta, ou geocodificar um endereço específico. Isso permite que o agente diga algo acionável, como “a unidade mais próxima fica na Rua Principal, a cerca de cinco minutos daqui”.

Processamento de voz com Amazon Nova 2 Sonic

O Amazon Nova 2 Sonic realiza o trabalho de voz dentro da chamada. Ele reconhece fala em diferentes sotaques e lida com a qualidade de áudio variável de uma linha telefônica. Transmite áudio em ambas as direções com baixa latência e chama ferramentas de forma assíncrona sem interromper a conversa (veja chamadas de ferramentas assíncronas no Amazon Nova Sonic), então o cliente não fica esperando enquanto os dados são buscados. Ele também lida com interrupções, permitindo que o cliente fale sobre o agente como ocorre em chamadas humanas.

Um detalhe específico para chamadas telefônicas: uma consulta ao backend pode levar alguns segundos, e o Amazon Nova 2 Sonic encerra uma sessão que fica ociosa por tempo demais. Para manter a sessão aberta durante uma chamada de ferramenta lenta, o agente envia um frame silencioso em intervalos curtos. A sessão permanece ativa e o cliente não percebe nada incomum.

Conexão do agente ao backend via MCP

O agente nunca chama as funções Lambda do backend diretamente. O AgentCore Gateway fica no meio e apresenta os endpoints do backend como ferramentas MCP que o agente descobre e chama pelo nome — cobrindo consultas de cardápio, operações de carrinho, registro de pedidos, histórico de clientes, geocodificação e busca de localização.

Isso significa que o agente não precisa saber qual função Lambda está por trás de uma operação ou como se autenticar nela. Quando o agente chama uma ferramenta como PlaceOrder, o gateway transforma isso em uma requisição REST ao Amazon API Gateway, que roteia para a função Lambda correspondente. Como o agente fala com ferramentas nomeadas em vez de funções específicas, é possível alterar um handler do backend ou adicionar uma ferramenta sem mudar o agente.

Reconhecendo o cliente sem login

Um cliente que liga não faz login, então o sistema usa o número de telefone como base de identidade. O sistema aplica um hash no número com um valor secreto armazenado no AWS Systems Manager Parameter Store, e o resultado se torna o identificador de sessão. O número bruto não aparece em logs nem no estado da sessão — o que ajuda a atender requisitos de tratamento de Informações de Identificação Pessoal (PII).

Se o identificador corresponder a um cliente conhecido, o agente cumprimenta o cliente pelo nome e pode oferecer o último pedido. Caso contrário, o cliente faz o pedido como convidado. Vale destacar que essa abordagem reconhece um cliente recorrente, mas não é verificação de identidade. Qualquer pessoa com acesso ao mesmo telefone pode fazer um pedido sob aquela identidade. Uma implantação em produção que exija identidade verificada pode adicionar uma etapa como uma senha de uso único enviada por SMS.

Pré-requisitos e implantação com AWS CDK

Antes de começar, é necessário ter:

• Uma conta AWS.
• Acesso ao modelo Amazon Nova 2 Sonic no Amazon Bedrock na região de implantação, solicitado na página de acesso a modelos do console do Amazon Bedrock.
• Acesso ao Amazon Chime SDK PSTN Audio, com aumento de cota de número de telefone solicitado no console do Amazon Chime SDK.
• Node.js 24.x ou superior.
• Interface de Linha de Comando da AWS (AWS CLI) 2.x configurada com credenciais.
• git para clonar o repositório.
• AWS CDK com bootstrap na conta e região alvo.

A solução completa está disponível no repositório de exemplo no GitHub. Após clonar o repositório, o fluxo de implantação é:

git clone https://github.com/aws-samples/sample-restaurant-telephony-ai-host-using-amazon-bedrock-agentcore-nova-sonic.git
cd sample-restaurant-telephony-ai-host-using-amazon-bedrock-agentcore-nova-sonic

Execute a verificação pré-implantação, que confirma se Node.js, AWS CLI, git, bootstrap do AWS CDK e acesso ao modelo Amazon Bedrock estão todos configurados:

./scripts/preflight-check.sh

Em seguida, execute o script de implantação com um prefixo de implantação. O prefixo é adicionado ao nome de cada recurso, permitindo implantar a solução mais de uma vez na mesma conta:

./scripts/deploy-all.sh --deploymentPrefix qsr-tel

O script implanta cada stack do Kit de Desenvolvimento de Nuvem da AWS (AWS CDK) em ordem, passando as saídas de uma stack para a seguinte. A construção da imagem de container do agente leva alguns minutos na primeira vez. Quando o script termina, ele exibe o número para discar: Your telephony agent is live at +1XXXXXXXXXX. Dial to test.

A região US East (N. Virginia), us-east-1, é recomendada como ponto de partida, pois é onde o Amazon Nova 2 Sonic, o Amazon Chime SDK PSTN Audio e o AgentCore Runtime estão disponíveis.

Custos e limpeza

Os dois maiores itens de custo são a cobrança por minuto do número gratuito e as tarefas Fargate sempre ativas. É possível reduzir ambos: um número DID (Discagem Direta a Ramal) local custa menos por minuto que um número gratuito, e escalar as tarefas Fargate para baixo fora do horário comercial reduz o custo de computação. Recomenda-se configurar um orçamento no AWS Cost Explorer para acompanhar os gastos.

Para remover os recursos e evitar cobranças contínuas, o script de limpeza exclui as stacks na ordem inversa:

# Visualize o que será excluído sem remover nada.
./scripts/cleanup-all.sh --dry-run

# Exclua todas as stacks criadas pela implantação.
./scripts/cleanup-all.sh

A limpeza é destrutiva: libera o número gratuito, exclui o histórico de pedidos no Amazon DynamoDB, remove o segredo no AWS Systems Manager Parameter Store e exclui as imagens de container no Amazon ECR. Faça backup de tudo que quiser manter antes de executar. Após o script finalizar, confirme no console do AWS CloudFormation que as stacks foram removidas (veja Visualizando dados e recursos de stacks do AWS CloudFormation no Console de Gerenciamento da AWS) e no console do Amazon Chime SDK que o número gratuito foi liberado (veja Gerenciando números de telefone no Amazon Chime SDK).

Conclusão

A arquitetura publicada pela AWS mantém telefonia, agente e backend independentes, de modo que cada parte pode evoluir por conta própria. É possível atualizar dados do cardápio, trocar o modelo de voz ou adicionar um canal sem coordenar mudanças em toda a stack. Para o restaurante, isso significa que pedidos por telefone chegam sem tirar funcionários do balcão, os clientes recebem um cumprimento imediato em vez de música de espera, e o sistema lida com os horários de pico sem precisar de mais pessoal. Novas capacidades como reservas ou pontos de fidelidade podem ser adicionadas simplesmente registrando novas ferramentas MCP, sem alterar o agente ou a camada de telefonia.

Para começar, clone o repositório de exemplo no GitHub e execute a verificação pré-implantação. A partir daí, substitua os dados de exemplo nas definições de tabela do DynamoDB com seus próprios itens de cardápio, localizações e preços, e atualize os templates de prompt no Parameter Store com o nome do restaurante, estilo de cumprimento e regras de pedido.

Fonte

Building a restaurant telephony AI host with Amazon Bedrock AgentCore and Amazon Nova 2 Sonic (https://aws.amazon.com/blogs/machine-learning/building-a-restaurant-telephony-ai-host-with-amazon-bedrock-agentcore-and-amazon-nova-2-sonic/)

O desafio de monitorar pipelines de ML distribuídos

Organizações que adotam estratégias de Operações de Aprendizado de Máquina (MLOps) frequentemente distribuem seus fluxos de trabalho de ML entre várias contas e regiões AWS. O Amazon SageMaker permite automatizar esses workloads por meio do SageMaker Pipelines, mas acompanhar o que está acontecendo em cada ambiente se torna rapidamente um problema operacional.

Sem uma solução centralizada, desenvolvedores e engenheiros de operações precisam alternar manualmente entre contas e regiões para inspecionar execuções de pipelines — o que gera retrabalho, aumenta o risco de falhas passarem despercebidas e torna o dia a dia mais lento. O Amazon SageMaker Studio oferece monitoramento nativo, mas apenas dentro de uma única conta e região.

Para resolver isso, a AWS publicou uma solução que centraliza o monitoramento de SageMaker Pipelines em múltiplas contas e regiões usando dashboards personalizados no Amazon CloudWatch. O código de infraestrutura está disponível em um repositório no GitHub baseado no AWS Cloud Development Kit (AWS CDK), permitindo customizações conforme as necessidades de cada organização.

Visão geral da solução

A solução propõe um dashboard interativo no CloudWatch que oferece visibilidade unificada sobre SageMaker Pipelines rodando em múltiplas contas e regiões AWS. A arquitetura escolhida é serverless e orientada a eventos, respondendo às mudanças de estado dos pipelines em tempo real — sem a necessidade de sistemas de monitoramento sempre ativos ou mecanismos de polling.

O modelo adotado é o hub-and-spoke: uma conta central (o hub) concentra o monitoramento, enquanto componentes leves em cada conta ou região secundária (os spokes) capturam os dados do SageMaker Pipelines e os encaminham para o hub. Isso reduz a complexidade operacional e centraliza a visualização.

Os dois stacks do AWS CloudFormation

A solução é composta por dois stacks principais do AWS CloudFormation:

• Dashboard Stack: contém o dashboard do CloudWatch, tabelas de armazenamento no Amazon DynamoDB e funções AWS Lambda responsáveis pelo processamento e visualização dos dados. É implantado apenas na conta e região primária, que atua como o hub de monitoramento.
• Forwarder Stack: é implantado nas contas monitoradas (os spokes). Esses stacks leves utilizam o Amazon EventBridge para capturar eventos e encaminhar dados enriquecidos ao hub central.

Como o fluxo de dados funciona

O funcionamento completo da solução segue o seguinte encadeamento:

• Quando uma etapa de um SageMaker Pipeline muda de status, o Amazon SageMaker AI gera eventos de origem contendo metadados como o horário do evento, o Nome de Recurso Amazon (ARN) do pipeline e da execução, e o status da etapa.
• Regras do EventBridge capturam esses eventos em tempo real e os enviam para funções Lambda para processamento.
• As funções Lambda enriquecem os dados com metadados adicionais — como o nome de exibição e o status da execução — e os enviam ao barramento local do EventBridge.
• Regras customizadas do EventBridge encaminham os dados enriquecidos para a conta hub de monitoramento. Papéis e políticas de recursos do AWS Identity and Access Management (IAM) garantem a segurança na transmissão de eventos entre contas.
• Uma regra do EventBridge na conta de monitoramento aciona uma função Lambda que ingere os dados de cada execução de pipeline e os armazena em tabelas do DynamoDB. As informações armazenadas incluem região, ID da conta, horários de criação, início e fim, nome de exibição e status de cada execução e de suas etapas individuais.
• Funções Lambda alimentam o backend do dashboard, lendo as tabelas do DynamoDB e retornando HTML formatado.
• Um dashboard do CloudWatch com widgets personalizados funciona como interface de usuário diretamente no AWS Management Console, exibindo as execuções com IDs de conta, regiões, horários de criação e status atual.
• Elementos interativos permitem filtrar dados por nome de pipeline e acessar informações detalhadas sobre as etapas de uma execução específica, incluindo nome, tipo, horários de início e fim e status.
• O CloudWatch dispara um alarme em caso de atividade anômala dos usuários do dashboard. O Amazon Simple Notification Service (Amazon SNS) então envia um alerta para os assinantes de um tópico SNS criptografado com uma chave gerenciada pelo cliente no AWS Key Management Service (AWS KMS). Os alarmes são acionados quando as chamadas dos widgets às funções Lambda ultrapassam os limites definidos no Dashboard Stack.

Pré-requisitos para implantação

Antes de implantar a solução, é necessário ter os seguintes recursos configurados:

• Uma conta AWS com duas regiões preparadas para o AWS CDK. Uma região hospedará o dashboard de monitoramento e a outra gerará eventos cross-region do SageMaker Pipelines.
• Uma segunda conta AWS com pelo menos uma região preparada para gerar eventos cross-account.
• Credenciais AWS configuradas como variáveis de ambiente no shell, com permissões suficientes para implantar a solução.
• Python (versão 3.14 ou superior).
• O AWS CDK instalado (versão 2.1100.1 ou superior).
• A AWS Command Line Interface (AWS CLI) instalada (versão 2.32.12 ou superior).
• Docker, necessário para o empacotamento das funções Lambda.
• Pelo menos um SageMaker Pipeline em cada combinação de conta e região. Caso não existam pipelines, é possível criá-los via SageMaker AI Projects pelo SageMaker Studio em um domínio Amazon SageMaker AI.

Como implantar a solução

Com os pré-requisitos atendidos, os passos para implantação são:

• Faça o clone do repositório no GitHub e siga as instruções detalhadas no arquivo README para implantar os stacks usando o AWS CDK e a AWS CLI.
• Acesse o console do AWS CloudFormation em cada conta e região. Selecione o stack DashboardStack ou o ForwarderStack para visualizar detalhes sobre as implantações e os recursos criados.

Testando o dashboard

Após a implantação, é possível validar as funcionalidades do dashboard seguindo os passos abaixo:

• Acesse o console do Amazon CloudWatch e, no painel de navegação, selecione Dashboards. Em seguida, escolha o dashboard PipelineMonitoringDashboard.
• Quando solicitado, permita a execução da função Lambda. Confirme que o nome da função contém customWidget, conforme as boas práticas recomendadas.
• Se não houver execuções recentes de SageMaker Pipelines, inicie novas execuções nas contas e regiões monitoradas — começando, por simplicidade, pela mesma conta e região do dashboard de monitoramento. Recarregue os resultados usando o botão de atualização no canto superior direito do widget.
• Escolha o botão Steps details para visualizar informações detalhadas sobre as etapas individuais do pipeline, incluindo nome, tipo, horários de início e fim e status.
• Utilize o seletor de intervalo de datas no topo do dashboard para filtrar execuções por período personalizado.
• Use o filtro de nome de pipeline no canto superior esquerdo do widget para buscar execuções de um pipeline específico.

Boas práticas e considerações

Flexibilidade e customização

O dashboard pode ser enriquecido com novos dados nas funções Lambda que populam as tabelas do DynamoDB, adicionando lógica de visualização, filtros adicionais, métricas, popups interativos ou widgets nativos do CloudWatch. Além disso, a solução pode ser estendida para monitorar execuções de máquinas de estado do AWS Step Functions, jobs no AWS Batch ou no AWS Glue, e clusters do Amazon EMR que suportem workloads de ML. Nesse caso, considere criar um barramento de eventos dedicado no EventBridge para isolar o tráfego de monitoramento de outros eventos.

Métricas e alarmes

O monitoramento do SageMaker Pipeline pode ser realizado em múltiplas camadas: regras do EventBridge para eventos de serviço, detecção de anomalias em logs do CloudWatch para logs de execução de jobs de ML, e métricas do CloudWatch para utilização de recursos. Configure alarmes adicionais em logs e métricas, ou notificações diretas de eventos, para enviar alertas via Amazon SNS à sua equipe.

Acessibilidade e compartilhamento do dashboard

Considere diferentes formas de compartilhar dashboards do CloudWatch para facilitar o acesso sem precisar passar pelo AWS Management Console. Uma alternativa para visualização de dados é o Amazon Managed Grafana.

Rede privada

Para organizações com requisitos rigorosos de segurança, considere implantar a solução dentro de uma Amazon Virtual Private Cloud (VPC) para maior isolamento. É possível conectar VPCs entre regiões e contas usando conexões de VPC peering ou o AWS Transit Gateway.

Integração com CI/CD

Para maior confiabilidade, implante a solução com pipelines de Integração e Entrega Contínua (CI/CD) nos ambientes que executam seus fluxos de ML. O AWS Organizations e o AWS Deployment Framework (ADF) ajudam a garantir implantações consistentes e repetíveis em todos os ambientes.

Limpeza dos recursos

Para remover os recursos criados, acesse o console do CloudFormation em cada combinação de conta e região onde a solução foi implantada e exclua as instâncias dos stacks DashboardStack ou ForwarderStack. Alternativamente, execute os mesmos comandos do AWS CDK utilizados na implantação, substituindo cdk deploy por cdk destroy. Lembre-se também de excluir os projetos do SageMaker, os recursos e as instâncias do domínio SageMaker AI em cada conta e região, caso tenham sido criados apenas para testar a solução.

Conclusão

A solução apresentada pela AWS oferece uma forma prática de centralizar o monitoramento de SageMaker Pipelines distribuídos em múltiplas contas e regiões, por meio de um dashboard interativo no CloudWatch. A arquitetura serverless e orientada a eventos garante atualizações em tempo quase real, integração direta com o AWS Management Console e escalabilidade sem a necessidade de infraestrutura dedicada sempre ativa.

Para equipes que queiram aprofundar o conhecimento em MLOps, a AWS também disponibiliza recursos complementares, como artigos sobre como implementar uma plataforma MLOps segura com Terraform e GitHub, o guia sobre governança do ciclo de vida de ML em escala com o Amazon SageMaker, o tutorial para construir um pipeline MLOps completo com SageMaker Pipelines, GitHub e GitHub Actions e o post sobre como criar uma solução centralizada de monitoramento para o Amazon SageMaker com o CloudWatch. Para customizações adicionais do dashboard, vale conferir os exemplos de widgets personalizados no CloudWatch.

Fonte

Monitor Amazon SageMaker Pipelines cross-account with custom Amazon CloudWatch dashboards (https://aws.amazon.com/blogs/machine-learning/monitor-amazon-sagemaker-pipelines-cross-account-with-custom-amazon-cloudwatch-dashboards/)

Expansão das instâncias G7e para novas regiões

A AWS anunciou a expansão das instâncias Amazon Elastic Compute Cloud (Amazon EC2) G7e para novas regiões globais. A partir de agora, essas instâncias — aceleradas pelas GPUs NVIDIA RTX PRO 6000 Blackwell Server Edition — estão disponíveis nas regiões Europa (Frankfurt e Estocolmo) e Ásia-Pacífico (Mumbai), ampliando o alcance geográfico para equipes que precisam de alto desempenho em IA e computação gráfica.

O que são as instâncias G7e?

As instâncias G7e representam a geração mais recente de instâncias aceleradas por GPU da AWS, projetadas para cargas de trabalho que exigem tanto processamento gráfico quanto capacidade de inteligência artificial. Em termos de desempenho de inferência, a AWS indica um ganho de até 2,3x em relação às instâncias G6e, o que as torna uma escolha relevante para quem já utiliza a geração anterior e busca mais eficiência.

Especificações técnicas

Do ponto de vista de hardware, as instâncias G7e contam com:

• Até 8 GPUs NVIDIA RTX PRO 6000 Blackwell Server Edition, com 96 GB de memória por GPU
• Processadores Intel Xeon de 5ª Geração
• Suporte a até 192 CPUs virtuais (vCPUs)
• Largura de banda de rede de até 1.600 Gbps

Além disso, as instâncias G7e suportam o NVIDIA GPUDirect Peer to Peer (P2P), tecnologia que melhora o desempenho em cargas de trabalho com múltiplas GPUs. As configurações com múltiplas GPUs também contam com suporte ao NVIDIA GPUDirect Acesso Remoto Direto à Memória (RDMA) com EFA em EC2 UltraClusters, o que reduz a latência em cargas de trabalho distribuídas de pequena escala com múltiplos nós.

Casos de uso

A AWS posiciona as instâncias G7e para uma variedade de cenários de alto desempenho, incluindo:

• Implantação de modelos de linguagem de grande escala (LLMs)
• Modelos de IA agêntica
• Modelos de IA generativa multimodal
• Modelos de IA física
• Cargas de trabalho de computação espacial que demandam processamento gráfico e de IA simultaneamente

Regiões disponíveis

Com a expansão anunciada, as instâncias G7e agora estão disponíveis nas seguintes regiões da AWS:

• US West (Oregon)
• US East (Norte da Virgínia e Ohio)
• Europa (Espanha, Londres, Frankfurt e Estocolmo)
• Ásia-Pacífico (Tóquio, Seul e Mumbai)

Modelos de compra

As instâncias G7e podem ser adquiridas como Instâncias On-Demand, Instâncias Spot ou como parte dos Savings Plans — os modelos tradicionais de compra da AWS que permitem equilibrar flexibilidade e economia conforme a necessidade de cada workload.

Como começar

Para provisionar instâncias G7e, é possível utilizar o Console de Gerenciamento da AWS, a Interface de Linha de Comando (CLI) da AWS ou os SDKs da AWS. Para detalhes técnicos completos sobre as instâncias, a documentação oficial está disponível na página das instâncias G7e.

Fonte

Amazon EC2 G7e instances now available in additional regions (https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-g7e-additional-regions/)

O problema que essa solução resolve

Um dos maiores obstáculos na construção de aplicações de IA no mundo real sempre foi a desconexão entre três capacidades fundamentais: sistemas que enxergam, sistemas que raciocinam e sistemas que agem. Desenvolvedores frequentemente precisam gerenciar múltiplas APIs, criar integrações customizadas e lidar com soluções frágeis para conectar essas peças — o que resulta em implementações ineficientes e caras.

Para endereçar esse desafio, a AWS publicou uma arquitetura de referência que converge três tecnologias-chave: Visão Computacional, Strands Agents e o Protocolo de Contexto de Modelo (MCP). Juntas, essas tecnologias formam um pipeline onde informações visuais podem ser capturadas, compreendidas e utilizadas dentro de um único framework unificado — reduzindo as barreiras tradicionais entre percepção, tomada de decisão e ação.

Visão geral da arquitetura

Na arquitetura proposta, o cliente interage com múltiplos serviços AWS por meio de uma função centralizada do Gerenciamento de Identidade e Acesso da AWS (IAM), que atua como gateway de segurança para o gerenciamento de permissões. Esse modelo elimina a necessidade de credenciais incorporadas no cliente e simplifica o controle de acesso entre os serviços envolvidos.

Os serviços que compõem a solução são:

• Amazon Simple Storage Service (Amazon S3): armazenamento de objetos para recuperar e gerenciar os dados visuais.
• Amazon OpenSearch: capacidades de busca para consultar dados indexados.
• Amazon Bedrock: acesso a modelos de IA generativa para tarefas como geração de texto pelo agente.
• Amazon Rekognition: análise de imagens, incluindo detecção de objetos e identificação de labels.

As três tecnologias centrais

A solução é sustentada por três pilares tecnológicos que vale entender individualmente antes de ver como se integram:

• Visão Computacional: foca no processamento de informações visuais, como fotos e vídeos.
• Strands Agents: é um framework para construção de agentes de IA que suporta múltiplos provedores de modelos e ambientes de implantação. Oferece um loop de agente customizável com capacidades de produção, incluindo observabilidade, rastreamento e implantação escalável.
• Protocolo de Contexto de Modelo (MCP): é um padrão criado para simplificar como sistemas de IA se integram com ferramentas e fontes de dados, substituindo a necessidade de construir conexões separadas para cada par de modelo e fonte de dados.

Interface com o usuário (cliente MCP)

A interface da aplicação é construída com Streamlit e oferece um chat UI intuitivo. No painel lateral, o usuário pode selecionar o modelo de fundação preferido para análise — o padrão é o Claude 4 Sonnet com capacidades de raciocínio, mas também há suporte ao Claude 3.7 Sonnet. Há ainda um botão dedicado para resetar o histórico da conversa.

A seção central da interface permite o upload de conteúdo visual. O sistema aceita imagens (PNG, JPG, JPEG, GIF, WEBP) e vídeos (MP4, AVI, MOV, MKV, WEBM, MPEG4), com limite de 200 MB por arquivo. Após o upload, o agente de IA pode realizar tarefas como recorte de objetos, detecção de labels e análise detalhada do conteúdo. O usuário interage pelo campo de mensagem na parte inferior da tela.

Servidores MCP de Visão Computacional

A implementação é composta por dois servidores: o servidor CV e o servidor OpenSearch. Cada um trata tipos diferentes de requisições.

Servidor CV

O servidor CV da AWS consolida três serviços de IA da Amazon em um protocolo padronizado, permitindo que agentes de IA acessem e processem conteúdo visual por meio de uma API consistente. As ferramentas disponíveis são:

• describe_image: usa o modelo Claude no Amazon Bedrock para analisar imagens com base em instruções de monitoramento específicas. Recupera imagens do Amazon S3 e as processa pelas capacidades multimodais do Claude. É útil para gerar descrições ou identificar atributos específicos dentro das imagens.
• analyze_video: usa as capacidades de análise de vídeo do Amazon Nova para processar arquivos de vídeo armazenados no S3, de acordo com instruções específicas fornecidas pelo usuário.
• detect_labels: integra-se ao Amazon Rekognition para detecção de labels e análise de propriedades de imagens. Oferece controle sobre parâmetros como limiares de confiança, contagem máxima de labels e filtros customizados. Identifica objetos, cenas e atividades, fornecendo coordenadas de bounding box para localização espacial.
• crop_bounding_box: também usa o Amazon Rekognition para detectar elementos-chave como faces, objetos ou texto, e então fornece coordenadas precisas de bounding box para recorte inteligente da imagem.
• remove_background: usa a biblioteca rembg para remoção de fundo de imagens sem exigir configurações complexas ou expertise avançada em aprendizado de máquina (ML).

O código abaixo ilustra a estrutura geral da ferramenta describe_image, mostrando como a imagem é recuperada do S3, validada quanto ao tipo de conteúdo e enviada ao Claude para análise:

async def describe_image(image_file_name: str, monitoring_instructions: str) ...
    try:
        # Get the image from S3
        prefix = f"mcp/{image_file_name}"
        print(f"\n[DEBUG] Attempting to analyze image at s3://{Connections.agent_bucket_name}/{prefix}\n")
        response = Connections.s3_client.get_object(
            Bucket=Connections.agent_bucket_name,
            Key=prefix
        )
        image_data = response['Body'].read()
        content_type = response['ContentType']

        # Ensure content type is supported by Bedrock
        valid_content_types = ['image/jpeg', 'image/png', 'image/gif', 'image/webp']
        if content_type not in valid_content_types:
            # Try to determine from file extension
            if image_file_name.lower().endswith(('.jpg', '.jpeg')):
                content_type = 'image/jpeg'
            elif image_file_name.lower().endswith('.png'):
                content_type = 'image/png'
            elif image_file_name.lower().endswith('.gif'):
                content_type = 'image/gif'
            elif image_file_name.lower().endswith('.webp'):
                content_type = 'image/webp'
            else:
                content_type = 'image/jpeg'  # Default fallback
            print(f"[DEBUG] Content type corrected to: {content_type}")

        # Create the prompt for Claude
        prompt = create_multimodal_prompt(
            image_data=image_data,
            text=monitoring_instructions,
            content_type=content_type,
            system_prompt=(
                "You are a helpful assistant that analyzes images. "
                "Provide detailed, accurate descriptions based on the user's instructions."
            )
        )

        # Get analysis from Claude
        analysis = invoke_bedrock_model(prompt)
        return ImageAnalysisResponse(
            status="success",
            source=prefix,
            analysis=analysis,
            message="Image analysis completed successfully"
        )
    except Exception as e:
        logger.error(f"Error analyzing image: {str(e)}")
        return ImageAnalysisResponse(
            status="error",
            source=image_file_name,
            analysis=None,
            message=f"Error analyzing image: {str(e)}"
        )

Servidor OpenSearch

O servidor OpenSearch fornece uma interface unificada para ingestão e recuperação de imagens. As ferramentas disponíveis são:

• generate_image_description: usa os modelos Claude do Amazon Bedrock para analisar imagens e gerar descrições em linguagem natural, processando as imagens pelas capacidades multimodais do Claude.
• generate_multimodal_embedding: usa os modelos Amazon Titan multimodais para criar representações vetoriais de alta dimensão (embeddings) que capturam informações visuais e textuais, codificando relações semânticas entre imagens e texto em um espaço vetorial compartilhado.
• ingest_image_to_opensearch: oferece um pipeline completo para processar e armazenar imagens no OpenSearch, combinando geração de descrição e criação de embeddings multimodais, indexando essas informações com metadados adequados.
• query_images_by_text: permite busca em linguagem natural em coleções de imagens usando os embeddings multimodais armazenados no OpenSearch. Consultas em texto são convertidas em embeddings e comparadas com os embeddings de imagens para encontrar os matches mais semanticamente similares.
• query_images_by_image: implementa busca baseada em imagem, permitindo que usuários encontrem imagens similares usando uma imagem como entrada de consulta.
• bulk_ingest_images: oferece capacidade de processamento em lote para ingestão de imagens em larga escala, gerenciando processamento paralelo e utilização de recursos.

Casos de uso práticos

Caso de uso 1: Pipeline de visão computacional sem infraestrutura dedicada

A arquitetura permite implementar capacidades de análise visual sem a complexidade tradicional de configurar e manter infraestrutura extensa. Desenvolvedores podem realizar tarefas como geração de bounding boxes, criação de descrições detalhadas de imagens e análise de vídeos — tudo sem servidores dedicados ou sistemas de gerenciamento complexos. O modelo de pagamento por uso e a implantação rápida são diferenciais importantes dessa abordagem.

Caso de uso 2: Catálogo inteligente de imagens com embeddings

Ao gerar e armazenar embeddings de imagens em um banco de dados vetorial, a solução vai além das limitações de buscas tradicionais baseadas em palavras-chave, permitindo recuperação de imagens com compreensão contextual. O sistema usa modelos de IA para criar embeddings ricos que capturam a essência semântica das imagens, permitindo encontrar conteúdo visualmente similar mesmo quando não há correspondência exata de palavras-chave. Isso cria um sistema de catalogação escalável que entende relações e contextos visuais — especialmente valioso para grandes coleções de imagens.

Caso de uso 3: Banco de memória visual para raciocínio contextual

Este caso de uso combina o pipeline de visão computacional com busca por similaridade baseada em embeddings. O sistema processa cenas para extrair objetos e seus bounding boxes, gera embeddings para cada elemento e os armazena com metadados ricos — incluindo informações temporais e espaciais. Isso permite raciocínio contextual entre múltiplas câmeras e períodos de tempo, respondendo perguntas complexas sobre indivíduos, suas associações e a presença de objetos em áreas específicas. A integração com agentes de monitoramento de vídeo viabiliza funcionalidades como detecção de atividades suspeitas e análise de padrões históricos.

Como implantar a solução

Para começar, é necessário ter instalado: AWS Command Line Interface (AWS CLI), uma conta AWS ativa e Python. O processo de implantação completo está documentado no README do repositório GitHub da solução.

Limpeza de recursos

Para evitar cobranças contínuas após os testes, a AWS recomenda as seguintes etapas: esvaziar o bucket do S3 utilizado e excluir a stack do AWS CloudFormation criada durante a implantação.

Conclusão

A integração entre as capacidades de IA do Amazon Bedrock, os protocolos padronizados do MCP e os serviços de visão computacional da AWS demonstra como aplicações modernas de visão computacional podem ser ao mesmo tempo sofisticadas e acessíveis. A solução endereça desafios recorrentes no campo: reduz a complexidade de infraestrutura por meio de arquiteturas serverless, oferece compreensão semântica, capacidades de raciocínio contextual e interfaces padronizadas que simplificam o desenvolvimento e a implantação.

A combinação de protocolos padronizados, modelos de IA poderosos e opções flexíveis de implantação posiciona essa solução como base para a próxima geração de aplicações de inteligência visual — onde padronização, acessibilidade e integração serão cada vez mais determinantes para construir sistemas práticos e escaláveis que conectam percepção visual e ação inteligente.

Fonte

Agentic vision: Building visual intelligence with Amazon Bedrock and MCP servers (https://aws.amazon.com/blogs/machine-learning/agentic-vision-building-visual-intelligence-with-amazon-bedrock-and-mcp-servers/)

O problema clássico dos testes de UX

Testar a experiência do usuário em interfaces digitais é uma das tarefas mais importantes — e mais negligenciadas — no desenvolvimento de produtos. O motivo é simples: escala. Testadores humanos conseguem cobrir apenas uma fração dos fluxos possíveis, priorizando os caminhos críticos e deixando casos de borda sem validação. Já as ferramentas tradicionais de automação, como Selenium ou Playwright, dependem de seletores de elementos hard-coded que quebram toda vez que a interface muda, gerando um custo de manutenção que inviabiliza a cobertura ampla.

Diferente do Controle de Qualidade (QA) convencional, que busca bugs funcionais, os testes de UX avaliam se o usuário consegue navegar com facilidade para completar uma tarefa — comprar um produto, criar uma conta, finalizar um pagamento. Esse tipo de análise exige raciocínio contextual, não apenas verificação de elementos na tela.

O que é o Amazon Nova Act e por que ele muda o jogo

A AWS apresentou o Amazon Nova Act como um modelo de fundação multimodal capaz de entender e interagir com interfaces de navegadores web por meio de visão e ação. Em vez de depender de seletores predefinidos, o Nova Act navega por sites de forma inteligente: ele analisa capturas de tela das páginas exatamente como um testador humano faria, identifica elementos interativos por pistas visuais e toma decisões contextuais sobre qual ação executar em seguida.

Essa capacidade de compreensão visual torna o Nova Act resiliente a mudanças de interface e a conteúdos dinâmicos — situações que normalmente quebrariam ferramentas de automação tradicionais. Além disso, os logs de raciocínio e cadeia de pensamento (chain of thought) gerados pelo modelo oferecem insights valiosos sobre o design e a intuitividade do site testado.

Visão geral da solução

A AWS publicou uma arquitetura de referência que combina o Nova Act com serviços gerenciados para criar uma plataforma de testes de UX implantada na nuvem. A solução é dividida em quatro camadas principais:

Camada de processamento de documentação

É a base da solução. O Amazon Simple Storage Service (S3) armazena a documentação do site, guias de usuário e especificações de fluxos de teste. Esse conteúdo não estruturado é ingerido em uma Base de Conhecimento do Amazon Bedrock para busca por similaridade semântica. Em seguida, o AWS Lambda utiliza o Claude 4.5 Sonnet via Amazon Bedrock para transformar fluxos de usuário em cenários de teste detalhados, consultando a base de conhecimento para entender como cada tarefa é realizada na arquitetura específica do site.

Camada de orquestração

O Amazon DynamoDB armazena os fluxos de teste gerados com metadados e parâmetros de execução. O DynamoDB Streams dispara o processamento em lote quando novos fluxos ficam disponíveis, e funções Lambda coordenam a execução e acionam tarefas no Amazon Elastic Container Service (ECS) para processamento paralelo.

Camada de execução

O Amazon ECS com AWS Fargate fornece computação serverless escalável para a execução paralela dos testes. Os agentes do Amazon Nova Act executam os fluxos de usuário em sessões de navegador simultâneas, com registro em tempo real de toda a interação para análise posterior.

Camada de análise

O Amazon S3 armazena os logs detalhados de raciocínio, capturas de tela e dados comportamentais. Funções Lambda processam esses resultados usando o Amazon Bedrock para calcular pontuações de usabilidade, identificar pontos de atrito e analisar padrões de execução em diferentes níveis de granularidade das instruções. Os resultados ficam disponíveis em um dashboard React.

Como implantar a solução

Antes de começar, é necessário ter: Node.js v20 ou superior, npm v10.8 ou superior, uma conta AWS e o Kit de Desenvolvimento em Nuvem da AWS (AWS CDK) configurado (veja como começar com o AWS CDK).

O código completo e as instruções de implantação estão disponíveis no repositório aws-samples no GitHub. A implantação usa o AWS CDK para automatizar toda a infraestrutura:

git clone git@github.com:aws-samples/sample-nova-act-ux-testing.git
cd nova-act-ux-testing
cp template.env .env
# Add your Nova Act API key in .env
# Deploy the solution
./deploy.sh

Ao final da implantação, o stack exibe outputs importantes que serão usados nas etapas seguintes.

Criando fluxos de teste

Após a implantação, há três abordagens para criar os fluxos de teste: geração automática a partir de documentação, definição manual ou uma combinação das duas. A AWS recomenda o modelo híbrido: usar a geração automática para estabelecer cobertura de base a partir da documentação existente e complementar com fluxos definidos manualmente para casos de borda, novas funcionalidades ou cenários que exigem controle preciso.

Opção 1: Geração automática de fluxos a partir de documentação

Uma função Lambda integrada ao Claude 4.5 Sonnet converte tarefas de usuário em fluxos de teste detalhados. Para aproveitar bem o sistema, é recomendado incluir múltiplas formas de atingir o mesmo objetivo. Por exemplo, se “comprar uma cafeteira” é um fluxo-chave, inclua tanto a abordagem por busca quanto a navegação por menus como tarefas separadas.

O sistema produz instruções em três níveis de detalhe. Uma instrução básica pode ser “compre uma cafeteira de aço inoxidável bem avaliada”, enquanto a versão detalhada expande isso em ações precisas: selecionar eletrodomésticos de cozinha no menu, aplicar filtros de material e avaliação, e concluir o processo de compra. Para mais detalhes, veja o arquivo lambda/flow_discovery/index.py no repositório.

O processo envolve: fazer upload da documentação do aplicativo no bucket S3 designado (o sistema suporta manuais de usuário, especificações de funcionalidades, documentos de jornadas comuns e casos de teste existentes), fazer upload do arquivo tasks.json no bucket uxflowteststack-tasksbucket para disparar a descoberta de fluxos, aguardar o processamento assíncrono e revisar os fluxos gerados na tabela do DynamoDB.

Opção 2: Definição manual de fluxos

Para controle preciso sobre cenários específicos, é possível definir fluxos customizados inserindo-os diretamente na tabela do DynamoDB. Essa abordagem é ideal para testar casos de borda específicos, validar novas funcionalidades antes que a documentação exista e testar fluxos que exigem contexto ou dados específicos de usuário.

Os componentes principais de um fluxo manual são: flow_id (identificador único para rastreamento e correlação de resultados), starting_url (página onde o fluxo de teste começa), instructions (array de passos em linguagem natural para o Nova Act executar), method_name (representa um método diferente para completar a mesma tarefa, como busca versus navegação) e gran_n (representa diferentes níveis de granularidade das instruções).

Personalizando a solução

Para aplicações que exigem autenticação, é possível configurar sessões persistentes no navegador para manter o estado de login entre execuções de teste, eliminando a necessidade de reautenticar a cada execução. O código Python que executa os fluxos do Nova Act no Amazon ECS está em ecs/ecs_act_headless/app.py. Veja um exemplo de configuração de autenticação persistente:

with NovaAct(
    starting_page="https://yourapp.com/purchase",
    user_data_dir="/tmp/authenticated-session",
    clone_user_data_dir=False
) as nova:
    # Your authenticated test flows run here
    nova.act("search for bananas")
    nova.act("purchase 2 bunches")

O Nova Act também suporta esquemas Pydantic para extração confiável de dados estruturados de páginas web, além de operações com arquivos para testar fluxos de upload e validar conteúdo baixado. Para implementação detalhada dessas funcionalidades, consulte a documentação do SDK do Nova Act.

Resultados e métricas gerados

Para cada execução de teste, a solução gera e armazena no Amazon S3 um arquivo results_summary.json contendo métricas de alto nível: duração de cada etapa, número de ações necessárias, status de sucesso ou falha e quaisquer dados extraídos. Veja o formato do arquivo de resumo:

{
  "flow_id": "ecommerce_purchase_flow",
  "batch_id": "batch_12345",
  "timestamp": "2026-07-01T20:50:01.811454",
  "results": [
    {
      "instruction": "search for desk lamp",
      "response": null,
      "metadata": {
        "num_steps": 3,
        "duration": 17.57,
        "success": true
      }
    },
    {
      "instruction": "select the first result",
      "response": null,
      "metadata": {
        "num_steps": 2,
        "duration": 11.1,
        "success": true
      }
    }
  ]
}

Além do resumo, o SDK do Amazon Nova Act gera relatórios HTML detalhados com capturas de tela do que o agente observou, o processo de tomada de decisão e raciocínio, e as ações específicas executadas (cliques, rolagens, preenchimento de formulários).

A função Lambda de análise processa esses resultados brutos e calcula métricas em diferentes camadas de abstração — contagens brutas, sinais ajustados por infraestrutura e pontuações de qualidade compostas. Essas métricas alimentam um dashboard React organizado em abas, como a aba de Visão Geral (com painel de erros ajustados que separa falhas de infraestrutura de falhas reais do agente) e a aba de Desempenho e Eficiência (que detalha o tempo por etapa e por fluxo conforme o nível de granularidade das instruções).

Para limpar todos os recursos implantados, basta executar:

cdk destroy

O que essa abordagem representa na prática

Os testes de UX tradicionalmente exigem tempo e recursos significativos, limitando a profundidade com que as equipes conseguem validar suas interfaces. A combinação das capacidades de interação inteligente com navegadores do Nova Act e a infraestrutura escalável em nuvem cria um novo padrão para esse tipo de validação.

Com essa abordagem, equipes podem testar mais jornadas de usuário, identificar problemas mais cedo no ciclo de desenvolvimento e iterar mais rapidamente na experiência do usuário. Em vez de amostras limitadas, torna-se viável validar jornadas completas em diferentes dispositivos e cenários — reduzindo custos de teste e o tempo gasto em validação manual.

Para saber mais

• Introdução ao Amazon Nova Act
• Página oficial do Amazon Nova Act
• SDK Python do Amazon Nova Act
• Amazon Nova Act SDK (preview): caminho para produção em agentes de automação de navegadores

Fonte

Scaling UX testing with Amazon Nova Act: A new approach to user flow analysis (https://aws.amazon.com/blogs/machine-learning/scaling-ux-testing-with-amazon-nova-act-a-new-approach-to-user-flow-analysis/)