Author: Make.com Service User

  • Personalize a navegação de agentes de IA com proxies, perfis e extensões no Amazon Bedrock AgentCore Browser

    Agentes de IA com capacidades avançadas de navegação na web

    Agentes que navegam na web não funcionam bem apenas com navegação básica de páginas. Empresas que usam a AWS para construir soluções com inteligência artificial relatam necessidades específicas: agentes que mantêm contexto de sessão entre interações, tráfego roteado através de infraestrutura de proxy corporativo, e comportamentos customizados em tempo de execução.

    O AgentCore Browser oferece um ambiente de navegação seguro e isolado para agentes interagirem com aplicações web. Até agora, cada sessão começava do zero com configurações padrão e acesso direto à internet, limitando as capacidades de agentes em ambientes corporativos reais.

    A AWS anunciou três novas capacidades que mudam esse cenário: configuração de proxy, perfis de navegador, e extensões de navegador. Juntas, essas funcionalidades oferecem controle fino sobre como agentes de IA interagem com a web.

    Entendendo as três novas capacidades

    Essas capacidades funcionam de forma complementar, oferecendo controle granular sobre como sessões do AgentCore Browser se conectam à internet, que estado retêm e como se comportam:

    • Configuração de proxy: Roteia tráfego do navegador através de servidores proxy próprios, garantindo estabilidade de IP e integração com infraestrutura de rede corporativa.
    • Perfis de navegador: Persistem cookies e armazenamento local entre sessões, permitindo que agentes retomem fluxos de trabalho autenticados sem repetir login.
    • Extensões de navegador: Carregam extensões Chrome em sessões para customizar comportamento do navegador conforme a necessidade — desde bloqueio de anúncios até autenticação auxiliar.

    Perfis de navegador persistentes para agentes operacionais

    Equipes construindo agentes para testes de e-commerce, fluxos de trabalho autenticados e jornadas multipassos precisam de sessões que “lembram” do estado anterior. Sem perfis persistentes, agentes precisam se reautenticar e reconstruir contexto a cada início de sessão, adicionando latência e fragilidade.

    Perfis de navegador resolvem esse problema salvando e restaurando cookies e armazenamento local entre sessões. Um agente que fez login em um portal ontem pode continuar exatamente de onde parou hoje.

    Estabilidade de IP é outro requisito comum. Portais de saúde e financeiros validam sessões baseando-se em endereço IP de origem. Endereços IP rotativos da AWS causam ciclos frequentes de reautenticação que quebram fluxos de trabalho de longa duração. Suporte a proxy permite rotear tráfego através de servidores com IPs de saída estáveis, mantendo continuidade de sessão e satisfazendo requisitos de IP allowlisting.

    Organizações que rotam tráfego através de proxies corporativos precisam estender essa prática para agentes de IA em sessões de navegador. Configuração de proxy habilita acesso a páginas internas e recursos que requerem conectividade baseada em proxy.

    Extensões de navegador permitem customizações como bloqueio de anúncios, auxiliares de autenticação ou outras personalizações em nível de navegador. Quando combinadas com logging de proxy, essas capacidades ajudam a fornecer controle de acesso e evidência de auditoria que podem suportar programas de conformidade como FedRAMP, HITRUST e PCI.

    Configuração de proxy para roteamento de tráfego

    O AgentCore Browser agora suporta rotear tráfego do navegador através de servidores proxy externos próprios. Ao criar uma sessão de navegador com configuração de proxy, o AgentCore configura o navegador para rotear tráfego HTTP e HTTPS através dos servidores proxy especificados.

    Como funciona

    Você chama StartBrowserSession com proxyConfiguration especificando seu servidor proxy. Se usar autenticação, o AgentCore recupera credenciais de proxy do AWS Secrets Manager. A sessão de navegador inicia com sua configuração de proxy aplicada, e tráfego do navegador roteia através de seu servidor proxy baseado em regras de roteamento por domínio.

    Começando com proxies

    Complete os pré-requisitos antes de prosseguir.

    Passo 1: Criar um segredo de credenciais (se seu proxy requer autenticação)

    import boto3
    import json
    
    client = boto3.client('secretsmanager')
    client.create_secret(
        Name='my-proxy-credentials',
        SecretString=json.dumps({
            'username': '',
            'password': ''
        })
    )

    Passo 2: Criar uma sessão de navegador com configuração de proxy

    session_client = boto3.client('bedrock-agentcore', region_name='')
    response = session_client.start_browser_session(
        browserIdentifier="aws.browser.v1",
        name="my-proxy-session",
        proxyConfiguration={
            "proxies": [{
                "externalProxy": {
                    "server": "",
                    "port": 8080,
                    "credentials": {
                        "basicAuth": {
                            "secretArn": "arn:aws:secretsmanager:::secret:"
                        }
                    }
                }
            }]
        }
    )
    print(f"Session ID: {response['sessionId']}")

    O campo credentials é opcional para proxies sem autenticação.

    Roteamento baseado em domínio

    Use domainPatterns para rotear domínios específicos através de proxies designados, e bypass.domainPatterns para domínios que devem conectar diretamente:

    proxyConfiguration={
        "proxies": [
            {
                "externalProxy": {
                    "server": "corp-proxy.example.com",
                    "port": 8080,
                    "domainPatterns": [".company.com", ".internal.corp"]
                }
            },
            {
                "externalProxy": {
                    "server": "general-proxy.example.com",
                    "port": 8080
                }
            }
        ],
        "bypass": {
            "domainPatterns": [".amazonaws.com"]
        }
    }

    Com essa configuração, requisições para *.company.com e *.internal.corp rotiam através do proxy corporativo, requisições para *.amazonaws.com contornam todos os proxies, e todo o resto roteia através do proxy geral.

    Precedência de roteamento

    Quando o AgentCore Browser processa uma requisição de saída, percorre três níveis de regras de roteamento para decidir onde enviar o tráfego. Primeiro verifica a lista de bypass. Se o domínio de destino corresponder a uma entrada em bypass.domainPatterns, a requisição conecta diretamente à internet sem usar proxy algum.

    Se o domínio não corresponder a uma regra de bypass, o AgentCore verifica cada domainPatterns de proxy em ordem e roteia a requisição através do primeiro proxy cuja regra corresponde. Se nenhuma regra de proxy corresponder, a requisição cai no proxy padrão — a entrada de proxy que não possui domainPatterns definida.

    Teste a nova funcionalidade de proxy com este exemplo de código.

    Perfis de navegador para persistência de estado

    Perfis de navegador permitem persistir e reutilizar dados de sessão entre múltiplas sessões de navegador, incluindo cookies e armazenamento local. Um agente que se autentica com um portal web em uma sessão pode restaurar esse estado em uma sessão posterior sem fazer login novamente.

    Isso é útil para fluxos de trabalho autenticados onde re-login adiciona latência, testes de e-commerce onde carrinhos de compras e dados de formulários precisam sobreviver entre sessões, e jornadas de usuário multipassos que abrangem múltiplas invocações de navegador.

    Ciclo de vida do perfil

    O ciclo de vida do perfil possui quatro estágios. Você começa chamando create_browser_profile() para criar um perfil nomeado. No final de uma sessão, você chama save_browser_session_profile() para capturar cookies e armazenamento local atuais naquele perfil. Ao iniciar uma nova sessão, você passa o identificador do perfil no parâmetro profileConfiguration de start_browser_session(), que restaura o estado salvo no novo navegador. Quando não precisar mais do perfil, você chama delete_browser_profile() para limpá-lo.

    O exemplo a seguir mostra um agente que adiciona itens a um carrinho de compras em uma sessão e verifica se persistem em uma sessão subsequente. Complete os pré-requisitos antes de prosseguir.

    import boto3
    
    control_client = boto3.client('bedrock-agentcore-control', region_name='')
    session_client = boto3.client('bedrock-agentcore', region_name='')
    
    # Create a browser profile
    profile = control_client.create_browser_profile(name="ecommerce_profile")
    profile_id = profile['profileId']
    
    # Session 1: Add items to cart
    session1 = session_client.start_browser_session(
        browserIdentifier="aws.browser.v1",
        name="shopping-session-1"
    )
    # ... agent navigates and adds items to cart ...
    
    # Save session state to profile
    session_client.save_browser_session_profile(
        sessionId=session1['sessionId'],
        browserIdentifier="aws.browser.v1",
        profileIdentifier=profile_id
    )
    session_client.stop_browser_session(sessionId=session1['sessionId'], browserIdentifier="aws.browser.v1")
    
    # Session 2: Resume with saved profile
    session2 = session_client.start_browser_session(
        browserIdentifier="aws.browser.v1",
        name="shopping-session-2",
        profileConfiguration={"profileIdentifier": profile_id}
    )
    # Cart items from Session 1 are now available

    Teste a nova funcionalidade de perfil com este exemplo de código.

    Extensões de navegador para customização

    Extensões de navegador permitem carregar extensões Chrome em sessões do AgentCore Browser para customizar como o navegador se comporta. Você empacota extensões como arquivos ZIP, carrega-as no Amazon Simple Storage Service (Amazon S3), e referencia-as ao iniciar uma sessão de navegador.

    Isso oferece acesso a funcionalidades disponíveis através da API de extensão Chrome, de roteamento de proxy e bloqueio de anúncios até auxiliares de autenticação e modificação de conteúdo. Por exemplo, você pode injetar tokens de autenticação para aplicações internas, remover anúncios e rastrear scripts que interferem com navegação de agente, ou modificar conteúdo de página para melhorar como agentes interagem com um site.

    Configurando extensões

    Sua extensão deve seguir o formato padrão de extensão Chromium e aderir às diretrizes de extensão Chromium. Complete os pré-requisitos antes de prosseguir.

    Fazer upload da extensão para Amazon S3:

    import boto3
    
    s3 = boto3.client('s3')
    s3.upload_file(
        'my-extension.zip',
        'amzn-s3-demo-bucket-extensions',
        'extensions/my-extension.zip'
    )

    Iniciar uma sessão com a extensão:

    import boto3
    
    region = ""
    client = boto3.client('bedrock-agentcore', region_name=region)
    response = client.start_browser_session(
        browserIdentifier="aws.browser.v1",
        name="my-session-with-extensions",
        sessionTimeoutSeconds=1800,
        viewPort={
            'height': 1080,
            'width': 1920
        },
        extensions=[
            {
                "location": {
                    "s3": {
                        "bucket": "amzn-s3-demo-bucket-extensions",
                        "prefix": "extensions/my-extension.zip"
                    }
                }
            },
            {
                "location": {
                    "s3": {
                        "bucket": "amzn-s3-demo-bucket-extensions",
                        "prefix": "extensions/another-extension.zip",
                        "versionId": "abc123"
                    }
                }
            }
        ]
    )
    print(f"Session ID: {response['sessionId']}")
    print(f"Status: {response['status']}")
    print(f"Automation Stream: {response['streams']['automationStream']['streamEndpoint']}")

    Teste a nova funcionalidade de extensões com este exemplo de código.

    Reunindo tudo: casos de uso práticos

    Essas três capacidades — configuração de proxy, perfis de navegador e extensões — permitem casos de uso que antes eram impossíveis:

    • Fluxos de trabalho autenticados: Agentes que precisam permanecer autenticados em portais corporativos internos podem usar perfis para manter sessão e proxies para acessar redes restritas.
    • Testes de e-commerce: Agentes podem manter carrinhos de compras, preferências e histórico de busca entre sessões, simulando comportamento real de usuários.
    • Jornadas complexas: Fluxos que envolvem múltiplas etapas, autenticação e verificação podem agora se completar sem começar do zero.
    • Conformidade e auditoria: Proxy logging combinado com extensões oferece visibilidade e controle necessários para programas de conformidade corporativa.

    Próximos passos

    Para começar, consulte os tutoriais no repositório Amazon Bedrock AgentCore samples e a documentação do AgentCore Browser. Para mais informações sobre preços, visite Amazon Bedrock AgentCore Pricing.

    Essas três capacidades — configuração de proxy, perfis de navegador e extensões — oferecem ao AgentCore Browser o roteamento de proxy, persistência de sessão e controles de extensibilidade que empresas precisam para implantar agentes de IA que navegam na web em produção. Você pode rotear tráfego através de infraestrutura de proxy corporativo, manter continuidade de sessão entre interações, e customizar comportamento de navegador com extensões, tudo mantendo credenciais seguras no AWS Secrets Manager.

    Fonte

    Customize AI agent browsing with proxies, profiles, and extensions in Amazon Bedrock AgentCore Browser (https://aws.amazon.com/blogs/machine-learning/customize-ai-agent-browsing-with-proxies-profiles-and-extensions-in-amazon-bedrock-agentcore-browser/)

  • Amazon Connect agora oferece resumos em tempo real com IA e recomenda as próximas ações para Tarefas

    O que mudou no Amazon Connect

    A Amazon Connect acaba de receber uma atualização importante que traz inteligência artificial para acelerar o trabalho dos agentes. O serviço agora fornece resumos de tarefas gerados por IA com sugestões de próximas ações, permitindo que os agentes entendam os trabalhos pendentes mais rapidamente e os resolvam com maior eficiência.

    Como funciona na prática

    Imagine um agente recebendo uma tarefa para processar uma solicitação de reembolso enviada através de um formulário online. Em vez de ter que revisar manualmente todos os passos anteriores, a IA do Amazon Connect faz um resumo automático das atividades realizadas — como verificação de detalhes do pedido, confirmação de elegibilidade para devolução e validação do método de pagamento — e então apresenta os próximos passos recomendados para completar o reembolso.

    Essa abordagem reduz significativamente o tempo que o agente gasta entendendo o contexto da tarefa e o coloca imediatamente em condição de avançar com a resolução.

    Como ativar o recurso

    Para aproveitar essa funcionalidade, é necessário adicionar o bloco de fluxo do assistente Connect aos seus fluxos antes de uma tarefa ser atribuída ao agente. Além disso, é possível orientar as recomendações do assistente de tarefas alimentado por IA através da adição de bases de conhecimento, personalizando as sugestões conforme a realidade do seu negócio.

    Disponibilidade

    Este novo recurso está disponível em todas as regiões da AWS onde o Amazon Connect oferece assistência em tempo real para agentes. Para começar a implementação, consulte a documentação de ajuda, explore a página de preços ou visite o site do Amazon Connect para obter informações completas.

    O impacto para centros de contato

    Essa integração de IA representa um passo significativo na automação de processos dentro de centros de contato. Ao reduzir o tempo de compreensão de cada tarefa, os agentes podem aumentar sua produtividade e oferecer um atendimento mais rápido aos clientes. A sugestão de próximas ações também ajuda a padronizar os processos, garantindo que os fluxos corretos sejam seguidos independentemente da experiência do agente.

    Fonte

    Amazon Connect now provides real time AI-powered overviews and recommended next actions for Tasks (https://aws.amazon.com/about-aws/whats-new/2026/02/connect-tasks-ai-assistance)

  • Suporte em IA da AWS Support Center agora funciona em 7 idiomas adicionais

    Suporte multilíngue chega ao console de troubleshooting da AWS

    A AWS anunciou a expansão do recurso de diagnóstico com inteligência artificial disponível no AWS Support Center Console. Agora o sistema oferece suporte em sete idiomas adicionais além do inglês: japonês, coreano, mandarim simplificado, mandarim tradicional, espanhol, português e francês.

    Uma barreira linguística importante foi removida

    O AWS Support Center Console é a interface principal onde clientes gerenciam sua experiência de suporte na nuvem, criando e rastreando casos de suporte. Anteriormente, as capacidades de diagnóstico assistidas por inteligência artificial estavam disponíveis somente em inglês, o que representava uma barreira significativa para profissionais que preferem trabalhar em seu idioma nativo.

    Com esta atualização, os usuários podem interagir com assistência de troubleshooting alimentada por IA em seu idioma preferido. Isso significa que desenvolvedores, arquitetos e equipes de operações em diferentes países agora têm acesso equivalente às ferramentas de resolução de problemas.

    Como funciona na prática

    O recurso de troubleshooting com IA da AWS Support ajuda clientes a resolver problemas com mais rapidez, fornecendo recomendações contextificadas e imediatas durante o processo de criação de um caso de suporte. Para ilustrar: um desenvolvedor japonês que enfrenta um problema de conectividade com EC2 pode agora receber insights gerados por IA e soluções potenciais totalmente em japonês, reduzindo significativamente o tempo necessário para entender e implementar as correções.

    Acesso democrático ao recurso

    Esta capacidade está integrada de forma contínua à experiência de suporte e está disponível para todos os clientes, independentemente do plano de suporte contratado. Isso garante que a barreira linguística não limite o acesso a ferramentas de autoatendimento.

    Qualquer cliente pode acessar o recurso selecionando um idioma suportado nas configurações do console e clicando no link “Try it now” no banner no topo do AWS Support Center Console.

    Regiões onde o recurso está disponível

    Este recurso está disponível em todas as regiões AWS onde o troubleshooting com IA no AWS Support Center Console é oferecido:

    • US East (N. Virginia)
    • US East (Ohio)
    • Europe (Ireland)

    Próximos passos

    Para aprender mais sobre o AWS Support Center Console e o troubleshooting com IA, consulte a documentação de suporte completa.

    Fonte

    AI Troubleshooting in the AWS Support Center Console now supports 7 additional languages (https://aws.amazon.com/about-aws/whats-new/2026/02/ai-troubleshooting-in-aws-support-center/)

  • Servidores MCP de Longa Duração no Amazon Bedrock AgentCore com Integração Strands Agents

    Agentes de IA Evoluindo Para Operações Complexas

    Os agentes de inteligência artificial estão deixando de ser simples interfaces de conversação para se tornarem ferramentas sofisticadas de processamento de dados. Organizações cada vez mais utilizam esses agentes para treinar modelos, processar grandes volumes de informações e executar simulações estendidas. Esse cenário traz uma questão técnica fundamental: operações que levam minutos ou horas extrapolam completamente os limites de tempo típicos das sessões de usuário.

    O desafio central abordado pela AWS diz respeito à execução de tarefas que persistem além das conexões convencionais. Imagine um cenário onde seu agente de IA inicia um processamento de dados que durará várias horas, o usuário fecha seu navegador, e quando retorna dias depois, o sistema apresenta os resultados completos com visibilidade total sobre o progresso e qualquer erro ocorrido. Isso é possível através de padrões arquiteturais que combinam Amazon Bedrock AgentCore e Strands Agents para gerenciar estado persistente.

    Sem esses padrões, encontram-se erros de timeout, utilização ineficiente de recursos e potencial perda de dados quando conexões se encerram abruptamente. A solução proposta integra três estratégias complementares: comunicação contínua entre servidores e clientes durante operações estendidas, gerenciamento de tarefas assíncronas que permite aos agentes iniciar processos sem bloquear outras operações, e a integração desses componentes em um sistema pronto para produção.

    Duas Estratégias Para Tarefas de Longa Duração

    Ao projetar servidores Model Context Protocol (MCP) para tarefas prolongadas, surge uma decisão arquitetural fundamental: a conexão deve permanecer ativa fornecendo atualizações em tempo real, ou deve haver desacoplamento entre execução e requisição inicial? Essa escolha delineia duas abordagens distintas.

    Mensagens de Contexto: Mantendo Conexões Ativas

    A abordagem de mensagens de contexto preserva comunicação contínua entre servidor MCP e cliente durante toda a execução. O servidor utiliza o objeto de contexto integrado do MCP para enviar notificações periódicas. Essa estratégia funciona melhor para cenários onde tarefas completam dentro de 10 a 15 minutos e a conectividade permanece estável.

    As vantagens dessa abordagem incluem implementação direta, ausência de lógica adicional de verificação repetida, implementação simplificada no cliente e sobrecarga mínima.

    A implementação funciona através de mensagens de “heartbeat” que mantêm a conexão viva durante operações estendidas. Cada notificação de progresso previne que o servidor encerre a conexão por inatividade. Exemplos práticos incluem relatórios de progresso em treinamento de modelos, onde a cada iteração um novo percentual de conclusão é reportado.

    Quando o progresso exato não é facilmente quantificável—como em processamento de datasets imprevisíveis ou chamadas a APIs externas—implementa-se um sistema de heartbeat baseado em tempo: notificações periódicas simplesmente informam que o processamento continua ativo, sem necessidade de métrica específica.

    Gerenciamento de Tarefas Assíncronas: O Modelo “Fire-and-Forget”

    O padrão de gerenciamento assíncronico separa a iniciação da tarefa de sua execução e recuperação de resultados. Após executar a ferramenta MCP, ela retorna imediatamente uma mensagem com identificador de tarefa enquanto o trabalho prossegue em background. Essa abordagem excele em cenários empresariais exigentes onde tarefas podem durar horas, usuários precisam de flexibilidade para desconectar e reconectar, e a confiabilidade do sistema é paramount.

    Os benefícios incluem verdadeira operação “fire-and-forget”, segurança para desconexão do cliente enquanto tarefas continuam, prevenção de perda de dados através de armazenamento persistente, suporte para operações de muitas horas, resiliência contra interrupções de rede e suporte a fluxos de trabalho completamente assíncronos.

    Este padrão espelha como organizações interagem com sistemas de processamento em lote: submete-se um job, desconecta-se, e verifica-se progresso quando conveniente. A implementação cria três ferramentas MCP distintas: uma que inicia a tarefa e retorna um identificador único, outra para verificar status e progresso em qualquer momento, e uma terceira para recuperar resultados quando concluídos.

    Quando Usar Cada Abordagem

    Mensagens de contexto funcionam melhor quando tarefas levam entre um e 15 minutos, conexões de rede são geralmente estáveis e a sessão do cliente permanece ativa durante toda a operação. O limite de 15 minutos baseia-se no tempo máximo para requisições síncronas no Amazon Bedrock AgentCore.

    Contudo, essa abordagem possui limitações críticas: a sessão do cliente deve permanecer ativa—se o navegador fecha ou a rede cai, o trabalho é perdido. Manter conexões abertas consome recursos significativos no servidor e cliente, potencialmente aumentando custos. Instabilidade de rede ainda pode interromper o processo, exigindo reinício completo. A maioria das infraestruturas possui limites de timeout absolutos que mensagens de heartbeat não conseguem contornar.

    Para operações verdadeiramente prolongadas que possam durar horas, ou quando usuários precisam desconectar e reconectar posteriormente, o gerenciamento assíncronico torna-se necessário. Porém, essa abordagem introduz suas próprias limitações: requer que usuários verifiquem manualmente status de tarefa, lembrem identificadores entre sessões e solicitem resultados explicitamente, aumentando complexidade de interação. Armazenamento em memória volátil—como em exemplo básico—significa que tarefas e resultados desaparecem se o servidor reinicia, tornando inadequado para produção sem persistência externa. Em ambientes serverless efêmeros, instâncias terminam automaticamente após inatividade, causando perda permanente do estado de tarefa em memória.

    Solução Robusta: Persistência Externa

    Para resolver essas limitações críticas, é necessário incluir persistência externa que sobreviva tanto a reinicializações de servidor quanto a terminações de instância. A solução avançada utiliza Amazon Bedrock AgentCore Memory como armazenamento persistente de estado de agente.

    Quando um servidor MCP executa tarefa de longa duração, escreve resultados intermediários ou finais diretamente no armazenamento de memória externa que o agente pode acessar. Isso cria resiliência contra dois tipos de falhas: a instância executando o servidor MCP pode ser encerrada por inatividade após conclusão da tarefa, e a instância hospedando o próprio agente pode ser reciclada em ambientes serverless. Quando usuários retornam para interagir com o agente—seja minutos, horas ou dias depois—o agente recupera resultados completados do armazenamento persistente.

    Essa abordagem minimiza dependências de runtime: mesmo que ambas as instâncias, servidor MCP e agente, sejam terminadas, os resultados da tarefa permanecem preservados e acessíveis quando necessário.

    Implementação Com Amazon Bedrock AgentCore e Strands Agents

    Escolhendo Entre Gateway e Runtime

    Antes de implementar, é importante compreender as opções de deployment disponíveis para servidores MCP no Amazon Bedrock AgentCore. Existem duas abordagens primárias: Amazon Bedrock AgentCore Gateway e AgentCore Runtime.

    AgentCore Gateway possui timeout de cinco minutos para invocações, tornando-o inadequado para hospedar servidores MCP que ofereçam ferramentas exigindo tempos de resposta estendidos ou operações longas. Amazon Bedrock AgentCore Runtime, por outro lado, oferece significativamente mais flexibilidade: timeout de 15 minutos para requisições síncronas e duração máxima de sessão ajustável para processos assíncronos—a duração padrão é oito horas.

    Embora fosse possível hospedar um servidor MCP em ambiente tradicional com servidores físicos para tempo de execução ilimitado, AgentCore Runtime proporciona equilíbrio ótimo para a maioria dos cenários de produção. Obtém-se benefícios serverless como scaling automático, preço por uso e sem gerenciamento de infraestrutura, enquanto os máximos ajustáveis cobrem praticamente todas as operações reais longas—desde processamento de dados e treinamento de modelos até geração de relatórios e simulações complexas. Essa abordagem permite construir agentes sofisticados sem overhead operacional de gerenciar servidores, reservando deployments com infraestrutura física apenas para casos raros que genuinamente exigem execuções de múltiplos dias.

    Servidor MCP Com Persistência de Memória

    A implementação do servidor MCP utiliza AgentCore Memory para atingir persistência de resultados. O cliente de memória estabelece comunicação com o armazenamento persistente. Quando uma tarefa em background completa, o método agentcore_memory_client.create_event() salva os resultados diretamente na memória do agente utilizando os identificadores apropriados de memória, ator e sessão.

    Diferentemente de abordagens tradicionais onde resultados podem ser armazenados temporariamente ou exigir recuperação manual, essa integração torna os resultados de tarefas uma parte permanente da memória conversacional do agente. O agente pode então referenciar esses resultados em interações futuras, criando experiência contínua de construção de conhecimento através de múltiplas sessões.

    Um componente crucial envolve extrair contexto de sessão através dos headers HTTP da requisição MCP. O header “Mcp-Session-Id” faz parte do protocolo MCP padrão. Esse header passa um identificador composto contendo três informações essenciais em formato delimitado: session_id@@@memory_id@@@actor_id. Headers são usados em vez de variáveis de ambiente por necessidade: esses identificadores mudam dinamicamente a cada conversa, enquanto variáveis de ambiente permanecem estáticas desde startup do container. Essa escolha é particularmente importante em cenários multi-tenant onde um único servidor MCP simultaneamente gerencia requisições de múltiplos usuários, cada um com seu próprio contexto de sessão distinto.

    Ao salvar eventos no AgentCore Memory, cada mensagem requer dois componentes: o conteúdo e um identificador de papel (role). Esses componentes precisam ser formatados de maneira que o framework de agente reconheça. Para o framework Strands Agents, isso significa serializar o conteúdo como JSON interno contendo detalhes da mensagem incluindo papel, conteúdo textual e identificador de mensagem, com um identificador de papel externo (USER neste exemplo) ajudando a categorizar a origem da mensagem no AgentCore Memory.

    Integração Com Strands Agents

    Integrar Amazon Bedrock AgentCore Memory com Strands Agents é notavelmente simples utilizando a classe AgentCoreMemorySessionManager do Bedrock AgentCore SDK. A implementação requer configuração mínima: criar um objeto AgentCoreMemoryConfig com os identificadores de sessão, inicializar o gerenciador de sessão com essa configuração, e passá-lo diretamente ao construtor do agente. O gerenciador de sessão transparentemente gerencia operações de memória nos bastidores, mantendo histórico de conversa e contexto através de interações enquanto organiza memórias utilizando a combinação de session_id, memory_id e actor_id.

    O gerenciamento de contexto de sessão é particularmente elegante nessa abordagem. O agente recebe identificadores de sessão através dos parâmetros de payload e contexto fornecidos pelo AgentCore Runtime. Esses identificadores formam uma ponte contextual crucial conectando interações do usuário através de múltiplas sessões. O session_id pode ser extraído do objeto contexto—gerando um novo se necessário—enquanto memory_id e actor_id são recuperados do payload. Esses identificadores são então empacotados em um header HTTP customizado que é passado ao servidor MCP durante o estabelecimento de conexão.

    Para manter essa experiência persistente através de múltiplas interações, clientes devem consistentemente fornecer os mesmos identificadores ao invocar o agente. Fornecendo consistentemente o mesmo memory_id, actor_id e runtimeSessionId através de invocações, usuários criam experiência conversacional contínua onde resultados de tarefas persistem independentemente de limites de sessão. Quando um usuário retorna dias depois, o agente pode automaticamente recuperar tanto histórico de conversa quanto resultados de tarefa que foram completados durante sua ausência.

    Uma Nova Geração de Agentes Autônomos

    Essa arquitetura representa avanço significativo nas capacidades de agentes de IA, transformando operações de longa duração de processos frágeis e dependentes de conexão em tarefas robustas e persistentes que continuam funcionando independentemente de estado de conexão. O resultado é um sistema que pode entregar assistência genuinamente assíncrona através de IA, onde trabalho complexo continua progredindo em background e resultados são integrados perfeitamente sempre que o usuário retorna à conversa.

    Tanto mensagens de contexto quanto gerenciamento assíncronico oferecem caminhos viáveis: mensagens de contexto para tarefas moderadas mantendo conexões ativas, gerenciamento assíncronico para necessidades que crescem. As soluções descritas podem ser rapidamente adaptadas para necessidades específicas, ajudando a construir IA que entrega resultados confiávelmente—mesmo quando usuários desconectam e retornam dias depois.

    Para conhecer mais detalhes, consulte a documentação do Amazon Bedrock AgentCore e explore o notebook de exemplo fornecido. Mais informações sobre quotas de serviço estão disponíveis na documentação de quotas do Amazon Bedrock AgentCore, e a documentação do AgentCore Memory Session Manager oferece detalhes sobre integração com Strands Agents.

    Fonte

    Build long-running MCP servers on Amazon Bedrock AgentCore with Strands Agents integration (https://aws.amazon.com/blogs/machine-learning/build-long-running-mcp-servers-on-amazon-bedrock-agentcore-with-strands-agents-integration/)

  • Amazon RDS for PostgreSQL: Suporte para Novas Versões Menores 18.2, 17.8, 16.12, 15.16 e 14.21

    Novas Versões Menores Disponíveis no Amazon RDS for PostgreSQL

    A Amazon Web Services anunciou o suporte a novas versões menores do PostgreSQL no serviço Amazon Relational Database Service (RDS) for PostgreSQL. Agora estão disponíveis as versões 18.2, 17.8, 16.12, 15.16 e 14.21, ampliando as opções de atualização para os usuários que mantêm bancos de dados em diferentes ciclos de suporte.

    Por Que Atualizar Para as Novas Versões Menores

    As atualizações de versões menores são importantes por dois motivos principais. Primeiro, elas resolvem vulnerabilidades de segurança conhecidas presentes em versões anteriores do PostgreSQL. A comunidade de desenvolvimento do PostgreSQL trabalha continuamente para identificar e corrigir essas falhas, tornando as novas versões menores mais seguras para ambientes de produção.

    Em segundo lugar, cada nova versão menor incorpora correções de bugs acumuladas pela comunidade PostgreSQL, melhorando a estabilidade e a confiabilidade do banco de dados. Essas correções adresam problemas encontrados em uso real e contribuem para uma experiência mais robusta.

    Nova Extensão pg_stat_monitor

    Esta versão também introduce a extensão pg_stat_monitor, que traz capacidades avançadas para monitoramento de performance. A ferramenta permite coletar métricas de desempenho e avaliar insights sobre o comportamento de consultas em uma visualização única e integrada, facilitando a identificação de gargalos e oportunidades de otimização.

    Estratégias de Atualização: Automática e Orquestrada

    Para simplificar o gerenciamento de bancos de dados em larga escala, a AWS oferece várias abordagens de atualização:

    • Atualizações Automáticas: Você pode configurar atualizações automáticas de versão menor durante janelas de manutenção programadas, minimizando a necessidade de intervenção manual.
    • Política de Rollout Orquestrado: Para organizações com muitas instâncias, a política de rollout do AWS Organizations permite orquestrar milhares de atualizações em fases. A estratégia típica começa pelos ambientes de desenvolvimento antes de passar aos sistemas de produção, reduzindo riscos.
    • Implantações Blue/Green: Para minimizar o tempo de inatividade, você pode utilizar implantações Blue/Green do Amazon RDS com replicação física, que criam uma cópia sincronizada do banco de dados e permitem failover com downtime próximo a zero durante a atualização.

    Como Começar

    A atualização de seus bancos de dados pode ser feita através do AWS Command Line Interface (CLI) ou do console de gerenciamento do Amazon RDS. Para informações sobre preços e disponibilidade regional das novas versões, consulte a página de precificação do Amazon RDS for PostgreSQL.

    Fonte

    Amazon RDS for PostgreSQL supports minor versions 18.2, 17.8, 16.12, 15.16 and 14.21 (https://aws.amazon.com/about-aws/whats-new/2026/02/rds-minor-version-18-2-17-8-16-12-15-16-14-21)

  • IA Encontra RH: Transformando Recrutamento e Seleção com Amazon Bedrock

    A IA na Transformação dos Processos de Recrutamento

    Organizações enfrentam desafios significativos ao tentar tornar seus processos de recrutamento mais eficientes sem comprometer práticas justas de contratação. Inteligência artificial oferece um caminho promissor para superar essas dificuldades, otimizando procedimentos de seleção e aumentando a qualidade das decisões. A AWS disponibiliza um conjunto de serviços de IA que potencializam a eficiência, efetividade e equidade nas práticas de recrutamento.

    Com o Amazon Bedrock, é possível construir um sistema de recrutamento escalável e robusto que simplifica fluxos de trabalho, permitindo que revisores humanos concentrem esforços na entrevista e avaliação real de candidatos. Este artigo detalha como criar um sistema de recrutamento alimentado por IA utilizando Amazon Bedrock, Amazon Bedrock Knowledge Bases, AWS Lambda e outros serviços AWS para aprimorar criação de descrições de vagas, comunicação com candidatos e preparação de entrevistas, sem abrir mão da supervisão humana.

    Arquitetura de um Sistema de Recrutamento Alimentado por IA

    O processo de recrutamento oferece múltiplas oportunidades para aprimoramento via IA através de agentes especializados, cada um potencializado pelo Amazon Bedrock e conectado a bases de conhecimento dedicadas. Esses agentes trabalham em conjunto ao longo de diferentes etapas do ciclo de recrutamento.

    Agente de Criação e Otimização de Descrição de Vagas

    Criar descrições de vagas inclusivas e atrativas é essencial para atrair talentos diversos. Este agente utiliza modelos de linguagem avançados disponíveis no Amazon Bedrock, conectando-se a uma base de conhecimento contendo descrições históricas da organização e diretrizes de inclusão. Ele é implantado com configuração segura de Amazon Virtual Private Cloud (Amazon VPC) e papéis de AWS Identity and Access Management (IAM). O agente referencia a base de conhecimento para otimizar anúncios de vagas mantendo conformidade com padrões organizacionais e requisitos de linguagem inclusiva.

    Agente de Gestão de Comunicação com Candidatos

    Este agente gerencia interações com candidatos através de funções Lambda que acionam comunicações baseadas em etapas do fluxo de trabalho, Amazon Simple Notification Service (Amazon SNS) para entrega segura de emails e mensagens, e integração com fluxos de aprovação para comunicações reguladas. Atualizações de status são automatizadas conforme a progressão do candidato. A configuração inclui endpoints VPC apropriados e criptografia para todos os dados em trânsito e em repouso. Amazon CloudWatch monitora a efetividade das comunicações e taxas de resposta.

    Agente de Preparação para Entrevistas

    Este agente oferece suporte ao processo de entrevista acessando uma base de conhecimento com questões, procedimentos operacionais padrão e melhores práticas. Gera materiais contextualizados para entrevistas baseados em requisitos específicos da função e analisa feedback de entrevistadores utilizando Amazon Bedrock para identificar sentimentos-chave e temas consistentes. Embora forneça estrutura e orientação, os entrevistadores mantêm controle completo sobre a conversação e processo de avaliação.

    Infraestrutura Técnica e Segurança

    A implementação demanda acesso a uma conta AWS com permissões administrativas, acesso aos modelos de fundação (FMs) do Amazon Bedrock, e capacidade de criar e gerenciar papéis IAM. Os serviços AWS necessários incluem Amazon API Gateway, AWS Key Management Service (AWS KMS), Amazon Simple Storage Service (Amazon S3) para armazenamento das bases de conhecimento, além de VPC, CloudWatch e SNS.

    O template de AWS CloudFormation define a infraestrutura completa, incluindo configuração de VPC, grupos de segurança, funções Lambda, API Gateway e bases de conhecimento, facilitando implantação segura e escalável com papéis IAM adequados e criptografia. A solução implementa uma abordagem abrangente de segurança: dados são protegidos através de criptografia KMS, papéis IAM seguem princípios de menor privilégio, e visibilidade completa é mantida via CloudWatch e logs de auditoria. Para informações sensíveis, tokenização de dados e políticas rigorosas de retenção protegem informações identificáveis pessoais (PII).

    Componentes Principais da Solução

    A arquitetura integra os três agentes de recrutamento e serviços AWS em um sistema coerente. O Agente de Criação de Descrição conecta-se diretamente a uma base de conhecimento contendo exemplos de descrições e práticas recomendadas para linguagem inclusiva. O Agente de Comunicação utiliza funções Lambda para gerenciar fluxos de trabalho e SNS para entrega confiável de mensagens. O Agente de Preparação para Entrevistas fornece orientação sobre formatos de perguntas enquanto ajuda a estruturar, resumir e analisar feedback, mantendo acesso a uma base de conhecimento detalhada de padrões de entrevista.

    Implementação de Bases de Conhecimento

    O gerenciador central de base de conhecimento interage com coleções de bases do Amazon Bedrock para fornecer melhores práticas, modelos e padrões aos agentes de recrutamento. Para melhorar a qualidade da Geração Aumentada por Recuperação (RAG), recomenda-se ajustar o tamanho dos segmentos de documentos e sua sobreposição, experimentar diferentes modelos de embedding e ativar reranking para promover passagens mais relevantes. Cada agente pode utilizar diferentes modelos de fundação — por exemplo, um modelo rápido como Anthropic Claude 3 Haiku para tarefas em alto volume, e um modelo mais robusto como Claude 3 Sonnet para análise mais profunda no Agente de Preparação para Entrevistas.

    Otimização de Custos e Desempenho

    Para otimizar eficiência e gerenciar custos, a solução implementa escalamento automático para funções Lambda adaptando-se a variações de carga de trabalho. Para cargas previsíveis, AWS Savings Plans reduzem custos sem sacrificar desempenho. É possível estimar custos da solução utilizando a AWS Pricing Calculator, que ajuda no planejamento de serviços como Amazon Bedrock, Lambda e Amazon Bedrock Knowledge Bases.

    Dashboards abrangentes do CloudWatch fornecem visibilidade em tempo real do desempenho do sistema, facilitando identificação e resolução rápida de problemas. Tags de alocação de custos rastreiam despesas por departamentos ou projetos, permitindo orçamento e alocação de recursos mais precisos. Alertas de orçamento notificam a equipe quando gastos se aproximam de limites predefinidos, evitando surpresas de faturamento. Revisões periódicas de planejamento de capacidade garantem que a infraestrutura acompanhe o crescimento organizacional e mudanças nas necessidades de recrutamento.

    Supervisão Humana e Governança

    O sistema de recrutamento alimentado por IA deve priorizar supervisão humana e governança para promover práticas éticas e justas. Pontos obrigatórios de revisão ao longo do processo permitem que recrutadores avaliem recomendações de IA e tomem decisões finais. Caminhos claros de escalação facilitam intervenção humana em casos excepcionais. Ações sensíveis, como seleção final de candidatos ou aprovação de ofertas, devem estar sujeitas a fluxos de aprovação em múltiplos níveis.

    Monitoramento contínuo de qualidade e precisão de decisões — comparando recomendações de IA com decisões humanas — identifica áreas para aprimoramento. A equipe deve receber treinamento regular sobre capacidades e limitações do sistema. Procedimentos de sobreposição bem documentados permitem que recrutadores ajustem ou cancelem decisões de IA quando necessário. Treinamento regular de conformidade reforça o compromisso com uso ético de IA no recrutamento.

    Framework de Melhoria Contínua

    O compromisso com excelência deve refletir-se em um framework de melhoria contínua. Revisões regulares de métricas e coleta de feedback de stakeholders identificam áreas de aprimoramento. Testes A/B de novas funcionalidades ou mudanças de processos permitem decisões orientadas por dados. Documentação abrangente captura lições aprendidas de cada iteração ou desafio, informando atualizações contínuas de dados de treinamento.

    Análise detalhada de tendências de desempenho ao longo do tempo permite resolução proativa de potenciais problemas e capitalização em estratégias bem-sucedidas. Satisfação de stakeholders — recrutadores, gestores de contratação e candidatos — deve ser uma métrica essencial no framework de melhoria, verificando se o sistema IA-alimentado atende as necessidades de todos os envolvidos no processo de recrutamento.

    Orquestração de Agentes e Evolução da Solução

    Conforme implementações de IA amadurecem e organizações desenvolvem múltiplos agentes especializados, a necessidade de orquestração sofisticada torna-se crítica. Amazon Bedrock AgentCore fornece a fundação para gerenciar essa evolução, facilitando coordenação perfeitamente integrada e comunicação entre agentes mantendo controle centralizado. Esta camada de orquestração otimiza alocação de recursos e roteia tarefas com base em capacidades dos agentes, futuro-provando a infraestrutura de IA.

    Conclusão

    Os serviços de IA da AWS oferecem capacidades específicas para transformar processos de recrutamento e aquisição de talento. Mantendo foco robusto em supervisão humana, organizações podem criar práticas de contratação mais eficientes, justas e efetivas. O objetivo da IA em recrutamento não é substituir tomada de decisão humana, mas aumentá-la e apoiá-la, ajudando profissionais de RH a concentrarem-se nos aspectos mais valiosos de seus papéis: construir relacionamentos, avaliar alinhamento cultural e tomar decisões matizadas que impactam carreiras e sucesso organizacional.

    Para mais informações sobre soluções alimentadas por IA na AWS, consulte postagens do blog Amazon Bedrock e recursos sobre IA Responsável.

    Fonte

    AI meets HR: Transforming talent acquisition with Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/ai-meets-hr-transforming-talent-acquisition-with-amazon-bedrock/)

  • AWS Payment Cryptography recebe aprovação do Groupement des Cartes Bancaires

    Uma Aprovação Importante para Pagamentos em Nuvem

    A AWS Payment Cryptography alcançou um marco significativo ao receber aprovação do Groupement des Cartes Bancaires (CB), a rede nacional de cartões bancários da França. Essa aprovação posiciona o serviço como um dos primeiros serviços de criptografia de pagamentos baseados em nuvem a obter essa certificação, uma conquista relevante para o ecossistema de pagamentos digital europeu.

    A aprovação do CB complementa as credenciais de conformidade já existentes no serviço, abrindo caminho para que organizações executem cargas de trabalho de pagamento na AWS enquanto mantêm a conformidade com os requisitos da rede francesa.

    Qui Pode Aproveitar essa Aprovação

    Essa certificação é especialmente relevante para organizações que atuam no setor de pagamentos e estão considerando a migração para ambientes em nuvem. Entre os beneficiários diretos estão:

    • Adquirentes de pagamentos
    • Facilitadores de pagamentos
    • Redes de pagamento
    • Switches e processadores de pagamento
    • Bancos emissores de cartões

    Para essas organizações, a aprovação do CB funciona como um componente confiável de seus frameworks de conformidade durante a migração para a nuvem.

    Funcionalidades Equivalentes a Infraestrutura Tradicional

    Historicamente, organizações que processam pagamentos por cartão dependem de Módulos de Segurança de Hardware (Hardware Security Modules — HSM) para realizar operações criptográficas em conformidade. O AWS Payment Cryptography oferece funcionalidades equivalentes, mas como um serviço elástico e escalável, eliminando o ônus operacional de adquirir, manter e gerenciar módulos HSM standalone.

    Esse modelo reduz complexidade, custos com infraestrutura e o trabalho administrativo associado ao gerenciamento de hardware especializado, enquanto mantém os mesmos níveis de segurança e conformidade.

    Conformidade Multinível

    O serviço se beneficia de um modelo robusto de responsabilidade compartilhada que já cobre múltiplas certificações essenciais:

    • Padrão de Segurança de Dados PCI (PCI PIN, PCI P2PE, PCI 3DS, PCI DSS)
    • SOC-2
    • CSA STAR
    • ISO/IEC 27001

    A aprovação do CB agora se adiciona a esse portfólio de certificações, oferecendo um mapa de conformidade abrangente para casos de uso europeus e internacionais.

    Disponibilidade Regional

    O AWS Payment Cryptography está disponível nas seguintes regiões da AWS:

    • América do Norte: Canadá (Montreal), EUA (Ohio, N. Virginia, Oregon)
    • Europa: Irlanda, Frankfurt, Londres, Paris
    • África: Cape Town
    • Ásia-Pacífico: Singapura, Tóquio, Osaka, Mumbai, Hyderabad, Sydney

    Essa distribuição geográfica oferece flexibilidade para organizações que processam pagamentos em múltiplas jurisdições.

    Próximos Passos

    Para começar a utilizar o serviço, os usuários podem baixar a versão mais recente da CLI/SDK da AWS e consultar o guia de usuário do AWS Payment Cryptography, que inclui detalhes adicionais sobre conformidade e orientações técnicas para implementação.

    Fonte

    AWS Payment Cryptography Achieves Cartes Bancaires Approval (https://aws.amazon.com/about-aws/whats-new/2026/02/payment-cryptography-cartes-bancaires)

  • Modelo NVIDIA Nemotron 3 Nano 30B MoE agora disponível no Amazon SageMaker JumpStart

    O modelo de IA generativa NVIDIA Nemotron agora está no SageMaker JumpStart

    A AWS anunciou a disponibilidade geral do modelo NVIDIA Nemotron 3 Nano 30B, com 3 bilhões de parâmetros ativos, no catálogo de modelos do Amazon SageMaker JumpStart. Essa integração oferece aos desenvolvedores brasileiros a oportunidade de acelerar a inovação e entregar valor comercial concreto com o Nemotron 3 Nano na plataforma AWS, sem a necessidade de gerenciar complexidades de implantação de modelos.

    Com as capacidades gerenciadas do SageMaker JumpStart, é possível potencializar aplicações de IA generativa com as capacidades do Nemotron. O modelo é classificado como um pequeno modelo híbrido de mistura de especialistas (Mixture of Experts — MoE), projetado para oferecer a mais alta eficiência computacional e precisão, permitindo que desenvolvedores executem tarefas de agentes altamente especializadas em escala.

    Características principais do Nemotron 3 Nano 30B

    O que diferencia o Nemotron 3 Nano de outras soluções disponíveis no mercado é sua arquitetura inovadora e desempenho comprovado. O modelo é totalmente aberto, com pesos de código aberto, conjuntos de dados e receitas publicados. Isso permite que desenvolvedores personalizem, otimizem e implantem o modelo em sua própria infraestrutura, atendendo requisitos específicos de privacidade e segurança.

    Arquitetura e design

    O Nemotron 3 Nano utiliza uma arquitetura híbrida que combina Transformer com Mamba. Uma característica importante é o suporte a orçamento de tokens, que permite alcançar precisão ótima enquanto minimiza a geração de tokens de raciocínio durante a inferência.

    Desempenho em benchmarks técnicos

    O modelo demonstra excelência em codificação e raciocínio, liderando em diversos benchmarks reconhecidos internacionalmente: SWE Bench Verified, GPQA Diamond, AIME 2025, Arena Hard v2 e IFBench. Em comparação com outros modelos de linguagem abertos com menos de 30 bilhões de parâmetros, o Nemotron se destaca em tarefas de codificação, raciocínio científico, matemática e compreensão de instruções.

    Capacidades técnicas

    O modelo oferece um contexto de até 1 milhão de tokens, funcionando como modelo de fundação baseado em texto, tanto para entradas quanto saídas. Com 30 bilhões de parâmetros totais, mas apenas 3 bilhões ativados simultaneamente, alcança uma relação impressionante entre capacidade e eficiência computacional.

    Como começar com o Nemotron 3 Nano no SageMaker JumpStart

    Requisitos iniciais

    Para utilizar o Nemotron 3 Nano no Amazon SageMaker JumpStart, é necessário ter um domínio do Amazon SageMaker Studio provisionado.

    Processo de implantação

    Para testar o modelo, abra o SageMaker Studio e navegue até a seção “Models” no painel de navegação. Digite “NVIDIA” na barra de pesquisa e selecione o “NVIDIA Nemotron 3 Nano 30B”. Na página de detalhes do modelo, escolha “Deploy” e siga as instruções fornecidas para concluir a implantação. Após o modelo estar ativo em um endpoint de SageMaker AI, você poderá testá-lo imediatamente.

    Acesso via linha de comando

    O modelo pode ser acessado utilizando exemplos da Interface de Linha de Comando da AWS (AWS CLI). Use o identificador de modelo nvidia/nemotron-3-nano para fazer referência ao modelo.

    cat > input.json << EOF
    {
      "model": "${MODEL_ID}",
      "messages": [
        {
          "role": "system",
          "content": "You are a helpful assistant."
        },
        {
          "role": "user",
          "content": "What is NVIDIA? Answer in 2-3 sentences."
        }
      ],
      "max_tokens": 512,
      "temperature": 0.2,
      "stream": False,
      "chat_template_kwargs": {"enable_thinking": False}
    }
    EOF
    
    aws sagemaker-runtime invoke-endpoint \
      --endpoint-name ${ENDPOINT_NAME} \
      --region ${AWS_REGION} \
      --content-type 'application/json' \
      --body fileb://input.json \
      > response.json

    Integração com SDK do SageMaker e Boto3

    Alternativamente, é possível acessar o modelo usando o SDK do SageMaker e a biblioteca Boto3. O exemplo abaixo em Python demonstra como enviar uma mensagem de texto ao Nemotron 3 Nano 30B através do SageMaker SDK:

    runtime_client = boto3.client('sagemaker-runtime', region_name=region)
    
    payload = {
      "messages": [
        {"role": "user", "content": prompt}
      ],
      "max_tokens": 1000
    }
    
    try:
      response = self.runtime_client.invoke_endpoint(
        EndpointName=self.endpoint_name,
        ContentType='application/json',
        Body=json.dumps(payload)
      )
      response_body = response['Body'].read().decode('utf-8')
      raw_response = json.loads(response_body)
      return self.parse_response(raw_response)
    except Exception as e:
      raise Exception(
        f"Failed to invoke endpoint '{self.endpoint_name}': {str(e)}. "
        f"Check that the endpoint is InService and you have least-privileged IAM permissions assigned."
      )

    Para exemplos adicionais de código, consulte o repositório GitHub da NVIDIA.

    Disponibilidade e recursos complementares

    O NVIDIA Nemotron 3 Nano agora está totalmente gerenciado no SageMaker JumpStart. Verifique a documentação do pacote de modelo para conhecer a disponibilidade em cada região da AWS. Para aprender mais sobre o serviço, consulte a página do modelo Nemotron Nano, o notebook de exemplo da NVIDIA no GitHub para o Nemotron 3 Nano 30B, e a página de preços do Amazon SageMaker JumpStart.

    Desenvolvedores brasileiros que desejarem testar o modelo e compartilhar feedback podem fazê-lo através do AWS re:Post para SageMaker JumpStart ou através dos canais habituais de suporte da AWS.

    Fonte

    NVIDIA Nemotron 3 Nano 30B MoE model is now available in Amazon SageMaker JumpStart (https://aws.amazon.com/blogs/machine-learning/nvidia-nemotron-3-nano-30b-is-now-available-in-amazon-sagemaker-jumpstart/)

  • Dominando Limitações e Disponibilidade do Amazon Bedrock: Um Guia Prático para Aplicações em Produção

    O Desafio das Aplicações de IA em Produção

    Quando aplicações de inteligência artificial generativa entram em produção, erros se tornam inevitáveis. Os dois mais comuns são aqueles que retornam 429 ThrottlingException (requisição rejeitada por excesso de volume) e 503 ServiceUnavailableException (serviço temporariamente indisponível). Embora a maioria desses erros seja recuperável através de tentativas subsequentes, o impacto na experiência do usuário é imediato: atrasos nas respostas, interrupções na fluidez da conversa e, potencialmente, abandono da plataforma.

    O desafio fica ainda mais complexo em cenários com múltiplos usuários acessando o mesmo modelo simultaneamente. Nesse contexto, a diferença entre uma aplicação resiliente e usuários frustrados está justamente na capacidade de tratar esses erros adequadamente. Uma estratégia bem elaborada de retry, rate limiting e observabilidade pode transformar falhas transitórias em pequenos incômodos em vez de bloqueadores críticos.

    Diferenças Entre os Dois Tipos de Erro

    Entender a raiz de cada erro é fundamental para implementar a solução correta. O erro 503 ocorre quando o serviço Bedrock enfrenta problemas de capacidade ou infraestrutura — é uma questão de saúde do serviço. Já o 429 emerge quando a conta atinge seus limites de quota — seja em requisições por minuto (RPM – Requisições Por Minuto) ou em tokens processados por minuto (TPM – Tokens Por Minuto).

    A estratégia de retry para cada um difere significativamente. Para 503, tentativas com backoff exponencial funcionam bem, pois o serviço geralmente se recupera em segundos. Para 429, é necessário sincronizar as tentativas com o ciclo de renovação de quota, que ocorre a cada 60 segundos.

    Entendendo o Erro 429: ThrottlingException

    Como Funciona a Limitação por Taxa de Requisição (RPM)

    O erro RPM surge quando o número total de chamadas ao Bedrock por minuto ultrapassa a quota configurada para a conta. O ponto crítico é que esse limite se aplica globalmente a todos os aplicativos que chamam o serviço na mesma região, não individualmente por aplicação.

    Imagine um cenário com três aplicações em produção, todas consumindo o mesmo modelo Bedrock na mesma região. A aplicação A pico em 50 requisições por minuto, assim como B e C. A quota contratada é de 150 RPM, que parecia adequada. Porém, na prática o tráfego não é perfeitamente uniforme. Durante uma promoção, a aplicação A salta para 60 RPM enquanto B e C permanecem em 50. O total chega a 160 RPM e algumas requisições começam a falhar.

    Mitigar esse problema requer ação em dois frontes: no lado do cliente e no lado da quota. No cliente, implementar rate limiting por aplicação garante que uma aplicação “barulhenta” não esgote a quota de outras. Usar exponencial backoff com variação aleatória (jitter) faz com que retries não ocorram sincronizados entre múltiplas instâncias. Sincronizar finais de retry com o ciclo de 60 segundos aumenta a chance de sucesso.

    No lado da quota, monitorar as métricas reais de pico via Amazon CloudWatch e solicitar aumentos através do AWS Service Quotas garante espaço para crescimento sem que surpreças de tráfego virem incidentes.

    Limitação por Tokens (TPM)

    Mesmo com contagem de requisições modestas, um único prompt grande ou uma resposta longa podem consumir milhares de tokens. O erro TPM ocorre quando o total de tokens (entrada + saída) por minuto excede a quota da conta.

    Uma aplicação enviando 10 requisições por minuto com 15 mil tokens de entrada e 5 mil de saída cada uma consome aproximadamente 200 mil tokens por minuto — muito mais restritivo que 200 pequenos prompts. Esse cenário frequentemente se manifesta quando usuários colam documentos grandes, transcripts longos ou executam trabalhos em lote de sumarização.

    Responder a isso significa monitorar proativamente o consumo de tokens através de logs do Bedrock, implementar um rate limiter que mantenha janela deslizante de 60 segundos de consumo, e quebrar tarefas grandes em chunks menores espalhados ao longo do tempo. Usar respostas em stream também ajuda, pois fornece mais controle sobre quando parar a geração.

    Limitação Específica por Modelo

    Às vezes o erro indica que um modelo específico está sobrecarregado — não é problema de quota da conta, mas de saturação temporária da infraestrutura compartilhada daquele modelo. Nesses casos, projetar para degradação graciosa funciona melhor que tratar como falha dura.

    Implementar fallback automático para modelos alternativos (por exemplo, se Claude Sonnet está indisponível, usar Claude Haiku) combinado com failover entre regiões melhora significativamente a resiliência. Expor esse comportamento degradado nos dashboards garante visibilidade — em vez de mascarar silenciosamente o problema.

    Entendendo o Erro 503: ServiceUnavailableException

    Esgotamento do Pool de Conexões

    Este erro frequentemente não vem do Bedrock em si, mas da forma como o cliente está configurado. O boto3 utiliza um pool HTTP padrão relativamente pequeno (cerca de 10 conexões), facilmente saturado em workloads altamente concorrentes. Criar um novo cliente para cada requisição multiplica desnecessariamente o número de conexões abertas.

    A solução é compartilhar uma única instância de cliente Bedrock e aumentar o tamanho do pool:

    import boto3
    from botocore.config import Config
    
    config = Config(
        max_pool_connections=50,
        retries={'max_attempts': 3}
    )
    bedrock_client = boto3.client('bedrock-runtime', config=config)

    Problemas Temporários de Recursos do Serviço

    Quando a AWS Bedrock sinaliza indisponibilidade temporária, geralmente está lidando com pico de demanda em modelos on-demand. Nesse cenário, tratar como outage transitória e focar em retry inteligente com fallover gracioso é a estratégia adequada.

    Padrões Avançados de Resiliência

    O Padrão Circuit Breaker

    Para sistemas críticos, simples retries não bastam. O padrão circuit breaker evita que a aplicação continue martelando um serviço já falho. Funciona em três estados: CLOSED (operação normal), OPEN (rejeitando requisições após múltiplas falhas) e HALF_OPEN (testando recuperação).

    Quando Bedrock retorna 503, continuar enviando requisições piora a situação. O circuit breaker reduz a carga no serviço em dificuldade, ajudando sua recuperação mais rápida, falha rapidamente em vez de desperdiçar tempo em requisições que provavelmente falharão, e se recupera automaticamente testando periodicamente se o serviço se restabeleceu.

    Failover entre Regiões com CRIS

    O recurso Cross-Region Inference (CRIS) da AWS Bedrock oferece um mecanismo gerenciado de roteamento de tráfego entre regiões. Perfis CRIS globais podem enviar tráfego para regiões comerciais da AWS com melhor combinação de throughput e custo. Perfis geográficos confinam o tráfego a geografias específicas para atender requisitos rígidos de residência de dados.

    Para workloads não reguladas, usar perfil global melhora significativamente disponibilidade e absorve picos regionais. Para workloads reguladas, configurar perfis geográficos alinhados com limites de compliance fornece controle necessário.

    Implementação de Retry e Rate Limiting Robusto

    Backoff Exponencial com Jitter

    Este padrão é essencial para tratar throttling graciosamente, evitando martelar o serviço imediatamente após falha e prevenindo que múltiplas instâncias retry no mesmo momento:

    import time
    import random
    from botocore.exceptions import ClientError
    
    def bedrock_request_with_retry(bedrock_client, operation, **kwargs):
        """Secure retry implementation with sanitized logging."""
        max_retries = 5
        base_delay = 1
        max_delay = 60
        
        for attempt in range(max_retries):
            try:
                if operation == 'invoke_model':
                    return bedrock_client.invoke_model(**kwargs)
                elif operation == 'converse':
                    return bedrock_client.converse(**kwargs)
            except ClientError as e:
                if e.response['Error']['Code'] == 'ThrottlingException':
                    if attempt == max_retries - 1:
                        raise
                    delay = min(base_delay * (2 ** attempt), max_delay)
                    jitter = random.uniform(0, delay * 0.1)
                    time.sleep(delay + jitter)
                    continue
                else:
                    raise

    Rate Limiter Consciente de Tokens

    Para limitação baseada em tokens, manter janela deslizante de 60 segundos de consumo permite decidir de forma simples se é seguro enviar outra requisição:

    import time
    from collections import deque
    
    class TokenAwareRateLimiter:
        def __init__(self, tpm_limit):
            self.tpm_limit = tpm_limit
            self.token_usage = deque()
        
        def can_make_request(self, estimated_tokens):
            now = time.time()
            while self.token_usage and self.token_usage[0][0] < now - 60:
                self.token_usage.popleft()
            current_usage = sum(tokens for _, tokens in self.token_usage)
            return current_usage + estimated_tokens <= self.tpm_limit
        
        def record_usage(self, tokens_used):
            self.token_usage.append((time.time(), tokens_used))

    Monitoramento e Observabilidade

    Não é possível gerenciar aquilo que não se consegue visualizar. O Amazon CloudWatch fornece métricas essenciais: Invocations (invocações bem-sucedidas), InvocationClientErrors (erros 4xx incluindo throttling), InvocationServerErrors (erros 5xx incluindo indisponibilidade), InvocationThrottles (erros 429 específicos), InvocationLatency (tempos de resposta) e InputTokenCount/OutputTokenCount (consumo de tokens).

    Dashboards efetivos separam 429 e 503 em widgets diferentes, desagregam por ModelId e Região, e mostram comparações lado a lado do tráfego atual versus semanas anteriores para detectar tendências emergentes.

    Alarmes críticos devem disparar para: múltiplos eventos de throttling em janela de 5 minutos, períodos consecutivos com throttles indicando pressão sustentada, quota utilizada acima de 80%, taxa de sucesso abaixo da SLA (por exemplo, 95% em 10 minutos), e picos súbitos de 503 correlacionados com regiões ou modelos específicos.

    Use Amazon Simple Notification Service (Amazon SNS) para rotear alertas aos canais de comunicação da equipe (Slack, PagerDuty, email). Configure níveis de severidade diferentes e inclua descrições detalhadas com links para runbooks de troubleshooting.

    Reunindo Tudo: Construindo Aplicações Resilientes

    O sucesso ao lidar com erros do Bedrock requer compreensão de causas raiz — distinguir entre limites de quota (429) e problemas de capacidade (503). Implementar retries apropriados com parâmetros diferentes para cada tipo de erro. Desenhar para escala utilizando connection pooling, circuit breakers e failover entre regiões. Monitorar proativamente com CloudWatch e alertas bem configurados. Planejar para crescimento solicitando aumentos de quota e implementando estratégias de fallback.

    Como próximo passo, identifique seus workloads Bedrock mais críticos, implemente os padrões de retry e rate limiting aqui descritos, e construa dashboards e alarmes que exponham picos reais em vez de apenas médias. Ao longo do tempo, use dados de tráfego real para refinar quotas, modelos de fallback e deployments regionais, garantindo que seus sistemas de IA permaneçam poderosos e confiáveis conforme escalam.

    Para equipes buscando acelerar resolução de incidentes, a AWS oferece o AWS DevOps Agent — um agente com inteligência artificial que investiga erros do Bedrock correlacionando métricas CloudWatch, logs e alarmes assim como um engenheiro DevOps experiente faria, identificando automaticamente causas raiz e sugerindo passos de remediação.

    Fonte

    Mastering Amazon Bedrock throttling and service availability: A comprehensive guide (https://aws.amazon.com/blogs/machine-learning/mastering-amazon-bedrock-throttling-and-service-availability-a-comprehensive-guide/)

  • Assistentes de voz em tempo real com Amazon Nova Sonic: uma alternativa às arquiteturas em cascata

    A transformação dos assistentes de voz por IA

    Os agentes de IA por voz estão redefinindo a forma como nos relacionamos com a tecnologia. Em atendimento ao cliente, assistência em saúde, automação residencial e produtividade pessoal, esses assistentes virtuais inteligentes ganham rapidamente espaço em diversos segmentos da indústria. Suas capacidades de processamento de linguagem natural, disponibilidade constante e sofisticação crescente os transformam em ferramentas valiosas para empresas que buscam eficiência e para indivíduos que desejam experiências digitais fluidas.

    A AWS recentemente apresentou o Amazon Nova Sonic, um modelo que viabiliza conversas de voz humanas em tempo real através de uma interface de streaming bidirecional. O modelo compreende diferentes estilos de fala e gera respostas expressivas que se adaptam tanto ao conteúdo quanto à entonação das palavras pronunciadas. Com suporte para múltiplos idiomas e disponibilidade de vozes masculinas e femininas, torna-se particularmente adequado para atendimento ao cliente, campanhas de marketing, assistentes de voz e aplicações educacionais.

    Comparando abordagens arquiteturais

    Sistemas clássicos de chat por voz utilizam arquiteturas em cascata com processamento sequencial, enquanto modelos mais recentes como o Amazon Nova Sonic combinam compreensão e geração de fala em um único modelo ponta a ponta. A abordagem tradicional decompõe o processamento de IA por voz em componentes distintos que funcionam em sequência:

    O pipeline tradicional em cascata

    • Detecção de atividade de voz (VAD): Um componente de pré-processamento identifica quando o usuário faz pausa ou para de falar.
    • Conversão de fala em texto (STT): As palavras pronunciadas são transformadas em formato textual através de reconhecimento automático de fala.
    • Processamento com modelo de linguagem grande (LLM): O texto transcrito é processado por um LLM ou gerenciador de diálogo, que analisa a entrada e gera uma resposta textual apropriada conforme o contexto da conversa.
    • Conversão de texto em fala (TTS): A resposta textual é reconvertida em áudio natural através de um modelo TTS e reproduzida ao usuário.

    Os desafios da arquitetura em cascata

    Embora arquiteturas em cascata ofereçam benefícios como modularidade, componentes especializados e facilidade de depuração, elas enfrentam dois grandes problemas: latência cumulativa e redução na interatividade.

    O efeito cascata

    Considere um assistente de voz respondendo uma consulta simples sobre o tempo. Em pipelines em cascata, cada etapa de processamento introduz latência e possibilidade de erros. Implementações de clientes demonstraram como interpretações incorretas iniciais podem se propagar através do pipeline, frequentemente resultando em respostas inadequadas. Esse efeito cascata complica a resolução de problemas e impacta negativamente a experiência do usuário.

    O tempo é fundamental

    Conversas naturais dependem de tempo apropriado. O processamento sequencial pode criar atrasos notáveis nos tempos de resposta. Essas interrupções no fluxo conversacional podem gerar fricção com o usuário e reduzir satisfação.

    O desafio da integração

    IA por voz demanda mais que apenas processamento de fala — requer padrões de interação naturais. Feedbacks de clientes evidenciaram como orquestrar múltiplos componentes dificultava o manejo de elementos dinâmicos de conversa, como interrupções ou trocas rápidas. Os recursos de engenharia frequentemente se concentravam mais em gerenciar o pipeline do que na qualidade da interação.

    A realidade dos recursos

    Arquiteturas em cascata exigem recursos computacionais independentes, monitoramento e manutenção para cada componente. Essa complexidade arquitetural impacta tanto a velocidade de desenvolvimento quanto a eficiência operacional. Os desafios de escalabilidade se intensificam conforme o volume de conversas aumenta, afetando confiabilidade do sistema e otimização de custos.

    Como o Nova Sonic aborda esses desafios

    Essas limitações conduziram decisões arquiteturais fundamentais no desenvolvimento do Nova Sonic, que busca atender à necessidade essencial de processamento de fala ponta a ponta unificado. Isso viabiliza experiências de voz naturais e responsivas sem a complexidade de gerenciar múltiplos componentes.

    Análise comparativa: fala ponta a ponta versus cascata

    Latência

    Nova Sonic: O modelo apresenta desempenho otimizado de latência. A AWS avalia a performance usando a métrica Time to First Audio (TTFA 1.09), que mede o tempo decorrido desde a conclusão da consulta falada do usuário até o recebimento do primeiro byte de áudio de resposta. Consulte o relatório técnico e cartão do modelo para detalhes completos.

    Modelos em cascata: Podem utilizar múltiplos modelos entre reconhecimento de fala, compreensão de linguagem e geração de voz, mas enfrentam latência adicional e propagação potencial de erros entre etapas. Utilizando frameworks de orquestração assíncrona modernos como Pipecat e LiveKit, é possível minimizar latência. Componentes de streaming e uso de pausas TTS ajudam a manter fluxo conversacional natural e reduzir atrasos.

    Complexidade arquitetural e de desenvolvimento

    Nova Sonic: Oferece arquitetura simplificada. O modelo combina conversão de fala em texto, compreensão de linguagem natural e conversão de texto em fala em uma única arquitetura, com uso de ferramentas integrado e detecção de barge-in. Disponibiliza uma arquitetura orientada por eventos para eventos de entrada e saída chave, além de uma API de streaming bidirecional que simplifica a experiência do desenvolvedor.

    Modelos em cascata: Exigem seleção de modelos melhores em sua classe para cada etapa do pipeline, enquanto orquestram componentes adicionais como pipelines assincronos para agentes delegados, uso de ferramentas, pausas TTS e VAD, adicionando complexidade significativa.

    Personalização e controle de modelos

    Nova Sonic: Oferece menor controle granular sobre componentes individuais. O serviço permite personalização de vozes, uso integrado de ferramentas e integrações com Amazon Bedrock Knowledge Bases e Amazon Bedrock AgentCore. Porém, não oferece o mesmo nível de granularidade disponível em sistemas totalmente modulares.

    Modelos em cascata: Proporcionam maior controle sobre cada etapa, permitindo ajuste individual, substituição e otimização independente de cada componente de modelo como STT, compreensão de linguagem e TTS. Isso inclui modelos do Amazon Bedrock Marketplace, Amazon SageMaker AI e modelos ajustados. Essa modularidade viabiliza flexibilidade e seleção de modelos, tornando-se ideal para capacidades complexas ou especializadas que exigem desempenho personalizado.

    Estrutura de custos

    Nova Sonic: Estrutura de custos simplificada através de uma abordagem integrada, utilizando modelo de consumo baseado em tokens.

    Modelos em cascata: Compõem múltiplos componentes cujos custos precisam ser estimados individualmente. Isso é especialmente importante em escala e volumes elevados.

    Suporte de idiomas e sotaques

    Nova Sonic: Suporta idiomas específicos conforme documentação da AWS.

    Modelos em cascata: Podem oferecer suporte mais amplo de idiomas através de modelos especializados, incluindo possibilidade de alternar idiomas durante a conversa.

    Disponibilidade regional

    Nova Sonic: Disponível nas regiões suportadas pela AWS.

    Modelos em cascata: Potencialmente mais amplo suporte regional devido à diversidade de modelos disponíveis e capacidade de auto-hospedar modelos em Amazon Elastic Kubernetes Service (Amazon EKS) ou Amazon SageMaker.

    Características compartilhadas entre as abordagens

    Opções de telefonia e transporte

    Ambas as abordagens — em cascata e ponta a ponta — suportam diversos protocolos de telefonia e transporte como WebRTC e WebSocket. Esses protocolos viabilizam streaming de áudio em tempo real e com baixa latência pela web e redes telefônicas. Facilitam troca de áudio bidirecional contínua, fundamental para experiências conversacionais naturais, permitindo que sistemas de IA por voz se integrem facilmente com infraestruturas de comunicação existentes mantendo responsividade e qualidade de áudio. A AWS oferece um guia de integração de telefonia para Nova Sonic.

    Avaliação, observabilidade e testes

    Ambas as abordagens de IA por voz — em cascata e ponta a ponta — podem ser sistematicamente avaliadas, observadas e testadas para comparação confiável. Investir em um sistema de avaliação e observabilidade de IA por voz é recomendado para ganhar confiança na precisão e desempenho de produção. Tal sistema deve ser capaz de rastrear todo o pipeline entrada-saída, capturando métricas e dados de conversa ponta a ponta para avaliar de forma abrangente qualidade, latência e robustez conversacional ao longo do tempo.

    Frameworks para desenvolvedores

    Ambas as abordagens contam com suporte de frameworks de IA por voz de código aberto líderes como Pipecat e LiveKit. Esses frameworks proporcionam pipelines modulares e flexíveis com capacidades de processamento em tempo real que desenvolvedores podem utilizar para construir, personalizar e orquestrar modelos de IA por voz de forma eficiente entre diferentes componentes e estilos de interação.

    Guia prático: quando usar cada abordagem

    Use fala ponta a ponta (Nova Sonic) quando:

    • A simplicidade da implementação é importante
    • O caso de uso se encaixa nas capacidades do Nova Sonic
    • Você busca uma experiência de chat em tempo real que soe humana e ofereça baixa latência

    Use modelos em cascata quando:

    • Personalização de componentes individuais é necessária
    • Você precisa usar modelos especializados do Amazon Bedrock Marketplace, Amazon SageMaker AI, ou modelos ajustados para seu domínio específico
    • Você necessita de suporte para idiomas ou sotaques não cobertos pelo Nova Sonic
    • O caso de uso requer processamento especializado em etapas específicas

    Conclusão

    O Amazon Nova Sonic representa uma evolução significativa na construção de assistentes de voz inteligentes. Projetado para resolver desafios enfrentados por arquiteturas em cascata, o modelo simplifica o desenvolvimento de agentes de IA por voz e oferece capacidades conversacionais genuinamente naturais.

    Se sua organização opera sistemas de voz em cascata e considera melhorias, agora possui as informações necessárias para avaliar uma migração para Nova Sonic a fim de oferecer experiências conversacionais fluidas e em tempo real com uma arquitetura simplificada.

    Para saber mais, consulte o Amazon Nova Sonic e contate seu time de contas para explorar como você pode acelerar suas iniciativas de IA por voz.

    Recursos adicionais

    Fonte

    Building real-time voice assistants with Amazon Nova Sonic compared to cascading architectures (https://aws.amazon.com/blogs/machine-learning/building-real-time-voice-assistants-with-amazon-nova-sonic-compared-to-cascading-architectures/)