Blog

O problema que essa integração resolve

Profissionais de RH, finanças e operações lidam diariamente com um desafio clássico: as informações que precisam para tomar decisões estão espalhadas em sistemas diferentes. Dados de headcount vivem em um lugar, metas orçamentárias em outro, políticas internas em um terceiro. Cruzar tudo isso manualmente consome horas e ainda assim o resultado pode estar desatualizado.

É exatamente esse problema que a integração entre a Visier e o Amazon Quick via Protocolo de Contexto de Modelo (MCP) se propõe a resolver. A ideia central é simples: conectar dados ao vivo da força de trabalho com o contexto organizacional interno, tudo acessível por meio de perguntas em linguagem natural.

Os componentes da solução

Amazon Quick

O Amazon Quick é descrito pela AWS como um workspace de Inteligência Artificial (IA) agêntica. Ele funciona como uma interface unificada para usuários de negócio, reunindo conhecimento corporativo, inteligência de negócios e automação de fluxos de trabalho em um único lugar. Seus agentes inteligentes recuperam informações e raciocinam sobre múltiplas camadas de dados simultaneamente, entregando respostas prontas para ação.

Visier

A Visier é uma plataforma de IA para força de trabalho baseada em nuvem que unifica dados de Sistema de Informação de Recursos Humanos (HRIS), folha de pagamento, gestão de talentos e rastreamento de candidatos em uma única camada de inteligência. Ela permite responder perguntas complexas sobre a força de trabalho em minutos, por meio do seu assistente de IA chamado Vee, apoiado por métricas pré-construídas e benchmarks do setor baseados em registros anonimizados de funcionários.

Por meio do seu servidor MCP, a Visier atua como um conector universal que entrega insights governados sobre pessoas diretamente nas ferramentas de IA corporativa onde as decisões são tomadas.

O Protocolo de Contexto de Modelo (MCP)

O MCP é um padrão aberto que permite que agentes de IA se conectem a fontes de dados e ferramentas externas. Funciona como um adaptador universal: o Amazon Quick consegue se comunicar com o agente analista Vee da Visier de forma estruturada e segura, sem precisar construir integrações customizadas do zero. A Visier expõe suas capacidades de análise de força de trabalho por meio de um servidor MCP, e o Amazon Quick inclui um cliente MCP nativo que descobre essas ferramentas e as disponibiliza para seus agentes e automações.

Benefícios para empresas

A integração endereça desafios reais do dia a dia corporativo. Entre os principais benefícios destacados:

• Inteligência unificada da força de trabalho: o Amazon Quick orquestra dados ao vivo da Visier com o conhecimento interno da empresa, entregando respostas sintetizadas que nenhum sistema produziria sozinho.
• Acesso em linguagem natural: usuários fazem perguntas conversacionais e recebem respostas atribuídas à fonte — seja um dado ao vivo da Visier ou um documento de política interna.
• Fluxos de trabalho automatizados e repetíveis: revisões periódicas de força de trabalho, alertas de limites e briefings pré-reunião podem ser configurados uma vez e entregues automaticamente, sem esforço manual.
• Acesso a dados governado e seguro: o servidor MCP da Visier aplica políticas de governança de dados para expor apenas informações autorizadas. O conhecimento corporativo no Quick Spaces mantém os controles de acesso existentes.
• Redução do tempo para obter insights: o que antes exigia horas de cruzamento manual de planilhas pode ser feito rapidamente a partir de uma única interface.

Pré-requisitos

Para configurar essa integração, são necessários:

• Uma conta AWS válida com as permissões de serviço adequadas.
• Um ambiente Amazon Quick com assinatura ativa (como começar).
• Uma conta Visier com acesso à API e servidor MCP habilitado.

Para mais detalhes sobre a configuração do Amazon Quick, a documentação oficial está disponível.

Como configurar a integração

Passo 1: Configurar o servidor MCP da Visier

A Visier fornece um servidor MCP pré-construído que expõe suas capacidades de análise como ferramentas MCP. No console de administração da Visier, é necessário navegar até Configurações > API e Integrações, habilitar o servidor MCP, configurar as credenciais de autenticação e os escopos de acesso a dados, e anotar a URL do endpoint e os detalhes de autenticação. As instruções detalhadas estão na documentação MCP da Visier.

Passo 2: Adicionar a Visier como integração MCP no Amazon Quick

No Amazon Quick, o processo passa por acessar Integrações no painel de navegação esquerdo, selecionar a aba Ações, localizar o bloco do Protocolo de Contexto de Modelo (MCP) e criar uma nova integração. É necessário informar um nome descritivo, uma descrição opcional e a URL do endpoint do servidor MCP da Visier obtida no passo anterior. Depois, selecionar o método de autenticação correspondente e inserir as credenciais. Após criada, o Amazon Quick descobre automaticamente as ferramentas expostas pelo servidor MCP da Visier — como ask_vee_question, search_metrics e list_analytic_object_property_values.

Para mais informações sobre a integração MCP no Amazon Quick, consulte Integrar ferramentas externas com agentes Amazon Quick usando MCP e a documentação de integração MCP.

Passo 3: Organizar o conhecimento corporativo nos Spaces

Os agentes do Amazon Quick utilizam os Spaces como fronteira contextual. Tudo que a organização sabe — políticas internas, documentos de planejamento, conhecimento específico de equipes — é construído dentro de um Space e disponibilizado ao agente no momento da consulta. O passo seguinte é fazer upload dos documentos internos relevantes para o Quick Spaces, criando um Space chamado “Planejamento de Força de Trabalho” e carregando documentos como orçamentos de headcount, diretrizes de remuneração, fluxos de aprovação e requisitos de conformidade.

Cenário de uso: preparando uma reunião de liderança

Para ilustrar a integração, o artigo original apresenta dois usuários fictícios — Maya, parceira de negócios de RH, e David, gerente de finanças — que precisam preparar juntos um briefing para uma reunião de liderança. A organização conectou a Visier ao Amazon Quick via MCP e carregou documentos internos no Quick Spaces, incluindo metas de saúde da força de trabalho para o ano fiscal, políticas de retenção e templates de briefing de risco.

A conversa entre os dois e o agente Amazon Quick percorre seis turnos progressivos:

• Turno 1 — Visão geral: David pergunta quantos funcionários a empresa tem e quantos estão nos EUA. O agente consulta a Visier via MCP e retorna os números ao vivo.
• Turno 2 — Orçamento vs. realidade: David pergunta como o headcount nos EUA se compara às metas de distribuição. O agente consulta a Visier para os dados ao vivo e o documento de metas no Quick Spaces para comparar com o alvo aprovado.
• Turno 3 — Panorama de tempo de serviço: Maya pergunta sobre o tempo médio de serviço e quais funções têm os maiores índices. O agente recupera os dados da Visier e os marcos relevantes da política de retenção no Quick Spaces.
• Turno 4 — Tempo de serviço vs. limites da política: Maya verifica se a média atual atende ao threshold definido na política. O agente compara o dado ao vivo da Visier com o limite armazenado no Quick Spaces.
• Turno 5 — Verificação de alta performance: Maya consulta quantos funcionários de alta performance existem e se a proporção está dentro do recomendado. O agente cruza o dado da Visier com o Playbook de Retenção de Alta Performance no Quick Spaces.
• Turno 6 — Síntese do briefing: David e Maya pedem um resumo dos principais riscos de saúde da força de trabalho. O agente consolida todos os dados dos turnos anteriores, cruza cada métrica com os thresholds e políticas correspondentes, sinaliza os riscos e apresenta as ações recomendadas de cada documento de política.

Automação com Quick Flows

Além das consultas conversacionais, o Amazon Quick oferece o Quick Flows, um motor de automação de fluxos de trabalho que permite definir sequências de múltiplos passos e executá-las em um agendamento ou sob demanda. Um fluxo pode recuperar dados de fontes conectadas, aplicar lógica e comparações, gerar saídas formatadas e entregar os resultados em um destino como uma caixa de entrada ou canal do Slack — tudo sem intervenção manual.

O artigo original apresenta um exemplo de fluxo chamado “Weekly Workforce Health Score” (Pontuação Semanal de Saúde da Força de Trabalho), que executa toda segunda-feira às 8h da manhã. Em seis passos sequenciais, ele:

• Recupera da Visier quatro métricas ao vivo: headcount global total, headcount nos EUA, tempo médio de serviço e contagem de funcionários de alta performance.
• Busca no Quick Spaces as metas e thresholds internos correspondentes a cada métrica.
• Calcula indicadores como percentual de headcount em relação à meta, gap de headcount nos EUA, proporção de alta performance e buffer de tempo de serviço acima da zona de atenção.
• Atribui uma pontuação a cada métrica (Em Dia: 25 pontos; Precisa de Atenção: 15 pontos; Abaixo da Meta: 5 pontos; Revisão Imediata Necessária: 0 pontos) e soma as quatro para gerar uma pontuação composta de 0 a 100.
• Para métricas com pontuação abaixo do ideal, recupera as ações de intervenção recomendadas nos documentos de política do Quick Spaces.
• Gera um briefing formatado com a pontuação composta, uma tabela de métricas com valores reais, metas, gaps e pontuações, e as ações recomendadas por prioridade.

Quick Research: análise profunda e autônoma

O Amazon Quick também oferece o Quick Research, uma capacidade de análise profunda projetada para perguntas que abrangem múltiplas fontes e exigem síntese. Diferente de uma conversa interativa, o Quick Research opera de forma autônoma: o usuário descreve o resultado que precisa em linguagem natural, e o Amazon Quick determina quais bases de conhecimento internas, fontes de dados conectadas e referências externas consultar, montando um relatório estruturado e com atribuição de fontes.

No cenário do artigo, Maya usa o Quick Research antes da reunião para solicitar um relatório de benchmarking da força de trabalho comparando a organização com pares do setor em três dimensões: tempo de serviço dos funcionários, proporções de alta performance e distribuição geográfica da força de trabalho. O Quick Research automaticamente consulta as três camadas: dados ao vivo da Visier via MCP, metas de política interna do Quick Space de Planejamento de Força de Trabalho, e benchmarks externos do setor via web.

Monitoramento e observabilidade

Para administradores que precisam de visibilidade sobre o que está sendo acessado, com que frequência e por quem, o Amazon Quick se integra ao Amazon CloudWatch para expor métricas do conector de ações MCP, como contagens de invocação e taxas de erro. Cada interação de chat pode ser entregue via Amazon CloudWatch Logs para destinos como Amazon Simple Storage Service (Amazon S3) ou Amazon Data Firehose, para análise e retenção de longo prazo. Para auditoria e conformidade, o AWS CloudTrail fornece um registro completo de chamadas de API e ações administrativas em todo o ambiente Amazon Quick.

Conclusão

A integração entre Visier e Amazon Quick via MCP demonstra um padrão que vai além da análise de pessoas: qualquer cenário em que inteligência de negócios especializada precise ser combinada com contexto organizacional interno pode se beneficiar dessa arquitetura. O valor não está em nenhum dos sistemas isoladamente — o Amazon Quick fornece a camada de orquestração e contexto corporativo, a Visier fornece a inteligência sobre a força de trabalho, e o MCP fornece a conexão segura e padronizada entre os dois. Para o usuário final, a experiência é simples: fazer uma pergunta e receber uma resposta que combina tudo que a organização sabe, pronta para agir.

Para começar, a documentação do Amazon Quick cobre configuração do ambiente, integrações e criação de agentes. Para o lado da Visier, a documentação do Servidor MCP da Visier detalha a configuração, autenticação e o conjunto completo de ferramentas de análise disponíveis. Mais informações sobre a plataforma de IA da Visier estão em visier.com. Para um aprofundamento em como o Amazon Quick se conecta a fontes externas via MCP, o artigo Integrar ferramentas externas com agentes Amazon Quick usando MCP é uma boa referência.

Fonte

Building Workforce AI Agents with Visier and Amazon Quick (https://aws.amazon.com/blogs/machine-learning/building-workforce-ai-agents-with-visier-and-amazon-quick/)

O que foi anunciado

A AWS anunciou a disponibilização de oito novas métricas no Amazon Connect voltadas especificamente para monitorar e aprimorar o desempenho de agentes de Inteligência Artificial (IA) em interações com clientes. Entre as novidades, destacam-se métricas como taxa de sucesso de objetivos, pontuação de fidelidade e precisão na seleção de ferramentas.

O que essas métricas permitem monitorar

Com esse conjunto de indicadores, equipes que utilizam o Amazon Connect passam a ter visibilidade real sobre a qualidade das interações conduzidas por agentes de IA. Na prática, é possível acompanhar:

• Se os agentes de IA conseguiram de fato resolver as solicitações dos clientes;
• O nível de fidelidade das respostas geradas — incluindo a detecção de alucinações contextuais, ou seja, quando o agente produz informações incorretas ou inventadas;
• A precisão com que o agente seleciona e utiliza as ferramentas disponíveis para cada situação;
• O feedback direto dos clientes, por meio de avaliações do tipo curtir/não curtir, quando esse recurso estiver habilitado.

Como acessar as novas métricas

As oito novas métricas podem ser acessadas de três formas distintas:

• Pelo painel de desempenho de agentes de IA do próprio Amazon Connect;
• Via API GetMetricDataV2, para quem prefere integrar os dados a fluxos de análise personalizados;
• Por meio do data lake zero-ETL, que facilita a integração com ferramentas de análise já existentes na organização — sem a necessidade de pipelines de transformação de dados.

Disponibilidade

O recurso já está disponível em todas as regiões da AWS onde o Amazon Connect com agentes de IA é suportado. Para consultar a documentação completa e entender como configurar o painel de desempenho, a AWS disponibilizou o Guia do Administrador do Amazon Connect. Quem quiser conhecer mais sobre a plataforma em geral pode acessar o site oficial do Amazon Connect.

Por que isso importa

Monitorar agentes de IA em produção ainda é um desafio para muitas equipes. Ter métricas nativas dentro da própria plataforma de atendimento reduz a complexidade operacional e permite que times de CX (Experiência do Cliente) e engenharia atuem com mais precisão na melhoria contínua dos fluxos automatizados. A detecção de alucinações, em especial, é um ponto crítico para garantir que o cliente receba respostas confiáveis — e agora isso pode ser rastreado diretamente no Amazon Connect.

Fonte

Amazon Connect now provides eight new metrics to measure and improve AI agent performance (https://aws.amazon.com/about-aws/whats-new/2026/04/amazon-connect-ai-agent-metrics/)

Gerenciamento automático de topologia no SageMaker HyperPod

A AWS anunciou uma melhoria significativa no Amazon SageMaker HyperPod: o serviço agora seleciona e mantém automaticamente a configuração ideal de topologia de rede para clusters Slurm, levando em conta os tipos de instâncias GPU presentes no cluster.

Por que a topologia de rede importa no treinamento distribuído

A topologia de rede tem impacto direto na performance do treinamento distribuído. Quando os jobs são alocados em nós que estão topologicamente próximos uns dos outros, a comunicação entre GPUs se torna mais rápida, as operações coletivas do NCCL ficam mais eficientes e o throughput geral do treinamento aumenta. Em outras palavras, a disposição física e lógica dos nós no cluster não é detalhe — ela define o quão bem os recursos de hardware são aproveitados.

Como o HyperPod gerencia a topologia automaticamente

Ao criar um cluster, o HyperPod inspeciona os tipos de instâncias presentes em todos os grupos de instâncias, identifica as características de rede e interconexão de cada tipo, e seleciona automaticamente o modelo de topologia mais adequado. O serviço suporta dois modelos principais:

• Topologia em árvore (tree topology): indicada para instâncias com interconexões hierárquicas, como ml.p5.48xlarge, ml.p5e.48xlarge e ml.p5en.48xlarge.
• Topologia em bloco (block topology): indicada para instâncias com conectividade uniforme de alta largura de banda, como ml.p6e-gb200.NVL72.

Para clusters com tipos de instâncias mistos, o HyperPod seleciona automaticamente uma topologia compatível que funcione de forma coerente em todos os nós.

Adaptação dinâmica ao longo do ciclo de vida do cluster

Um dos pontos mais relevantes dessa novidade é a capacidade de adaptação contínua. À medida que o cluster passa por operações de escalonamento — seja para cima, para baixo ou por substituição de nós — o HyperPod atualiza a configuração de topologia automaticamente, sem necessidade de intervenção manual. Isso garante que a topologia sempre reflita o estado real do cluster, sem exigir atualizações em arquivos de configuração nem reconfigurações do Slurm.

Como começar a usar

Para aproveitar esse recurso, basta criar um cluster SageMaker HyperPod Slurm com os tipos de instâncias GPU suportados. O agendamento com consciência de topologia já vem habilitado por padrão e não requer nenhuma configuração adicional. O recurso está disponível em todas as regiões AWS onde o Amazon SageMaker HyperPod é suportado.

Para mais detalhes sobre o agendamento com consciência de topologia, consulte a documentação oficial do Amazon SageMaker HyperPod.

Fonte

Amazon SageMaker HyperPod now supports automatic Slurm topology management (https://aws.amazon.com/about-aws/whats-new/2026/04/amazon-sagemaker-hyperpod-automatic-slurm-topology/)

O que mudou no SageMaker Unified Studio

A AWS anunciou uma expansão importante no Amazon SageMaker Unified Studio: a partir de agora, os notebooks serverless (sem servidor) com agente de dados integrado também estão disponíveis para domínios que utilizam o AWS IAM Identity Center (IdC) para autenticação e gerenciamento de acesso.

Antes dessa atualização, tanto o ambiente de notebooks quanto o agente de dados estavam disponíveis apenas em domínios IAM. Com essa mudança, equipes que já adotaram o IdC como mecanismo de autenticação passam a ter acesso ao mesmo ambiente de alta performance para cargas de trabalho de análise de dados e aprendizado de máquina (ML).

O que são os notebooks serverless do SageMaker

O notebook serverless do SageMaker Unified Studio funciona como um espaço de trabalho unificado para diferentes perfis técnicos — engenheiros de dados, analistas e cientistas de dados. Em um único ambiente interativo, é possível:

• Executar consultas SQL
• Rodar código Python
• Processar grandes volumes de dados
• Executar cargas de trabalho de ML
• Criar visualizações

A infraestrutura por trás desse ambiente é o Amazon Athena para Apache Spark, o que garante escalabilidade desde consultas SQL interativas até o processamento de dados em escala de petabytes.

O papel do agente de dados com IA integrada

Junto com os notebooks, o agente de dados com inteligência artificial (IA) integrada acelera o desenvolvimento ao gerar código e instruções SQL diretamente a partir de prompts em linguagem natural. Ou seja, o profissional descreve o que precisa em texto simples, e o agente sugere o código correspondente — guiando o usuário ao longo das tarefas.

Essa combinação permite que SQL, Python e linguagem natural coexistam no mesmo workspace, eliminando a necessidade de alternar entre ferramentas diferentes dependendo do tipo de tarefa. Um exemplo prático: é possível começar explorando dados com SQL, avançar para análises mais complexas com Python, e ainda usar prompts em linguagem natural para gerar código automaticamente em qualquer etapa do processo.

Disponibilidade

Os recursos de notebook e agente de dados do SageMaker estão disponíveis em todas as regiões da AWS onde o Amazon SageMaker Unified Studio é suportado.

Para saber mais, a AWS disponibiliza o guia do usuário de notebooks do SageMaker e o guia do usuário do agente de dados do SageMaker com detalhes completos sobre como utilizar esses recursos.

Fonte

Amazon SageMaker supports notebooks and data agent for IdC domains (https://aws.amazon.com/about-aws/whats-new/2026/04/amazon-sagemaker-idc/)

O problema que o AgentCore resolve

Qualquer desenvolvedor que já tentou colocar um agente de IA em funcionamento sabe bem como é: antes de testar se o agente faz algo útil, você passa horas — ou dias — resolvendo problemas de infraestrutura. Precisa escolher um framework, escrever código de orquestração, conectar ferramentas, configurar autenticação, montar pipeline de deploy. Só então o agente consegue processar a primeira requisição de verdade.

É trabalho necessário, mas não é o trabalho que diz se o agente vai ser bom. A AWS identificou esse gargalo e construiu o Amazon Bedrock AgentCore justamente para mudar essa equação — permitindo que times foquem na lógica do agente, não no encanamento de infraestrutura. O serviço já suportava frameworks populares como LangGraph, LlamaIndex, CrewAI e Strands Agents. Agora, a AWS anuncia novas capacidades que aprofundam essa proposta.

Harness gerenciado: do zero ao agente em três etapas

Todo agente precisa de uma camada de orquestração — o loop que chama o modelo, decide qual ferramenta acionar, repassa os resultados, gerencia a janela de contexto e lida com falhas. Para esse loop funcionar, existe uma infraestrutura de suporte: computação para hospedar o agente, sandbox para execução segura de código, conexões seguras com ferramentas, armazenamento persistente e recuperação de erros. Esse conjunto é o que a AWS chama de agent harness.

Até agora, montar esse harness era a primeira tarefa de qualquer time — e consumia dias antes mesmo de o agente processar uma única requisição real. A nova funcionalidade de harness gerenciado no AgentCore substitui toda essa construção inicial por uma configuração direta. Você declara o agente e o coloca para rodar com apenas três chamadas de API, sem escrever código de orquestração.

A ideia é simples: você define o que o agente faz — qual modelo usa, quais ferramentas pode chamar e quais instruções deve seguir. O AgentCore cuida de montar computação, ferramentas, memória, identidade e segurança para criar um agente funcional que pode ser testado em minutos. Trocar de modelo ou adicionar uma ferramenta vira uma mudança de configuração, não uma reescrita de código. É possível testar várias variações do agente em minutos apenas alterando parâmetros na chamada de API.

Essa velocidade não sacrifica flexibilidade. O harness do AgentCore é alimentado pelo Strands Agents, o framework open source da AWS. Quando você precisar de lógica de orquestração personalizada, roteamento especializado ou coordenação entre múltiplos agentes, basta migrar da configuração para um harness definido em código — na mesma plataforma, com o mesmo isolamento por microVM e o mesmo pipeline de deploy.

Outro ponto relevante: o AgentCore persiste o estado da sessão em um sistema de arquivos durável. Isso significa que agentes podem suspender uma tarefa no meio e retomá-la exatamente de onde pararam — tornando padrões de human-in-the-loop (humano no ciclo de decisão) viáveis sem nenhuma customização extra.

A VTEX, empresa brasileira de tecnologia para e-commerce, já está entre os casos de uso mencionados pela AWS. Rodrigo Moreira, VP de Engenharia da VTEX, destacou que antes cada novo protótipo de agente exigia dias de código de orquestração e configuração de infraestrutura antes de validar uma ideia. Com o harness do AgentCore, trocar de modelo, adicionar uma ferramenta ou refinar instruções passa a ser uma mudança de configuração — e a validação de ideias cai de dias para minutos.

AgentCore CLI: um único terminal do protótipo ao produção

Outro obstáculo clássico no ciclo de vida de agentes é a transição do desenvolvimento local para a produção. Normalmente isso significa sair do editor, configurar um pipeline de deploy separado e lidar com um processo que tem pouco a ver com o fluxo usado para construir o agente.

O novo AgentCore CLI unifica esse ciclo em um único terminal: prototipar, fazer deploy e operar o agente sem trocar de ferramenta. Você itera localmente e, quando o agente estiver pronto, faz o deploy sem montar um pipeline separado.

O AgentCore suporta deploy via Infraestrutura como Código (IaC) com suporte ao CDK e ao Terraform (em breve). Isso garante que a configuração do agente seja reproduzível e versionada — o que você testou localmente é exatamente o que roda em produção.

Skills para agentes de código: contexto que faz diferença

Boa parte do desenvolvimento de agentes hoje acontece com o apoio de assistentes de código como Claude Code ou Kiro. Mas um assistente de código só é tão eficaz quanto o contexto que ele tem. Um servidor MCP (Protocolo de Contexto de Modelo) genérico pode dar acesso a APIs e documentação, mas não captura as boas práticas específicas de uma plataforma: quais padrões usar, como as capacidades se encaixam, qual é o caminho recomendado para tarefas comuns.

As novas skills pré-construídas do AgentCore vão além do acesso bruto à API. Elas fornecem aos agentes de código conhecimento atualizado e curado sobre as melhores práticas do AgentCore — de forma que as sugestões recebidas reflitam como a plataforma deve ser usada, não apenas quais endpoints existem. O Kiro já inclui isso como um Power nativo. Plugins para Claude Code, Codex e Cursor chegam em breve.

Disponibilidade e preços

O harness gerenciado do AgentCore está disponível em prévia em quatro regiões AWS: US West (Oregon), US East (N. Virginia), Asia Pacific (Sydney) e Europe (Frankfurt). O AgentCore CLI e o sistema de arquivos persistente para agentes estão disponíveis em todas as regiões comerciais da AWS onde o AgentCore é oferecido. As skills para agentes de código devem estar disponíveis até o final de abril.

O modelo de cobrança é baseado nos recursos consumidos, sem custo adicional pelo CLI, pelo harness ou pelas skills. Mais detalhes estão na página de preços do AgentCore. Para começar, a documentação do AgentCore cobre os primeiros passos.

O que muda na prática

A proposta do AgentCore é clara: a plataforma em que você prototipa é a mesma em que você roda em produção. À medida que o agente evolui, você adiciona avaliações, memória, conexões com ferramentas e políticas de controle — sem precisar rearquitetar nada. O foco se mantém na lógica do agente, não na infraestrutura que o sustenta.

Fonte

Get to your first working agent in minutes: Announcing new features in Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/get-to-your-first-working-agent-in-minutes-announcing-new-features-in-amazon-bedrock-agentcore/)

O problema de custo em transcrição de áudio em escala

Muitas organizações lidam com volumes crescentes de áudio: bibliotecas de mídia para arquivamento, gravações de contact center, dados de treinamento para Inteligência Artificial (IA) ou vídeos sob demanda que precisam de legendas. Quando esses volumes crescem, os custos de serviços gerenciados de Reconhecimento Automático de Fala (ASR, do inglês Automatic Speech Recognition) passam a ser o principal limitador de escala.

Para endereçar esse desafio, a AWS publicou um guia mostrando como combinar o modelo NVIDIA Parakeet-TDT-0.6B-v3 com o AWS Batch em instâncias aceleradas por GPU. O resultado é um pipeline capaz de transcrever áudio em escala por frações de centavo por hora de áudio processado.

O modelo Parakeet-TDT-0.6B-v3

Lançado em agosto de 2025, o Parakeet-TDT-0.6B-v3 é um modelo open-source multilíngue de ASR desenvolvido pela NVIDIA. Ele usa uma arquitetura chamada Token-and-Duration Transducer (TDT), que prevê simultaneamente os tokens de texto e suas durações — o que permite ao modelo pular silêncios e processamentos redundantes de forma inteligente, atingindo velocidades de inferência muito superiores ao tempo real.

De acordo com as métricas publicadas pela NVIDIA, o modelo mantém uma Taxa de Erro por Palavra (WER, do inglês Word Error Rate) de 6,34% em condições limpas e 11,66% de WER a 0 dB de Relação Sinal-Ruído (SNR, do inglês Signal-to-Noise Ratio). Ele também suporta áudios de até três horas no modo de atenção local.

Os 25 idiomas europeus suportados incluem: búlgaro, croata, tcheco, dinamarquês, holandês, inglês, estoniano, finlandês, francês, alemão, grego, húngaro, italiano, letão, lituano, maltês, polonês, português, romeno, eslovaco, esloveno, espanhol, sueco, russo e ucraniano. Isso elimina a necessidade de modelos separados ou configurações específicas por idioma ao atender economias europeias internacionais.

Para implantação na AWS, o modelo requer instâncias com GPU e no mínimo 4 GB de VRAM, embora 8 GB ofereçam melhor desempenho. As instâncias G6 (GPUs NVIDIA L4) apresentam a melhor relação custo-desempenho para cargas de inferência. O modelo também funciona bem em G5 (A10G), G4dn (T4) e, para máximo throughput, P5 (H100) ou P4 (A100).

Arquitetura da solução

O fluxo começa quando um arquivo de áudio é enviado para um bucket do Amazon Simple Storage Service (Amazon S3). Esse upload dispara uma regra do Amazon EventBridge, que submete um job ao AWS Batch. O Batch provisiona os recursos de computação com GPU, e as instâncias provisionadas puxam a imagem de container — com o modelo já em cache — do Amazon Elastic Container Registry (Amazon ECR). O script de inferência baixa e processa o arquivo de áudio, e depois envia o transcript em JSON com timestamps para um bucket S3 de saída.

A arquitetura escala a zero quando ociosa, ou seja, custos são gerados apenas durante a computação ativa. Para uma análise aprofundada dos componentes arquiteturais gerais, a AWS referencia o post anterior sobre transcrição de áudio com Whisper usando AWS Batch e AWS Inferentia.

Pré-requisitos

• Crie uma conta AWS se ainda não tiver uma e faça login.
• Crie um usuário com permissões de administrador completo usando o AWS IAM Identity Center, conforme descrito em Adicionar usuários.
• Instale a Interface de Linha de Comando da AWS (AWS CLI) em sua máquina local e crie um perfil para o usuário administrador, conforme descrito em Configurar a AWS CLI.
• Instale o Docker em sua máquina local.
• Clone o repositório no GitHub para sua máquina local.

Construindo a imagem de container

O repositório inclui um Dockerfile que constrói uma imagem de container otimizada para performance de inferência. A imagem usa o Amazon Linux 2023 como base, instala o Python 3.12 e faz o cache do modelo Parakeet-TDT-0.6B-v3 durante o build — eliminando a latência de download em tempo de execução:

FROM public.ecr.aws/amazonlinux/amazonlinux:2023
WORKDIR /app

# Install system dependencies, Python 3.12, and ffmpeg
RUN dnf update -y && \
    dnf install -y gcc-c++ python3.12-devel tar xz && \
    ln -sf /usr/bin/python3.12 /usr/local/bin/python3 && \
    python3 -m ensurepip && \
    python3 -m pip install --no-cache-dir --upgrade pip && \
    dnf clean all && rm -rf /var/cache/dnf

# Install Python dependencies and pre-cache the model
COPY ./requirements.txt requirements.txt
RUN pip install -U --no-cache-dir -r requirements.txt && \
    rm -rf ~/.cache/pip /tmp/pip* && \
    python3 -m compileall -q /usr/local/lib/python3.12/site-packages

COPY ./parakeet_transcribe.py parakeet_transcribe.py

# Cache model during build to eliminate runtime download
RUN python3 -c "from nemo.collections.asr.models import ASRModel; \
    ASRModel.from_pretrained('nvidia/parakeet-tdt-0.6b-v3')"

CMD ["python3", "parakeet_transcribe.py"]

Enviando a imagem para o Amazon ECR

O repositório inclui um script updateImage.sh que detecta o ambiente (CodeBuild ou EC2), constrói a imagem, cria um repositório ECR se necessário, habilita o escaneamento de vulnerabilidades e faz o push da imagem. Para executá-lo:

./updateImage.sh

Implantando a solução

A solução usa um template do AWS CloudFormation (deployment.yaml) para provisionar a infraestrutura. O script buildArch.sh automatiza a implantação detectando a Região AWS, coletando informações de VPC, sub-redes e grupos de segurança, e implantando a stack do CloudFormation:

./buildArch.sh

Internamente, esse script executa:

aws cloudformation deploy --stack-name batch-gpu-audio-transcription \
  --template-file ./deployment.yaml \
  --capabilities CAPABILITY_IAM \
  --region ${AWS_REGION} \
  --parameter-overrides VPCId=${VPC_ID} SubnetIds="${SUBNET_IDS}" \
  SGIds="${SecurityGroup_IDS}" RTIds="${RouteTable_IDS}"

O template do CloudFormation cria: o ambiente de computação do AWS Batch com instâncias GPU G6 e G5; uma fila de jobs; uma definição de job referenciando a imagem ECR; buckets S3 de entrada e saída com notificações do EventBridge habilitadas; uma regra do EventBridge que dispara um job do Batch no upload ao S3; configuração do agente do Amazon CloudWatch para monitoramento de GPU, CPU e memória; e Funções de Gerenciamento de Identidade e Acesso (IAM, do inglês Identity and Access Management) com políticas de privilégio mínimo.

O AWS Batch permite selecionar imagens Amazon Linux 2023 com GPU especificando ImageType: ECS_AL2023_NVIDIA na configuração do ambiente de computação.

Usando instâncias Spot para reduzir ainda mais os custos

As instâncias Amazon EC2 Spot permitem executar cargas de trabalho na capacidade ociosa da EC2 com descontos de até 90%, dependendo do tipo de instância. Para habilitá-las, basta modificar o ambiente de computação no deployment.yaml:

DefaultComputeEnv:
  Type: AWS::Batch::ComputeEnvironment
  Properties:
    Type: MANAGED
    State: ENABLED
    ComputeResources:
      AllocationStrategy: SPOT_PRICE_CAPACITY_OPTIMIZED
      Type: SPOT
      BidPercentage: 100
      InstanceTypes:
        - "g6.xlarge"
        - "g6.2xlarge"
        - "g5.xlarge"
      MinvCpus: !Ref DefaultCEMinvCpus
      MaxvCpus: !Ref DefaultCEMaxvCpus
      # ... remaining configuration unchanged

Isso pode ser ativado passando --parameter-overrides UseSpotInstances=Yes ao executar o aws cloudformation deploy. A estratégia SPOT_PRICE_CAPACITY_OPTIMIZED seleciona pools de instâncias Spot com menor probabilidade de interrupção e menor preço. Diversificar os tipos de instância (G6 xlarge, G6 2xlarge, G5 xlarge) melhora a disponibilidade Spot. Definir MinvCpus: 0 garante que o ambiente escale a zero quando ocioso. Como os jobs de ASR são stateless e idempotentes, eles são ideais para Spot — e se uma instância for reclamada, o AWS Batch automaticamente tenta novamente o job (configurado com até 2 tentativas na definição do job).

Gerenciando memória para áudios longos

O consumo de memória do modelo Parakeet-TDT escala linearmente com a duração do áudio. O encoder Fast Conformer precisa gerar e armazenar representações de features para todo o sinal de áudio — dobrar a duração do áudio dobra aproximadamente o uso de VRAM. Com atenção completa, o modelo consegue processar até 24 minutos com 80 GB de VRAM.

A NVIDIA endereça isso com um modo de atenção local que suporta até 3 horas de áudio em um A100 de 80 GB:

# Enable local attention for long audio
asr_model.change_attention_model("rel_pos_local_attn", [128, 128])
asr_model.change_subsampling_conv_chunking_factor(1)  # auto select
asr_model.transcribe(["input_audio.wav"])

Esse modo pode apresentar uma leve queda de precisão — recomenda-se testar no seu caso de uso específico.

Inferência em streaming com buffer para áudios muito longos

Para áudios que excedem 3 horas, ou para processar áudios longos de forma econômica em hardware padrão como uma instância g6.xlarge, a solução usa inferência em streaming com buffer. Adaptada do exemplo de inferência em streaming do NVIDIA NeMo, essa técnica processa o áudio em chunks sobrepostos em vez de carregar o contexto completo na memória.

A configuração utiliza chunks de 20 segundos com 5 segundos de contexto à esquerda e 3 segundos de contexto à direita para manter a qualidade da transcrição nas fronteiras dos chunks. Reduzir o tamanho do chunk aumenta o tempo de processamento, então é recomendado experimentar para encontrar a configuração ideal:

# Streaming inference loop
while left_sample < audio_batch.shape[1]:
    # add samples to buffer
    chunk_length = min(right_sample, audio_batch.shape[1]) - left_sample
    # [Logic to manage buffer and flags omitted for brevity]
    buffer.add_audio_batch_(...)
    # Encode using full buffer [left-chunk-right]
    encoder_output, encoder_output_len = asr_model(
        input_signal=buffer.samples,
        input_signal_length=buffer.context_size_batch.total(),
    )
    # Decode only chunk frames (constant memory usage)
    chunk_batched_hyps, _, state = decoding_computer(...)
    # Advance sliding window
    left_sample = right_sample
    right_sample = min(right_sample + context_samples.chunk, audio_batch.shape[1])

Processar o áudio em chunks de tamanho fixo desacopla o uso de VRAM da duração total do áudio — uma única instância g6.xlarge consegue processar um arquivo de 10 horas com o mesmo footprint de memória de um arquivo de 10 minutos. Para implantar com streaming habilitado, basta definir o parâmetro EnableStreaming=Yes:

aws cloudformation deploy \
  --stack-name batch-gpu-audio-transcription \
  --template-file ./deployment.yaml \
  --capabilities CAPABILITY_IAM \
  --parameter-overrides EnableStreaming=Yes \
  VPCId=your-vpc-id SubnetIds=your-subnet-ids SGIds=your-sg-ids RTIds=your-rt-ids

Testes, monitoramento e resultados

Para validar a solução em escala, foram processados 1.000 arquivos de áudio idênticos de 50 minutos — gravações de uma conferência de imprensa pré-voo da NASA — distribuídos em 100 instâncias g6.xlarge, cada uma processando 10 arquivos.

A implantação inclui uma configuração do agente do Amazon CloudWatch que coleta métricas de utilização de GPU, consumo de energia, uso de VRAM, utilização de CPU, consumo de memória e uso de disco em intervalos de 10 segundos. Essas métricas aparecem no namespace CWAgent, permitindo a criação de dashboards para monitoramento em tempo real.

Desempenho e análise de custos

O modelo Parakeet-TDT-0.6B-v3 atingiu uma velocidade de inferência bruta de 0,24 segundos por minuto de áudio. Considerando o overhead completo do pipeline (carregamento do modelo, carregamento do áudio, pré e pós-processamento), os resultados do benchmark em uma instância g6.xlarge foram:

• Duração do áudio: 3 horas e 25 minutos (205 minutos)
• Duração total do job: 100 segundos
• Velocidade efetiva de processamento: 0,49 segundos por minuto de áudio

Em termos de custo, com base nos preços da instância g6.xlarge na região us-east-1:

• On-Demand (~$0,805/hora): aproximadamente $0,00011 por minuto de áudio
• Spot Instances (~$0,374/hora): aproximadamente $0,00005 por minuto de áudio

Os preços são estimativas com base nas taxas da us-east-1 no momento da publicação original. Os preços Spot variam por Zona de Disponibilidade e estão sujeitos a mudanças.

Esses números evidenciam a vantagem econômica da abordagem self-hosted para cargas de trabalho de alto volume em comparação com serviços gerenciados de API.

Limpeza dos recursos

Para evitar cobranças futuras, é necessário excluir os recursos criados pela solução: esvaziar todos os buckets S3 (entrada, saída e logs) e deletar a stack do CloudFormation:

aws cloudformation delete-stack --stack-name batch-gpu-audio-transcription

Opcionalmente, remova o repositório ECR e as imagens de container. Para instruções detalhadas, consulte a seção de limpeza do README do repositório.

Conclusão

A combinação do modelo NVIDIA Parakeet-TDT-0.6B-v3 com o AWS Batch e as instâncias EC2 Spot resulta em um pipeline de transcrição de áudio capaz de processar em escala por frações de centavo por hora. Com suporte a 25 idiomas europeus — incluindo português — e detecção automática de idioma, a solução elimina a necessidade de modelos separados por idioma. A técnica de inferência em streaming com buffer estende essa capacidade para áudios de qualquer duração em hardware padrão, e a arquitetura orientada a eventos escala automaticamente do zero para lidar com cargas de trabalho variáveis.

O código de exemplo está disponível no repositório GitHub para quem quiser explorar e implementar a solução.

Fonte

Cost-effective multilingual audio transcription at scale with Parakeet-TDT and AWS Batch (https://aws.amazon.com/blogs/machine-learning/cost-effective-multilingual-audio-transcription-at-scale-with-parakeet-tdt-and-aws-batch/)