Author: Make.com Service User

  • Colaboração entre Agentes: Usando Amazon Nova 2 Lite e Amazon Nova Act em Sistemas Multi-Agentes

    O Problema do Agente Único Sobrecarregado

    Os primeiros protótipos de sistemas baseados em agentes de inteligência artificial costumam compartilhar a mesma arquitetura: um único modelo grande, alguns conectores para ferramentas externas e um extenso prompt de sistema. Essa abordagem funciona razoavelmente bem enquanto os casos de uso permanecem relativamente simples e contidos. No entanto, quando a complexidade real do mundo chega à porta, o sistema começa a desmoronar.

    Considere um cenário comum: construir um assistente para planejamento de viagens. As buscas de voos chegam através de uma API estruturada e previsível. As buscas de hotéis, por sua vez, precisam navegar em interfaces web dinâmicas que mudam constantemente. Instruir um único modelo para lidar com ambas as tarefas simultaneamente é como pedir que um engenheiro escreva APIs de backend enquanto também clica manualmente em um site em tempo real. Com o tempo, o modelo começa a confundir instruções, perde contexto e alucina etapas inexistentes.

    Aumentar o prompt, adicionar mais ferramentas e implementar lógica de fallback não resolve o problema fundamental: o sistema foi projetado de forma inadequada. Um agente único, quando sobrecarregado com muitas responsabilidades, desacelera, perde rastreabilidade das decisões, faz escolhas inconsistentes e eventualmente colapsa sob seu próprio peso. A solução não está em melhorar o prompting — está em reimaginar a arquitetura.

    Arquitetura de Múltiplos Agentes Especializados

    A estratégia mais eficaz é dividir o trabalho entre agentes especializados, permitindo que cada um se concentre em uma única responsabilidade bem definida. Em vez de forçar um modelo a fazer tudo, designa-se:

    • Agente Viagem: Orquestra todo o fluxo, interpreta a intenção do usuário e coordena os demais agentes
    • Agente Voos: Realiza buscas estruturadas em APIs de voos, onde os dados são previsíveis e organizados
    • Agente Hotéis: Navega em sites reais de hotéis, lidando com layouts dinâmicos e elementos visuais complexos

    Essa separação mantém a lógica limpa e evita que agentes individuais se tornem os gargalos do sistema. Cada um executa sua função com excelência, e um simples mecanismo de passagem de mensagens coordena todo o workflow sem complicações.

    Imagem original — fonte: Aws

    Comunicação Entre Agentes

    Para que essa arquitetura funcione, os agentes precisam de um mecanismo simples e robusto para se comunicar. O Agente Viagem envia uma solicitação clara ao Agente Voos, aguarda os resultados, e então dispara o Agente Hotéis com a próxima etapa. Não é necessário nada sofisticado — apenas um formato leve de mensagens estruturadas em JSON que cada agente compreenda e saiba como processar.

    Quando esse loop de comunicação está em lugar, todo o workflow finalmente se sente coordenado em vez de caótico. Cada mensagem é um objeto JSON compacto contendo a ação, os dados de entrada e o destino da resposta. Essa simplicidade é o segredo para manter o sistema compreensível e manutenível conforme ele cresce.

    Implementação Prática com Amazon Nova

    Agente Viagem (Amazon Nova 2 Lite)

    O Agente Viagem atua como o orquestrador central. Recebe a requisição do usuário em linguagem natural, interpreta a intenção usando Amazon Nova 2 Lite e decide quais agentes chamar em sequência. A tarefa pesada de raciocínio acontece aqui: o modelo quebra a entrada em etapas, identifica quando disparar o Agente Voos ou o Agente Hotéis, e mantém o registro do plano geral.

    Como o Agente Viagem não toca sistemas externos diretamente, seu trabalho concentra-se em raciocinar com clareza e rotear mensagens entre os agentes especializados. Ele opera sobre Amazon Bedrock, a plataforma gerenciada da AWS para modelos fundacionais.

    Aqui está uma versão simplificada de como o Agente Viagem é inicializado:

    # Initialize A2A client tools provider
    provider = A2AClientToolProvider(known_agent_urls=[
        "http://localhost:9000",  # Hotel Booking Expert (NovaAct)
        "http://localhost:9001"   # Flight Booking Expert
    ])
    
    bedrock_model = BedrockModel(
        model_id="global.amazon.nova-2-lite-v1:0",
        region_name="us-east-1",
    )
    
    # Create client agent with A2A tools
    client_agent = Agent(
        name="Travel Client",
        model=bedrock_model,
        description="Client agent that coordinates travel planning using specialized A2A agents",
        tools=provider.tools,
        system_prompt="""You are an autonomous travel planning agent. You MUST take action immediately without asking for confirmation."""
    )

    Na prática, o Agente Viagem recebe uma requisição em linguagem natural simples: “Encontre voos de Nova York para Tóquio em 10 de julho e um hotel até 15 de julho.” A partir daí, Amazon Nova 2 Lite reconhece que duas tarefas separadas são necessárias, gera um plano claro, envia uma mensagem ao Agente Voos, aguarda os resultados, e depois dispara o Agente Hotéis com a próxima instrução. Por fim, monta ambas as saídas em uma resposta coerente para o usuário. Essa orquestração mantém a lógica limpa e fluida.

    Agente Voos (Amazon Nova 2 Lite + API)

    O Agente Voos tem um escopo muito mais estreito: transformar uma requisição estruturada em opções reais de voos. Utiliza Amazon Nova 2 Lite para o raciocínio leve necessário — validar entradas, formatar a busca e decidir se chama a API de voos ao vivo ou retorna dados de fallback quando credenciais não estão disponíveis.

    Após a chamada à API, o agente devolve uma resposta JSON limpa e previsível ao Agente Viagem. Como esse agente trabalha com dados estruturados, a carga de raciocínio é mínima e o trabalho do Nova 2 Lite consiste principalmente em escolher o caminho correto de execução e normalizar a saída.

    @tool
    def search_flights(origin: str, destination: str, departure_date: str, return_date: Optional[str] = None) -> str:
        # Nova 2 Lite handles the reasoning around which path to take
        if amadeus_configured():
            return _search_amadeus_flights(
                origin=origin,
                destination=destination,
                departure_date=departure_date,
                return_date=return_date
            )
        else:
            # Local development fallback
            return _search_flights_web(origin, destination, departure_date, return_date)

    E aqui está um exemplo simplificado da resposta:

    {
        "flights": [
            {
                "flight_number": "DL456",
                "price": 520,
                "duration": "14h 30m"
            },
            {
                "flight_number": "JL701",
                "price": 545,
                "duration": "13h 50m"
            }
        ],
        "source": "Amadeus API"
    }

    Essa separação mantém todo o pipeline previsível e evita que lógica específica de API vaze para dentro do Agente Viagem.

    Agente Hotéis (Amazon Nova Act)

    Hotéis são fundamentalmente diferentes de voos. Não existe uma API única e limpa para consultá-los — a maioria dos sites carrega conteúdo de formas que mudam a cada visita. É nesse cenário que Amazon Nova Act brilha.

    O Agente Hotéis utiliza Nova Act para controlar um navegador real e seguir instruções em linguagem natural. Em vez de escrever código frágil de web scraping ou parsing de DOM, o agente instrui o Nova Act sobre o que precisa, e o modelo cuida da navegação, retornando dados estruturados.

    @tool
    def search_hotels(location: str, checkin_date: str, nights: int = 2) -> str:
        with NovaAct() as nova:
            result = nova.act(
                f"Search for hotels in {location} from {checkin_date} for {nights} nights. "
                f"Return the top 3 listings with name, price, and rating.",
                schema=HotelSearchResults.model_json_schema()
            )
        return json.dumps(result)

    Aqui está um exemplo simplificado da resposta:

    {
        "hotels": [
            {
                "name": "Shinjuku Grand",
                "price": "$180",
                "rating": 4.3
            },
            {
                "name": "Park Tower Tokyo",
                "price": "$210",
                "rating": 4.6
            },
            {
                "name": "Hotel Blossom",
                "price": "$155",
                "rating": 4.0
            }
        ],
        "source": "Anycompany.com via Nova Act"
    }

    Usar Amazon Nova Act mantém o Agente Hotéis funcionando mesmo quando os sites mudam de layout. Não há necessidade de manutenção constante ou ajustes frágeis.

    Exemplo de Execução Completa

    Para ilustrar como tudo funciona na prática, aqui está um fluxo de execução real:

    Requisição do usuário: “Organize uma viagem para uma pessoa de Nova York a Paris em 6 de dezembro de 2025, incluindo duas noites de hospedagem em Paris.”

    Agente Viagem → Agente Voos: O Agente Viagem extrai a parte de voos da requisição e a envia. O Agente Voos retorna três voos diretos e baratos de JFK para Paris, incluindo companhia aérea, horários, preço e duração.

    Agente Viagem → Agente Hotéis: O Agente Viagem envia a parte de hospedagem. O Agente Hotéis, utilizando Nova Act, consulta hotéis em Paris e retorna as três opções principais com nomes, preços e notas resumidas.

    Resultado final para o usuário: O Agente Viagem combina ambas as respostas e retorna um resumo claro incluindo:

    • O voo recomendado
    • O hotel recomendado
    • Data de check-in e check-out
    • Preços totais
    • Uma pergunta se deseja prosseguir com a reserva

    Vantagens da Abordagem Multi-Agentes

    Construir um planejador de viagens com três agentes pequenos e especializados provou ser muito mais fácil de gerenciar do que um único agente monolítico. Cada agente concentra-se em uma tarefa bem definida. Amazon Nova 2 Lite realiza o raciocínio necessário para mover o trabalho de uma etapa para a próxima. Amazon Nova Act cobre as partes sem APIs, como buscas de hotéis, sem exigir código de scraping manual.

    O padrão de passagem de mensagens mantém tudo conectado mas ainda direto e compreensível. Essa arquitetura não se limita a planejamento de viagens. Qualquer tarefa que misture diferentes habilidades pode usar a mesma abordagem: deixe um agente planejar o trabalho, deixe os outros executarem as partes em que são especializados, e passe mensagens pequenas entre eles. O resultado é um sistema que muda e explica-se naturalmente.

    Para experimentar essa implementação, o código completo e exemplos estão disponíveis no repositório Agent to Agent com Amazon Nova no GitHub.

    Fonte

    Agent-to-agent collaboration: Using Amazon Nova 2 Lite and Amazon Nova Act for multi-agent systems (https://aws.amazon.com/blogs/machine-learning/agent-to-agent-collaboration-using-amazon-nova-2-lite-and-amazon-nova-act-for-multi-agent-systems/)

  • Amazon Neptune Analytics agora disponível em 7 regiões adicionais

    Expansão geográfica do Neptune Analytics

    A AWS anunciou a disponibilidade do Amazon Neptune Analytics em sete regiões adicionais: Oriente Médio (Bahrain), Oriente Médio (Emirados Árabes Unidos), Israel (Tel Aviv), África (Cidade do Cabo), Canadá (Calgary), Ásia-Pacífico (Malásia) e Europa (Zurique). Com essa expansão, os usuários podem agora criar e gerenciar gráficos do Neptune Analytics nessas novas regiões, abrindo possibilidades para executar análises gráficas avançadas em geografias que antes não tinham acesso ao serviço.

    Sobre o Amazon Neptune

    O Neptune é um banco de dados em grafo (graph database) sem servidor que trabalha com dados conectados. A abordagem baseada em grafos traz benefícios significativos, especialmente para aplicações de inteligência artificial: ao modelar dados como um grafo, o serviço captura o contexto relacional dos dados, o que melhora a precisão e a capacidade de explicação das aplicações de IA generativa.

    Um dos principais diferenciais do Neptune é a escalabilidade automática. O serviço escala instantaneamente cargas de trabalho em grafo, eliminando a necessidade de o usuário gerenciar manualmente a capacidade infraestrutura — o que reduz a carga operacional e os custos.

    Capacidades e integrações para IA

    A AWS integrou o Neptune com tecnologias modernas de IA. O serviço oferece GraphRAG (Retrieval-Augmented Generation com grafos) totalmente gerenciado, funcionando em conjunto com o Amazon Bedrock Knowledge Bases. Além disso, o Neptune se integra ao Strands AI Agents SDK e a ferramentas populares de memória para agentes de IA, facilitando o desenvolvimento de aplicações inteligentes.

    Na dimensão de análise, o Neptune consegue processar e analisar dezenas de bilhões de relacionamentos entre dados estruturados e não estruturados em segundos, entregando insights estratégicos que seriam impraticáveis em abordagens tradicionais.

    Diferencial no mercado

    Segundo a AWS, o Neptune é o único banco de dados e mecanismo de análise que combina o poder dos dados conectados com as capacidades empresariais e o valor agregado do ecossistema AWS.

    Como começar

    Para iniciar com o Neptune Analytics, os usuários podem criar novos gráficos usando o Console de Gerenciamento da AWS ou a AWS CLI (Interface de Linha de Comando da AWS). Para detalhes sobre precificação e disponibilidade em regiões, recomenda-se consultar a página de preços do Neptune e a tabela de regiões da AWS.

    Fonte

    Amazon Neptune Analytics is now available in 7 additional regions (https://aws.amazon.com/about-aws/whats-new/2026/02/amazon-neptune-analytics-in-seven-additional-regions)

  • Acelere o desenvolvimento de aplicações com agentes usando o template completo para Amazon Bedrock AgentCore

    Aplicações com agentes ganham velocidade com novo template completo

    Aplicações inteligentes que funcionam como agentes autônomos estão transformando a forma como as empresas operam. De chatbots de atendimento ao cliente até assistentes de pesquisa, a demanda por mover protótipos para produção rapidamente nunca foi tão alta. Nesse contexto, a AWS lançou o Amazon Bedrock AgentCore, uma plataforma de desenvolvimento dedicada à construção, implantação e dimensionamento de agentes de IA em ambientes produtivos.

    O AgentCore oferece componentes fundamentais como hospedagem do runtime, gerenciamento de memória, integração de ferramentas e observabilidade, tudo com segurança em nível empresarial e dimensionamento automático. Para demonstrar como todos esses componentes trabalham juntos desde o início, a AWS disponibilizou o Fullstack AgentCore Solution Template (FAST) — um projeto iniciante pronto para implantação que conecta runtime do AgentCore, gateway, memória e interpretador de código com um frontend em React e autenticação via Amazon Cognito, tudo definido com o AWS Cloud Development Kit (AWS CDK).

    O FAST fornece uma arquitetura de referência completa mostrando como os componentes se integram na prática, acompanhado de uma aplicação de chat funcionando que você pode estudar e expandir conforme suas necessidades.

    Entendendo a arquitetura do FAST

    O template oferece uma pilha tecnológica completa para implantar agentes no Amazon Bedrock AgentCore. A solução gerencia automaticamente autenticação, hospedagem de aplicação frontend, runtime do agente, memória, observabilidade e integração de ferramentas via protocolo de contexto de modelo (Model Context Protocol — MCP) por padrão.

    No núcleo da arquitetura está o Amazon Bedrock AgentCore Runtime, responsável por executar seu agente. Para segurança, os usuários se autenticam através do Amazon Cognito, que protege quatro pontos críticos de integração:

    • Acesso do usuário à aplicação web frontend hospedada no Amazon CloudFront
    • Autenticação baseada em token para o frontend acessar o AgentCore Runtime
    • Autenticação baseada em token para que os agentes acessem o AgentCore Gateway
    • Autenticação baseada em token para requisições de API ao Amazon API Gateway

    O frontend é uma aplicação React que utiliza Tailwind CSS e componentes shadcn, hospedada no AWS Amplify Hosting. A comunicação com o AgentCore Runtime ocorre através de streaming HTTP em tempo real, permitindo respostas contínuas. O mecanismo de feedback integrado demonstra como realizar chamadas HTTP síncronas e autenticadas via API Gateway, armazenando dados de aplicação no DynamoDB.

    Capacidades principais do AgentCore integradas

    O runtime do AgentCore se conecta a diversas capacidades que potencializam o agente:

    AgentCore Memory: Armazena histórico de conversas (curto prazo) e insights extraídos como preferências do usuário (longo prazo), permitindo que seu agente mantenha contexto entre sessões sem exigir trabalho customizado com banco de dados. O FAST inclui memória de curto prazo por padrão, sendo possível adicionar memória de longo prazo com pequenas modificações.

    AgentCore Gateway: Expõe APIs como ferramentas compatíveis com Model Context Protocol (MCP) para seus agentes.

    AgentCore Code Interpreter: Executa código Python de forma segura em ambientes isolados de sandbox.

    AgentCore Observability: Envia métricas e logs compatíveis com Open Telemetry (OTEL) para o Amazon CloudWatch e rastreamentos para o AWS X-Ray.

    O template inclui padrões tanto para Strands Agents quanto para LangGraph. Importante: o FAST e o AgentCore são agnósticos quanto ao framework de agentes, permitindo que você use o SDK de agentes que preferir. A infraestrutura é definida em AWS CDK, garantindo implantações repetíveis e consistentes.

    Design preparado para desenvolvimento assistido por IA

    O FAST foi concebido com documentação extensiva já integrada. O repositório inclui:

    • Documentos de direcionamento — regras e convenções que assistentes de código seguem automaticamente
    • Guias de funcionalidades — documentação detalhada sobre gateway, memória, streaming e outras integrações
    • READMEs espalhados pelo código — contexto para cada componente

    Quando você pede a um assistente de código que faça alterações, ele consegue ler esses documentos e seguir os padrões documentados. Esta abordagem funciona com diversos assistentes, incluindo Kiro, Cline, Claude Code, Cursor e outros. A documentação é independente de sistema específico.

    Vale reforçar: o desenvolvimento assistido por IA é opcional. A mesma documentação que guia assistentes de código é igualmente útil para desenvolvedores que preferem escrever o código manualmente.

    Preparando o ambiente

    Antes de implantar o FAST, certifique-se de ter instalado:

    O usuário de AWS Identity and Access Management (IAM) que você utilizar deve ter permissões para realizar as chamadas necessárias de serviço AWS e gerenciar os recursos mencionados. Ao conceder permissões, siga o princípio do menor privilégio.

    Implantando o template passo a passo

    Passo 1: Clonar o repositório

    Comece clonando o repositório usando os comandos abaixo:

    git clone https://github.com/awslabs/fullstack-solution-template-for-agentcore.git
    cd fullstack-solution-template-for-agentcore

    Passo 2: Configurar a implantação

    Edite o arquivo infra-cdk/config.yaml para personalizar sua implantação:

    stack_name_base: your-project-name
    admin_user_email: admin@example.com # Opcional: cria usuário automaticamente e envia credenciais
    backend:
      pattern: strands-single-agent # Disponível: strands-single-agent, langgraph-single-agent
      deployment_type: docker # Disponível: docker, zip

    Passo 3: Implantar o backend com CDK

    Execute os comandos para implantar o backend:

    cd infra-cdk
    npm install
    cdk bootstrap # Necessário apenas uma vez por conta/região
    cdk deploy

    Este processo cria o User Pool do Cognito, constrói e envia o container do agente para o Amazon Elastic Container Registry (Amazon ECR), cria o AgentCore Runtime e configura a distribuição CloudFront. A implantação leva aproximadamente 5 a 10 minutos.

    Passo 4: Implantar o frontend

    Use o script para implantar a interface:

    cd ..
    python scripts/deploy-frontend.py

    O script gera a configuração de autenticação a partir dos outputs da stack CDK, instala dependências, constrói a aplicação React e implanta no AWS Amplify Hosting. Ao finalizar, ele exibe a URL da aplicação:

    ✓ Deployment completed successfully!
    Console: https://console.aws.amazon.com/amplify/apps
    App URL: https://main.d123490abcdef.amplifyapp.com

    Passo 5: Criar um usuário no Cognito

    Se você informou um admin_user_email na configuração, receberá um email com credenciais temporárias. Caso contrário, crie o usuário manualmente:

    • Abra o console do Amazon Cognito
    • Localize seu User Pool (nomeado como {stack_name_base}-user-pool)
    • Navegue até Usuários e selecione Criar usuário
    • Digite um endereço de email e uma senha temporária
    • Marque a opção de verificar o email
    • Escolha Criar usuário

    Passo 6: Acessar e testar a aplicação

    Acesse a URL do Amplify Hosting (exibida no terminal após a implantação do frontend) no seu navegador. Faça login com suas credenciais do Cognito e altere sua senha temporária quando solicitado.

    A aplicação de exemplo FAST é uma interface simples de chat multi-turno. A interface mantém-se minimalista propositalmente — ela foi construída para ser substituída por seu próprio frontend ou integrada a uma aplicação existente.

    O agente de linha de base inclui duas ferramentas para demonstrar a arquitetura:

    • Ferramenta de análise de texto: Uma ferramenta baseada em AWS Lambda por trás do AgentCore Gateway que conta palavras e analisa frequência de letras. Demonstra o padrão de integração com Gateway.
    • Code Interpreter: Integração direta com o AgentCore Code Interpreter para execução Python segura em sandbox isolado.

    Teste com essas consultas de exemplo para verificar se as ferramentas funcionam:

    • “Analise o texto: The quick brown fox jumps over the lazy dog” — o agente deve retornar contagem de palavras e análise de frequência de letras
    • “Calcule os primeiros 20 números de Fibonacci” — observe o agente escrever e executar código Python em tempo real

    Lembre-se: a interface e as ferramentas fornecidas servem como ponto de partida, não como limitações. Você deve substituí-las conforme suas necessidades.

    Personalizando a aplicação para seus requisitos

    Alterando o padrão do agente

    O template inclui dois padrões de agentes no diretório patterns/:

    • strands-single-agent — agente conversacional básico usando framework Strands com integração de ferramentas MCP
    • langgraph-single-agent — agente conversacional básico usando LangGraph com integração de ferramentas MCP

    Para trocar de padrão, atualize backend.pattern no arquivo infra-cdk/config.yaml e reimplante com cdk deploy.

    Para criar seu próprio padrão, adicione um novo diretório sob patterns/ com sua implementação de agente, um arquivo requirements.txt e um Dockerfile. Atualize a configuração para apontar para seu novo padrão.

    Adicionando novas ferramentas via Gateway

    O AgentCore Gateway roteia chamadas de ferramentas para uma função AWS Lambda. Para adicionar uma nova ferramenta:

    • Crie uma função Lambda que implemente a lógica de sua ferramenta
    • Defina o esquema da ferramenta (nome, descrição e parâmetros de entrada) na stack CDK
    • Adicione a função Lambda como destino do AgentCore Gateway
    • Reimplante com cdk deploy

    O agente descobre ferramentas automaticamente a partir do Gateway através de MCP.

    Usando o Code Interpreter

    O Code Interpreter já está integrado no agente de linha de base, fornecendo execução Python segura em ambientes isolados de sandbox com persistência de sessão. Usuários podem solicitar ao agente que execute cálculos, gere dados ou execute código Python arbitrário.

    Modificando o frontend

    O frontend é uma aplicação React padrão no diretório frontend/. Assistentes de código como Kiro são hábeis em modificar frontends React. Descreva as mudanças que você deseja e deixe o assistente implementá-las. Após fazer alterações, reimplante com:

    python scripts/deploy-frontend.py

    Como o FAST utiliza AWS Amplify Hosting, você tem a opção de integrar com um sistema de controle de versão suportado para aproveitar os recursos nativos de integração e entrega contínua (CI/CD) do Amplify Hosting, que pode substituir o script deploy-frontend.py fornecido.

    Além do chat: outros casos de uso

    A aplicação de linha de base se concentra em interface de chat, mas o FAST suporta muitos casos de uso com agentes. Por exemplo, um agente de análise de documentos poderia adicionar um componente de envio de arquivos ao frontend, uma ferramenta Lambda que extrai texto de PDFs, e lógica de agente que resume os achados. Ou um agente de automação de fluxo poderia monitorar canais Slack e criar tickets Jira automaticamente a partir de solicitações de suporte.

    A mesma arquitetura se aplica — você apenas substitui os componentes. Essas personalizações funcionam dentro da arquitetura padrão do FAST.

    Flexibilidade: substituindo componentes principais

    A arquitetura foi projetada deliberadamente para ser modular, permitindo substituir componentes conforme seus requisitos evoluem:

    • Provedor de identidade: Substitua o Amazon Cognito por Okta, Microsoft Entra ID, Auth0 ou seu sistema OAuth 2.0 compatível existente
    • Framework frontend: Troque o frontend React por Vue, Angular, ou integre o backend do agente a uma aplicação existente
    • Hospedagem: Mude do AWS Amplify Hosting para Vercel, Netlify, uma distribuição CloudFront auto-gerenciada, ou sua solução preferida
    • Framework de agente: Use Strands Agents, LangGraph, CrewAI ou até SDKs de agentes em outras linguagens como TypeScript ou Java

    A infraestrutura modular em CDK e a arquitetura desacoplada tornam direto adaptar o template às suas necessidades específicas.

    Limpando recursos

    Para remover os recursos criados pelo FAST, execute:

    cd infra-cdk
    cdk destroy --force

    Este comando deleta recursos AWS incluindo buckets do Amazon Simple Storage Service (Amazon S3) e imagens do Amazon Elastic Container Registry (Amazon ECR). Se deixar recursos em execução, você pode incorrer em cobranças. Note que o Amazon Bedrock AgentCore é faturado por uso.

    Próximos passos

    O FAST ajuda a reduzir o tempo para construir e implantar uma aplicação com agentes para menos de 30 minutos. Você obtém autenticação segura, um frontend funcional e capacidades integradas do AgentCore — Memória, Gateway, Code Interpreter e Observabilidade — sem precisar escrever infraestrutura do zero.

    A aplicação de chat de linha de base e as ferramentas de exemplo são pontos de partida, não limitações. Você pode substituir sua própria lógica de agente, conectar suas ferramentas, modificar o frontend, ou até substituir componentes principais como o provedor de identidade ou a solução de hospedagem. A arquitetura modular se adapta aos seus requisitos.

    Para começar, acesse o repositório, clone-o, implante o FAST na sua conta AWS e tenha uma aplicação com agentes funcionando em menos de 30 minutos. Depois, customize e coloque em produção algo real.

    Para assistência especializada, a AWS Generative AI Innovation Center, AWS Professional Services e AWS Partners estão disponíveis para ajudar.

    Fonte

    Accelerate agentic application development with a full-stack starter template for Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/accelerate-agentic-application-development-with-a-full-stack-starter-template-for-amazon-bedrock-agentcore/)

  • ECS Managed Instances agora disponível na AWS European Sovereign Cloud

    ECS Managed Instances chega à AWS European Sovereign Cloud

    A AWS anunciou a disponibilidade do Amazon ECS Managed Instances na AWS European Sovereign Cloud. Trata-se de uma opção de computação totalmente gerenciada que elimina a necessidade de gerenciar infraestrutura, mantendo acesso completo às capacidades do Amazon EC2.

    Ao transferir as operações de infraestrutura para a AWS, as organizações conseguem manter o desempenho desejado das aplicações com a simplicidade necessária, além de reduzir o custo total de propriedade. A solução dimensiona automaticamente instâncias EC2 para corresponder aos requisitos da carga de trabalho e otimiza continuamente o posicionamento das tarefas para minimizar custos operacionais.

    Capacidades principais do serviço

    Segurança e manutenção automática

    O ECS Managed Instances fortalece a postura de segurança através de correções de segurança regulares iniciadas a cada 14 dias. Isso elimina a responsabilidade manual de gerenciar patches, reduzindo vulnerabilidades e mantendo a infraestrutura atualizada.

    Provisioning simplificado

    Os usuários precisam apenas definir os requisitos das tarefas — número de vCPUs, tamanho de memória e arquitetura de CPU — e o Amazon ECS provisiona, configura e opera automaticamente as instâncias EC2 mais apropriadas dentro da conta AWS utilizando acesso controlado pela AWS.

    Flexibilidade de tipos de instância

    É possível especificar tipos de instância desejados na configuração do Capacity Provider do ECS Managed Instances, incluindo opções com aceleração GPU, otimização para rede e performance em modo rajada. Isso oferece a flexibilidade de executar cargas de trabalho nas famílias de instâncias preferidas.

    Como começar

    Para iniciar com o ECS Managed Instances, é possível utilizar o AWS Console, o Amazon ECS MCP Server ou ferramentas de infraestrutura como código para ativar o recurso em um novo cluster Amazon ECS ou em um existente.

    É importante observar que os usuários serão cobrados pelo gerenciamento da computação provisionada, além dos custos regulares do Amazon EC2.

    Para obter mais informações sobre o ECS Managed Instances, consulte a página de recursos, a documentação e o blog de lançamento da AWS News.

    Fonte

    Amazon ECS Managed Instances now available in AWS European Sovereign Cloud (https://aws.amazon.com/about-aws/whats-new/2026/02/ecs-mi-european-sovereign-cloud)

  • AWS Config expande suporte para 30 novos tipos de recursos

    Ampliação do suporte a tipos de recursos

    A AWS anunciou uma expansão significativa no AWS Config, incorporando suporte a 30 tipos adicionais de recursos em seus principais serviços. Essa ampliação abrange serviços importantes como Amazon EKS (Elastic Kubernetes Service), Amazon Q e AWS IoT, proporcionando aos usuários uma cobertura muito mais abrangente de seus ambientes em nuvem.

    A inclusão desses novos tipos de recursos permite que organizações descubram, avaliem, auditem e remediem uma faixa significativamente mais ampla de recursos. Para quem já possui a gravação habilitada para todos os tipos de recursos, a novidade funciona de forma automática — o AWS Config passa a rastrear esses novos tipos imediatamente, sem necessidade de configurações adicionais.

    Recursos monitoráveis em novos contextos

    Os novos tipos de recursos agora estão disponíveis não apenas no AWS Config, mas também integrados com Config rules (regras de configuração) e Config aggregators (agregadores de configuração). Isso significa que as estratégias de conformidade e auditoria ganham ferramentas ainda mais robustas para manter seus ambientes sob controle.

    Cobertura geográfica

    Você pode agora utilizar o AWS Config para monitorar os seguintes tipos de recursos em todas as regiões AWS onde esses recursos estejam disponíveis.

    Tipos de recursos adicionados

    A lista de novos tipos de recursos suportados inclui capacidades em múltiplos domínios:

    • AWS::ApplicationSignals::ServiceLevelObjective
    • AWS::IoT::SoftwarePackage
    • AWS::ARCZonalShift::AutoshiftObserverNotificationStatus
    • AWS::IoT::TopicRule
    • AWS::B2BI::Transformer
    • AWS::IoTWireless::Destination
    • AWS::CE::CostCategory
    • AWS::IoTWireless::DeviceProfile
    • AWS::CleanRooms::ConfiguredTable
    • AWS::IoTWireless::NetworkAnalyzerConfiguration
    • AWS::CleanRooms::Membership
    • AWS::IoTWireless::TaskDefinition
    • AWS::CodeArtifact::PackageGroup
    • AWS::IoTWireless::WirelessGateway
    • AWS::Connect::Prompt
    • AWS::Kinesis::ResourcePolicy
    • AWS::EKS::Nodegroup
    • AWS::PCAConnectorSCEP::Connector
    • AWS::GameLift::MatchmakingRuleSet
    • AWS::QBusiness::Application
    • AWS::GameLift::Script
    • AWS::QuickSight::DataSet
    • AWS::Glue::Crawler
    • AWS::QuickSight::Dashboard
    • AWS::InternetMonitor::Monitor
    • AWS::Route53::DNSSEC
    • AWS::IoT::BillingGroup
    • AWS::SSM::PatchBaseline
    • AWS::IoT::ResourceSpecificLogging
    • AWS::Transfer::User

    Implicações para governança em nuvem

    Essa expansão reflete o compromisso contínuo da AWS com melhorias em visibilidade e controle. À medida que ambientes em nuvem crescem em complexidade — especialmente com adoção de contêineres via EKS, soluções de negócios via Amazon Q e conectividade via IoT — a necessidade de rastreabilidade e auditoria completa se torna crítica para conformidade e segurança.

    Fonte

    AWS Config now supports 30 new resource types (https://aws.amazon.com/about-aws/whats-new/2026/02/aws-config-new-resource-types)

  • Saídas estruturadas no Amazon Bedrock: respostas de IA em conformidade com esquema

    Uma mudança fundamental na geração de JSON estruturado

    A AWS anunciou uma novidade no Amazon Bedrock que redefine como os desenvolvedores trabalham com respostas estruturadas de modelos de inteligência artificial. A capacidade de saídas estruturadas representa um avanço significativo: pela primeira vez, é possível garantir que as respostas JSON dos modelos de fundação estejam sempre em conformidade com um esquema especificado, através de decodificação restrita.

    Essa transformação muda fundamentalmente a arquitetura dos aplicativos. Em vez de criar elaborados sistemas de validação, tratamento de erros e lógica de reprocessamento quando a IA retorna dados mal formatados, os desenvolvedores agora podem construir com confiança, sabendo que cada resposta respeitará exatamente o formato esperado.

    Os casos de uso potenciais são diversos: pipelines de extração de dados sem necessidade de validação, sistemas de agentes de IA que chamam funções externas com segurança, e arquiteturas de aplicação simplificadas que dispensam lógica de retry. Um notebook Jupyter companion fornece exemplos práticos para todas as funcionalidades abordadas.

    Os desafios tradicionais com geração de JSON

    Historicamente, obter dados estruturados de modelos de linguagem era um processo frágil. Os desenvolvedores precisavam elaborar prompts detalhados, esperar pelo melhor resultado e construir sistemas complexos de tratamento de erros. Mesmo com prompts cuidadosamente preparados, problemas recorrentes surgem:

    • Falhas de análise: JSON sintaticamente inválido que quebra chamadas de json.loads()
    • Campos ausentes: Pontos de dados necessários não retornam nas respostas
    • Incompatibilidades de tipo: Strings onde inteiros são esperados, quebra processamento downstream
    • Violações de esquema: Respostas que tecnicamente são JSON válido, mas não correspondem ao modelo de dados esperado

    Em sistemas em produção, esses problemas se multiplicam. Uma única resposta malformada pode atravessar um pipeline inteiro, exigindo reprocessamentos que aumentam latência e custos. Para fluxos de trabalho com agentes, parâmetros inválidos podem quebrar completamente chamadas de função.

    Considere um exemplo concreto: um sistema de reservas que necessita do campo passageiros: int. Sem imposição de esquema, o modelo pode retornar passageiros: "dois" ou passageiros: "2"—ambos são JSON sintaticamente válido, mas semanticamente incorretos para a assinatura da função.

    Como as saídas estruturadas transformam a situação

    As saídas estruturadas no Amazon Bedrock não representam uma melhoria incremental—trata-se de um deslocamento fundamental de formatação probabilística para determinística. Através de decodificação restrita, o Bedrock força as respostas do modelo a estarem em conformidade com o esquema JSON especificado.

    Dois mecanismos complementares estão disponíveis:

    • Formato de saída JSON Schema: Controla o formato da resposta do modelo. Ideal para extração de dados, geração de relatórios e respostas prontas para APIs.
    • Uso de ferramenta restrita: Valida parâmetros de ferramentas. Essencial para fluxos de trabalho com agentes, chamadas de função e automação em múltiplas etapas.

    Essas funcionalidades podem ser usadas independentemente ou em conjunto, oferecendo controle preciso sobre tanto o que o modelo retorna quanto como chama suas funções.

    Os benefícios entregues são significativos:

    • Sempre válido: Sem erros de JSON.parse() ou exceções de análise
    • Type-safe: Tipos de campos são impostos e campos obrigatórios sempre estão presentes
    • Confiável: Sem necessidade de reprocessamentos por violações de esquema
    • Pronto para produção: Deploy com confiança em escala empresarial

    O funcionamento técnico das saídas estruturadas

    As saídas estruturadas utilizam amostragem restrita com artefatos de gramática compilados. Quando uma requisição é feita, o Bedrock executa as seguintes etapas:

    • Validação de esquema: O Amazon Bedrock valida o esquema JSON contra um subconjunto suportado do JSON Schema Draft 2020-12
    • Compilação de gramática: Para esquemas novos, o Bedrock compila uma gramática (a primeira requisição pode levar mais tempo)
    • Cache: Gramáticas compiladas são mantidas em cache por 24 horas, acelerando requisições subsequentes
    • Geração restrita: O modelo gera tokens que produzem JSON válido correspondendo ao esquema

    Considerações de desempenho

    A latência inicial é um fator importante a considerar. A compilação inicial pode adicionar latência para esquemas novos. Entretanto, requisições subsequentes com esquemas idênticos têm overhead mínimo, pois a gramática compilada permanece em cache.

    O escopo do cache é por conta, durando 24 horas a partir do primeiro acesso. Alterar a estrutura do esquema JSON ou do esquema de entrada de uma ferramenta invalida o cache, mas modificar apenas nomes ou campos de descrição não.

    Começando com saídas estruturadas

    O seguinte exemplo demonstra saídas estruturadas usando a Converse API:

    import boto3
    import json
    
    # Initialize the Bedrock Runtime client
    bedrock_runtime = boto3.client(
        service_name='bedrock-runtime',
        region_name='us-east-1'  # Choose your preferred region
    )
    
    # Define your JSON schema
    extraction_schema = {
        "type": "object",
        "properties": {
            "name": {"type": "string", "description": "Customer name"},
            "email": {"type": "string", "description": "Customer email address"},
            "plan_interest": {"type": "string", "description": "Product plan of interest"},
            "demo_requested": {"type": "boolean", "description": "Whether a demo was requested"}
        },
        "required": ["name", "email", "plan_interest", "demo_requested"],
        "additionalProperties": False
    }
    
    # Make the request with structured outputs
    response = bedrock_runtime.converse(
        modelId="us.anthropic.claude-opus-4-5-20251101-v1:0",
        messages=[
            {
                "role": "user",
                "content": [
                    {
                        "text": "Extract the key information from this email: John Smith (john@example.com) is interested in our Enterprise plan and wants to schedule a demo for next Tuesday at 2pm."
                    }
                ]
            }
        ],
        inferenceConfig={
            "maxTokens": 1024
        },
        outputConfig={
            "textFormat": {
                "type": "json_schema",
                "structure": {
                    "jsonSchema": {
                        "schema": json.dumps(extraction_schema),
                        "name": "lead_extraction",
                        "description": "Extract lead information from customer emails"
                    }
                }
            }
        }
    )
    
    # Parse the schema-compliant JSON response
    result = json.loads(response["output"]["message"]["content"][0]["text"])
    print(json.dumps(result, indent=2))

    A saída obtida está em conformidade total com o esquema—sem validação adicional necessária:

    {
      "name": "John Smith",
      "email": "john@example.com",
      "plan_interest": "Enterprise",
      "demo_requested": true
    }

    Requisitos e melhores práticas

    Para utilizar saídas estruturadas efetivamente, algumas orientações devem ser seguidas:

    Configuração de esquema obrigatória

    Configure additionalProperties: false em todos os objetos. Essa é uma configuração necessária para que saídas estruturadas funcionem. Sem ela, o esquema não será aceito:

    {
        "type": "object",
        "properties": {
            "name": {"type": "string"}
        },
        "required": ["name"],
        "additionalProperties": false
    }

    Nomes e descrições descritivas

    Use nomes de propriedade e descrições claros. Os modelos utilizam nomes de propriedades e descrições para compreender quais dados extrair. Nomes descritivos como customer_email têm melhor desempenho do que nomes genéricos como field1.

    Enumerações para valores restritos

    Quando um campo possui um conjunto limitado de valores válidos, use enum para restringir opções. Isso melhora a precisão e garante valores válidos.

    Incrementalismo na construção

    Comece com os campos mínimos necessários e adicione complexidade gradualmente. Esquemas básicos compilam mais rapidamente e são mais fáceis de manter.

    Reutilização de esquemas

    Estruture sua aplicação para reutilizar esquemas entre requisições. O cache de gramática de 24 horas melhora significativamente o desempenho para consultas repetidas.

    Verificação de stopReason

    Verifique stopReason em cada resposta. Dois cenários podem produzir respostas não conformes: recusas (quando o modelo declina por razões de segurança) e limites de token (quando max_tokens é atingido antes da conclusão). Trate ambos os casos no seu código.

    Teste com dados realistas

    Valide seus esquemas contra inputs representativos de produção. Casos extremos em dados reais frequentemente revelam problemas de design de esquema.

    Recursos JSON Schema suportados

    Os seguintes recursos são suportados:

    • Todos os tipos básicos: object, array, string, integer, number, boolean, null
    • enum (strings, números, booleanos ou nulls apenas)
    • const, anyOf, allOf (com limitações)
    • $ref, $def e definitions (apenas referências internas)
    • Formatos de string: date-time, time, date, duration, email, hostname, uri, ipv4, ipv6, uuid
    • Array minItems (apenas valores 0 e 1)

    Não suportados: Esquemas recursivos, referências externas de $ref, restrições numéricas (minimum, maximum, multipleOf), restrições de string (minLength, maxLength), additionalProperties definido como qualquer valor diferente de false.

    Uso restrito de ferramentas para fluxos de trabalho com agentes

    Ao construir aplicações onde modelos chamam ferramentas, configure strict: true na definição da ferramenta para restringir parâmetros de ferramentas a corresponderem exatamente com seu esquema de entrada:

    import boto3
    import json
    
    bedrock_runtime = boto3.client('bedrock-runtime', region_name='us-east-1')
    
    response = bedrock_runtime.converse(
        modelId="us.anthropic.claude-opus-4-5-20251101-v1:0",
        messages=[
            {
                "role": "user",
                "content": [{"text": "What's the weather like in San Francisco?"}]
            }
        ],
        inferenceConfig={"maxTokens": 1024},
        toolConfig={
            "tools": [
                {
                    "toolSpec": {
                        "name": "get_weather",
                        "description": "Get the current weather for a specified location",
                        "strict": True,  # Enable strict mode
                        "inputSchema": {
                            "json": {
                                "type": "object",
                                "properties": {
                                    "location": {
                                        "type": "string",
                                        "description": "The city and state, e.g., San Francisco, CA"
                                    },
                                    "unit": {
                                        "type": "string",
                                        "enum": ["celsius", "fahrenheit"],
                                        "description": "Temperature unit"
                                    }
                                },
                                "required": ["location", "unit"],
                                "additionalProperties": False
                            }
                        }
                    }
                }
            ]
        }
    )
    
    # Tool inputs conform to the schema
    for content_block in response["output"]["message"]["content"]:
        if "toolUse" in content_block:
            tool_input = content_block["toolUse"]["input"]
            print(f"Tool: {content_block['toolUse']['name']}")
            print(f"Input: {json.dumps(tool_input, indent=2)}")

    Com strict: true, as saídas estruturadas garantem que:

    • O campo location é sempre uma string
    • O campo unit é sempre celsius ou fahrenheit
    • Nenhum campo inesperado aparece na entrada

    Aplicações práticas em diversos setores

    Os exemplos e notebooks demonstram casos de uso que atravessam múltiplas indústrias:

    • Serviços financeiros: Extrair dados estruturados de relatórios de earnings, aplicações de crédito e documentos de conformidade. Com saídas estruturadas, todos os campos obrigatórios estão presentes e corretamente tipados para processamento downstream.
    • Healthcare: Analisar notas clínicas em registros estruturados conformes com esquema. Extrair informações de pacientes, diagnósticos e planos de tratamento em JSON validado para integração com sistemas EHR.
    • Ecommerce: Construir pipelines confiáveis de enriquecimento de catálogo de produtos. Extrair especificações, categorias e atributos de descrições de produtos com resultados consistentes e confiáveis.
    • Legal: Analisar contratos e extrair termos-chave, partes, datas e obrigações em formatos estruturados adequados para sistemas de gerenciamento de contratos.
    • Atendimento ao cliente: Construir sistemas inteligentes de roteamento de tickets e resposta, onde intents extraídos, sentimentos e entidades correspondem ao modelo de dados da aplicação.

    Escolhendo a abordagem correta

    Os testes revelaram padrões claros sobre quando usar cada funcionalidade:

    Use JSON Schema output format quando:

    • Você precisa da resposta do modelo em uma estrutura específica
    • Construindo pipelines de extração de dados
    • Gerando respostas prontas para API
    • Criando relatórios ou resumos estruturados

    Use strict tool use quando:

    • Construindo sistemas de agentes que chamam funções externas
    • Implementando fluxos de trabalho multi-etapas com cadeias de ferramentas
    • Exigindo tipos de parâmetro validados para chamadas de função
    • Conectando IA a bancos de dados, APIs ou serviços externos

    Use ambos em conjunto quando:

    • Construindo agentes complexos que precisam de chamadas de ferramenta validadas e respostas finais estruturadas
    • Criando sistemas onde resultados de ferramentas intermediárias alimentam saídas estruturadas
    • Implementando fluxos de trabalho empresariais exigindo conformidade de esquema de ponta a ponta

    Comparação de APIs: Converse versus InvokeModel

    Tanto a Converse API quanto a InvokeModel API suportam saídas estruturadas, com formatos de parâmetro ligeiramente diferentes:

    Aspecto Converse API InvokeModel (Anthropic Claude) InvokeModel (modelos open-weight)
    Localização do esquema outputConfig.textFormat output_config.format response_format
    Flag strict de ferramenta toolSpec.strict tools[].strict tools[].function.strict
    Formato de esquema String JSON em jsonSchema.schema Objeto JSON em schema Objeto JSON em json_schema.schema
    Melhor para Fluxos de trabalho conversacionais Inferência single-turn (Claude) Inferência single-turn (open-weight)

    Nota: A InvokeModel API utiliza nomes de campos de requisição diferentes dependendo do tipo de modelo. Para modelos Anthropic Claude, use output_config.format para saídas JSON schema. Para modelos open-weight, use response_format em seu lugar.

    Escolha a Converse API para conversas multi-turn e a InvokeModel API quando você necessita acesso direto ao modelo com formatos de requisição específicos do provedor.

    Modelos suportados e disponibilidade

    Saídas estruturadas está geralmente disponível em todas as regiões comerciais da AWS para provedores de modelo Amazon Bedrock selecionados:

    • Anthropic
    • DeepSeek
    • Google
    • MiniMax
    • Mistral AI
    • Moonshot AI
    • NVIDIA
    • OpenAI
    • Qwen

    A funcionalidade funciona perfeitamente com:

    • Inferência entre regiões: Use saídas estruturadas entre regiões da AWS sem configuração adicional
    • Inferência em lote: Processe grandes volumes com saídas conformes com esquema
    • Streaming: Transmita respostas estruturadas com ConverseStream ou InvokeModelWithResponseStream

    Conclusão

    A capacidade de saídas estruturadas no Amazon Bedrock reduz significativamente a incerteza da geração de JSON por IA através de respostas validadas e conformes com esquema. Utilizando formato de saída JSON Schema e uso restrito de ferramentas, os desenvolvedores podem construir pipelines confiáveis de extração de dados, fluxos de trabalho robustos com agentes e aplicações de IA prontas para produção—sem lógica personalizada de análise ou validação.

    Seja extraindo dados de documentos, construindo automação inteligente ou criando APIs alimentadas por IA, as saídas estruturadas entregam a confiabilidade que suas aplicações exigem.

    Saídas estruturadas está agora geralmente disponível no Amazon Bedrock. Para usar saídas estruturadas com as APIs Converse, atualize para o AWS SDK mais recente. Para saber mais, consulte a documentação do Amazon Bedrock e explore o notebook de exemplo.

    Fonte

    Structured outputs on Amazon Bedrock: Schema-compliant AI responses (https://aws.amazon.com/blogs/machine-learning/structured-outputs-on-amazon-bedrock-schema-compliant-ai-responses/)

  • Amazon WorkSpaces Secure Browser agora suporta domínios personalizados

    Domínios personalizados no WorkSpaces Secure Browser

    A AWS lançou um novo recurso para o Amazon WorkSpaces Secure Browser que permite configurar domínios personalizados nos portais de acesso. Ao invés de usar a URL padrão fornecida pela plataforma, as organizações agora podem rotear o acesso através de seu próprio domínio, criando uma experiência muito mais alinhada com a identidade corporativa.

    Como funciona a configuração

    O processo é relativamente simples para administradores. Basta adicionar o domínio personalizado diretamente no painel do WorkSpaces Secure Browser e configurar um proxy reverso (como o Amazon CloudFront, por exemplo). Uma vez em operação, o tráfego é direcionado através do proxy reverso até o endpoint do portal. Após a autenticação e autorização bem-sucedida, o WorkSpaces Secure Browser redireciona automaticamente os usuários para o domínio personalizado configurado.

    Autenticação e integração com provedores de identidade

    O serviço oferece flexibilidade quanto à autenticação. É possível usar o AWS Identity Center ou integrar com seu próprio Provedor de Identidade (IdP). O suporte inclui tanto fluxos iniciados pelo IdP quanto pelo provedor de serviço, oferecendo às empresas a liberdade de escolher o modelo de autenticação que melhor se adequa à sua infraestrutura existente.

    Disponibilidade e custo

    Este recurso está disponível sem nenhum custo adicional em 10 regiões AWS: US East (N. Virginia), US West (Oregon), Canada (Central), Europe (Frankfurt, London, Ireland) e Asia Pacific (Tokyo, Mumbai, Sydney, Singapore). O WorkSpaces Secure Browser continua operando com modelo de pagamento conforme o uso.

    Próximos passos

    Para começar a usar domínios personalizados, acesse o console do Amazon WorkSpaces Secure Browser e configure seu domínio no portal. Para detalhes técnicos completos sobre a implementação, consulte a documentação sobre domínios personalizados do WorkSpaces Secure Browser. Você também pode conferir informações sobre o modelo de preço do serviço.

    Fonte

    Amazon WorkSpaces Secure Browser now supports custom domain (https://aws.amazon.com/about-aws/whats-new/2026/02/amazon-workspaces-secure-browser-custom-domains/)

  • Amazon Bedrock AgentCore Browser agora suporta perfis de navegação

    O que são perfis de navegação no Bedrock AgentCore Browser

    A AWS anunciou um novo recurso para o Amazon Bedrock AgentCore Browser: o suporte a perfis de navegação. Essa funcionalidade resolve um desafio importante em automações de grande escala, permitindo que estados de autenticação sejam reutilizados em múltiplas sessões de navegador sem que seja necessário realizar login novamente.

    Para clientes corporativos que precisam executar centenas ou milhares de sessões automatizadas de navegador diariamente, esse ganho é significativo. O tempo de configuração de sessão foi reduzido de minutos para dezenas de segundos, representando uma melhora substancial em eficiência operacional.

    Como funcionam os perfis de navegação

    Os perfis de navegação funcionam através da persistência de dados do navegador. Quando você cria um perfil, ele armazena informações essenciais como cookies e local storage (armazenamento local) de múltiplas sessões.

    O fluxo é simples: você autentica em um website uma única vez e salva a sessão em um perfil de navegação. Quando inicia uma nova sessão utilizando esse perfil salvo, seu estado de autenticação é preservado — você permanece conectado sem necessidade de inserir credenciais novamente. Dessa forma, agentes de automação conseguem executar tarefas em websites autenticados sem intervenção manual de login.

    Flexibilidade e processamento paralelo

    O recurso oferece modos de sessão flexíveis que atendem tanto operações de leitura quanto operações persistentes. Uma vantagem importante é a capacidade de processamento paralelo: múltiplas sessões podem utilizar o mesmo perfil simultaneamente, viabilizando automações complexas e escaláveis.

    Disponibilidade regional

    O suporte a perfis de navegação está disponível em todos os 14 regiões da AWS onde o Amazon Bedrock AgentCore Browser funciona:

    • Regiões US: Virgínia, Ohio e Oregon
    • Regiões Ásia Pacífico: Mumbai, Singapura, Sydney, Tóquio e Seul
    • Regiões Europa: Frankfurt, Irlanda, Londres, Paris e Estocolmo
    • Canadá: região central

    Próximos passos

    Para aprofundar seu conhecimento sobre essa funcionalidade, você pode consultar a documentação sobre perfis de navegação no site oficial da AWS.

    Fonte

    Amazon Bedrock AgentCore Browser now supports browser profiles (https://aws.amazon.com/about-aws/whats-new/2026/02/amazon-bedrock-agentcore-browser-profiles)

  • Gerenciamento de Clusters Amazon SageMaker HyperPod com CLI e SDK

    Simplificação da Computação Distribuída para IA

    O treinamento e implementação de grandes modelos de inteligência artificial exigem capacidades avançadas de computação distribuída. No entanto, gerenciar esses sistemas complexos não deveria ser uma tarefa complicada para cientistas de dados e profissionais de aprendizado de máquina.

    A Amazon SageMaker HyperPod com orquestração Amazon Elastic Kubernetes Service (Amazon EKS) oferece uma abordagem diferente. O pacote de ferramentas — composto por interface de linha de comando (CLI) e kit de desenvolvimento de software (SDK) — permite que usuários gerenciem infraestrutura de cluster e acessem capacidades de treinamento e inferência distribuídos de forma mais intuitiva, abstraindo a complexidade subjacente dos sistemas distribuídos.

    Arquitetura em Camadas para Simplicidade

    A CLI e o SDK seguem uma arquitetura multi-camada compartilhada. Ambas servem como pontos de entrada para o usuário e estão construídas sobre componentes comuns, proporcionando comportamento consistente nas diferentes interfaces.

    Para automação de infraestrutura, o SDK orquestra o gerenciamento do ciclo de vida do cluster através de uma combinação de provisionamento de stacks AWS CloudFormation e interações diretas com APIs da AWS. Cargas de trabalho de treinamento e inferência, além de ambientes de desenvolvimento integrados (IDEs), são expressas como Definições de Recurso Personalizado do Kubernetes (CRDs), que o SDK gerencia através da API do Kubernetes.

    Instalação e Preparação

    Pré-requisitos

    Para utilizar as ferramentas, você precisará de:

    Instalação da CLI HyperPod

    A instalação é direta. Execute o seguinte comando a partir do seu ambiente local:

    pip install sagemaker-hyperpod

    Este comando configura as ferramentas necessárias para interagir com clusters SageMaker HyperPod. Para instalações existentes, certifique-se de que tem a versão mais recente do pacote (SageMaker HyperPod 3.5.0 ou posterior).

    Para verificar se a CLI foi instalada corretamente, execute:

    hyp

    A saída exibirá todas as opções e comandos disponíveis, incluindo instruções de uso. A CLI oferece uma gama completa de comandos para gerenciar o ciclo de vida do HyperPod — desde criação de clusters até criação de endpoints, execução de jobs, monitoramento e exclusão.

    Para informações detalhadas sobre uso da CLI e parâmetros disponíveis, consulte a documentação de referência da CLI.

    Criação e Gerenciamento de Clusters

    Inicializando uma Nova Configuração de Cluster

    A AWS oferece dois caminhos para criar clusters HyperPod: através do console de gerenciamento ou da CLI. O console fornece a experiência mais guiada, enquanto a CLI é ideal para usuários que preferem automação programática.

    Ambas as abordagens utilizam o mesmo modelo CloudFormation subjacente, disponível no repositório GitHub SageMaker HyperPod cluster setup. Para um passo a passo baseado em console, consulte o post sobre a nova experiência de criação de cluster.

    A criação via CLI segue um fluxo baseado em configuração. Primeiro, inicialize uma nova configuração de cluster:

    hyp init cluster-stack

    Isso cria um arquivo config.yaml onde você especifica a configuração do cluster, além de um arquivo README.md com informações sobre o fluxo de trabalho.

    Configuração do Cluster

    O arquivo config.yaml contém variáveis cruciais como:

    resource_name_prefix: hyp-eks-stack
    hyperpod_cluster_name: hyperpod-cluster
    kubernetes_version: 1.31

    O parâmetro resource_name_prefix serve como identificador principal dos recursos criados. Cada implantação deve usar um prefixo único para evitar conflitos.

    Você pode editar a configuração diretamente ou usar comandos da CLI como:

    hyp configure --kubernetes-version 1.33

    Existem duas nuances importantes ao atualizar valores de configuração: underscores (_) em nomes de variáveis no arquivo se tornam hífens (-) nos comandos CLI. Variáveis contendo listas são configuradas como JSON nos comandos CLI.

    Validação e Envio

    Após realizar as alterações desejadas, valide o arquivo de configuração:

    hyp validate

    Se bem-sucedido, o comando confirmará que a configuração é válida. Em seguida, envie o stack de criação para CloudFormation:

    hyp create --region us-east-1

    O comando realiza validação e injeta valores do arquivo config.yaml no modelo. Os arquivos resolvidos são salvos em um subdiretório com timestamp, fornecendo um mecanismo leve de versionamento local. Se bem-sucedido, você receberá uma ID de stack do CloudFormation.

    Monitoramento da Criação

    Para listar stacks CloudFormation existentes:

    hyp list cluster-stack --region us-east-1

    Você pode filtrar por status usando a flag --status. Para visualizar detalhes de um stack específico:

    hyp describe cluster-stack <nome-do-stack> --region us-east-1

    Se algum dos stacks mostrar status como CREATE_FAILED ou ROLLBACK_*, abra a página CloudFormation no console para investigar. Falhas frequentemente relacionam-se a cotas de serviço insuficientes para o cluster, grupos de instâncias ou componentes de rede como VPCs ou gateways NAT. Consulte as quotas do SageMaker HyperPod para saber mais sobre requisitos.

    Conexão ao Cluster

    Após o stack completar sua criação com status CREATE_COMPLETE, configure a CLI e seu ambiente Kubernetes local para interagir com o cluster:

    hyp set-cluster-context --cluster-name <nome-cluster> --region us-east-1

    Este comando atualiza sua configuração Kubernetes local, permitindo usar tanto a CLI HyperPod quanto utilitários como kubectl para gerenciar recursos.

    Modificação de Clusters Existentes

    A CLI oferece capacidade de modificar grupos de instâncias e modo de recuperação de nós através do comando:

    hyp update cluster --cluster-name <nome> --region <região> --instance-groups '[{"instance_count": 2, "instance_group_name": "worker-nodes", "instance_type": "ml.m5.large"}]'

    Todos os campos são necessários para executar o comando de atualização, mesmo que você esteja modificando apenas um deles. A opção --node-recovery permite configurar o comportamento de recuperação de nós (Automática ou Nenhuma). Para mais informações, consulte a documentação sobre recuperação automática de nós.

    Exclusão de Clusters

    Para remover um cluster HyperPod:

    hyp delete cluster-stack <nome-do-stack> --region us-east-1

    Esta ação é irreversível. A CLI solicitará confirmação antes de proceder. Você pode usar a flag --retain-resources para especificar recursos que deseja manter durante o processo de exclusão.

    SDK Python para Controle Programático

    A AWS também inclui um SDK Python para acesso programático às funcionalidades descritas. O SDK Python é utilizado pelos comandos CLI e é instalado quando você instala o pacote sagemaker-hyperpod.

    A CLI é ideal para usuários que preferem uma experiência simplificada e interativa para tarefas comuns como criação de clusters, monitoramento de jobs e implantação de endpoints. É especialmente útil para prototipagem rápida, experimentação e automação de fluxos de trabalho através de scripts ou pipelines CI/CD.

    O SDK, por sua vez, oferece maior controle programático e flexibilidade, sendo a escolha preferida quando você precisa incorporar funcionalidades HyperPod diretamente em sua aplicação, integrar com outros serviços da AWS ou de terceiros, ou construir fluxos de trabalho customizados e complexos.

    O repositório GitHub da CLI SageMaker HyperPod mostra exemplos de como criação e gerenciamento de clusters podem ser implementados usando o SDK Python.

    Próximos Passos

    A CLI e o SDK do SageMaker HyperPod simplificam significativamente a criação e gerenciamento de clusters. Essas ferramentas fornecem valor através de:

    • Gerenciamento simplificado do ciclo de vida — Da configuração inicial às atualizações e limpeza do cluster, as ferramentas alinham-se com como equipes gerenciam ambientes de treinamento e inferência de longa duração
    • Controle declarativo — O SDK expõe o modelo de configuração subjacente, permitindo que equipes codifiquem especificações de cluster, grupos de instâncias e sistemas de armazenamento
    • Observabilidade integrada — Visibilidade dos stacks CloudFormation está disponível sem trocar de ferramentas, suportando iteração suave durante desenvolvimento e operação

    Se você deseja explorar como usar a CLI e o SDK para enviar jobs de treinamento e implantar modelos em seu novo cluster, consulte nosso post complementar sobre treinamento e implantação de modelos no SageMaker HyperPod.

    Fonte

    Manage Amazon SageMaker HyperPod clusters using the HyperPod CLI and SDK (https://aws.amazon.com/blogs/machine-learning/manage-amazon-sagemaker-hyperpod-clusters-using-the-hyperpod-cli-and-sdk/)

  • Avaliando Modelos de IA Generativa com Juiz LLM Baseado em Rubrica da Amazon Nova no SageMaker AI (Parte 2)

    O Juiz LLM Baseado em Rubrica: Transformando a Avaliação de Modelos de IA

    Em um artigo anterior, foi apresentado o recurso de juiz LLM da Amazon Nova no Amazon SageMaker AI, uma ferramenta especializada de avaliação que permite medir sistematicamente o desempenho relativo de sistemas de IA generativa. Agora, o SageMaker AI oferece uma versão aprimorada: um juiz LLM baseado em rubrica, alimentado pela Amazon Nova, que muda fundamentalmente como as equipes de desenvolvimento avaliam seus modelos.

    Diferentemente de abordagens tradicionais que usam as mesmas regras genéricas para todas as tarefas, este juiz gera automaticamente critérios de avaliação específicos para cada prompt individual. Isso permite que desenvolvedores de IA generativa e engenheiros de aprendizado de máquina criem automaticamente critérios precisos e contextualizados para seus modelos, eliminando a necessidade de escrever manualmente regras de avaliação para cada caso de uso.

    Entendendo o Juiz Baseado em Rubrica

    O que é uma Rubrica na Avaliação de IA?

    Uma rubrica é um guia de pontuação usado para avaliar desempenho. Historicamente, avaliar um modelo de IA exigia que humanos escrevessem manualmente um checklist de regras estáticas — por exemplo, “A resposta é educada?” ou “A resposta é concisa?” — que se aplicavam a todas as tarefas.

    O desafio dessa abordagem é que regras genéricas não se adaptam bem a diferentes contextos. Uma tarefa de escrita criativa requer critérios completamente diferentes de uma tarefa de codificação ou resumo de documentos legais. O juiz alimentado pela Amazon Nova resolve esse problema criando um checklist personalizado para cada interação específica.

    Quando um usuário envia um prompt específico — por exemplo, “Resuma este documento médico para um paciente” — o juiz analisa esse prompt e decide dinamicamente que características uma resposta ideal deveria ter. Ele gera automaticamente critérios como: “Usa linguagem simples, sem jargão médico?”, “Captura o diagnóstico corretamente?” e “O tom é empático?”. Em seguida, o juiz avalia a resposta do modelo em relação exatamente a esses critérios relevantes, em vez de aplicar regras genéricas.

    Exemplo Prático de Avaliação

    Considere a pergunta: “Os dinossauros realmente existiram?” Duas respostas muito diferentes poderiam ser avaliadas:

    Uma resposta oferece detalhes extensos com evidências (fósseis, pegadas, ninhos) e explica a distinção entre dinossauros extintos e aves como descendentes vivos. A outra fornece uma resposta mais concisa, cobrindo os pontos principais sem a mesma profundidade.

    O juiz baseado em rubrica analisa o contexto do prompt e gera critérios dinâmicos: precisão factual, clareza da explicação e estrutura apresentação. Ele então compara ambas as respostas contra esses critérios específicos, fornecendo uma justificativa detalhada de por que uma resposta é preferível à outra — neste caso, destacando que a primeira resposta oferece mais evidência e melhor estrutura organizacional.

    Imagem original — fonte: Aws

    Aplicações Empresariais do Juiz Baseado em Rubrica

    A avaliação dinâmica baseada em rubrica resolve desafios críticos em diversos cenários:

    Desenvolvimento de modelos e seleção de checkpoints: Equipes de desenvolvimento integram a avaliação do juiz Nova em pipelines de treinamento para avaliar automaticamente checkpoints. Pontuações por critério revelam quais capacidades melhoraram ou regrediram entre iterações, permitindo decisões informadas sobre ajustes de hiperparâmetros e curadoria de dados.

    Controle de qualidade de dados de treinamento: Equipes usam o juiz para filtrar conjuntos de dados de ajuste fino supervisionado, gerando pontuações baseadas em critérios de relevância e identificando exemplos de baixa qualidade. Para conjuntos de dados de preferência, as margens calculadas entre pares de respostas possibilitam estratégias de aprendizado curricular que filtram exemplos unilaterais demais.

    Análise profunda automatizada e identificação de causa raiz: Organizações que implementam IA generativa em escala podem usar a avaliação do juiz para análise sistemática de milhares de saídas de modelo sem revisão manual. Quando qualidade problemas aparecem, desenvolvedores examinam quais critérios específicos impulsionam as decisões de preferência, identificando fraquezas sistemáticas que informam melhorias direcionadas.

    Como Funciona a Geração Dinâmica de Rubrica

    O juiz baseado em rubrica da Amazon Nova recebe como entrada um trio: prompt, resposta_1 e resposta_2. Ele compara a qualidade das duas respostas e gera um rótulo de preferência, acompanhado de uma justificativa.

    Uma rubrica é um conjunto de critérios ponderados usados para avaliar as duas respostas. Cada critério possui um nome curto, descrição e peso. O treinamento do juiz o capacita a gerar critérios cujos pesos somam 1. A saída estruturada em YAML inclui os critérios gerados, pontuações por critério em escala de 1 a 5, e justificativas detalhadas. O resultado final inclui um de quatro rótulos de preferência: [[A>B]], [[B>A]], [[A=B]] ou [[A=B (ambas ruins)]].

    Cada pontuação de critério vem acompanhada de justificativa fundamentada em características observáveis das respostas, permitindo análise aprofundada e depuração do comportamento do modelo.

    Melhorias em Relação à Versão Anterior

    O juiz baseado em rubrica difere das versões anteriores em como apresenta resultados e quais informações fornece. A versão anterior retornava apenas rótulos de preferência simples. A versão baseada em rubrica gera saída estruturada em YAML contendo:

    • Uma rubrica específica do prompt com critérios e pesos de importância
    • Descrições em linguagem natural para cada critério
    • Pontuação em escala Likert (1–5) ou decisão binária para cada critério
    • Justificativa para cada pontuação de critério
    • Julgamento geral de preferência

    Esse formato de saída mais detalhado facilita casos de uso nuançados. Critérios específicos permitem comparações direcionadas — por exemplo, uma resposta sucinta pode ser mais apropriada para um caso de uso, enquanto uma resposta abrangente é necessária para outro. Justificativas e pontuações explícitas de critérios permitem aos usuários descartar critérios inadequados e recalcular preferências sem consultar o juiz novamente.

    Métricas de Avaliação Explicadas

    O processo de avaliação do juiz utiliza várias métricas importantes para comparação de qualidade:

    Concordância direta: Mede concordância com preferência humana em uma ordem específica de resposta.

    Concordância reconciliada: Porque a consistência posicional é uma propriedade importante de um juiz LLM confiável, os checkpoints são avaliados obtendo julgamentos em ambas as ordens possíveis de apresentação. O juiz recebe crédito apenas se concordar em ambas as direções e corresponder à preferência humana. Por definição, este número sempre será mais baixo que a concordância direta, mas fornece um proxy mais preciso do desempenho real.

    Pontuações ponderadas: Novas métricas que fornecem visão sobre a confiança do julgamento. Uma grande diferença entre pontuações ponderadas indica forte preferência por uma resposta. Essas pontuações são calculadas normalizando pontuações de critério para 0–1, multiplicando pelo peso do critério e somando para gerar pontuações finais. A margem de pontuação mostra a diferença entre pontuações ponderadas.

    Metodologia de Treinamento do Juiz

    O juiz baseado em rubrica da Amazon Nova foi treinado com um pacote de recompensa multi-aspecto otimizando para várias características desejáveis:

    • Precisão de preferência — recompensado quando produz decisões alinhadas com preferências humanas de ouro
    • Consistência posicional — decisões resilientes a inconsistências de posição de resposta candidata
    • Qualidade de justificativa — as justificativas devem alinhar com rubricas geradas, pontuações e julgamento final
    • Calibração de pontuação — pontuações ponderadas calibradas com precisão de decisão (julgamentos de alta confiança devem ser corretos mais frequentemente)

    O processo começou com dados de preferência anotados por humanos, empregando filtragem customizada de dados e geração de dados sintéticos para obter justificativas de preferência alinhadas com rubrica. O pipeline customizado treinou o juiz a gerar critérios apropriados com granularidade precisa para tomada de decisão consistente e robusta.

    Desempenho em Benchmarks

    Testes em conjuntos de dados de avaliação padrão mostram melhorias significativas, particularmente em tarefas exigindo julgamento nuançado:

    • PPE: de 0.61 para 0.64
    • RMBench: de 0.66 para 0.88
    • RewardBench: de 0.88 para 0.90
    • JudgeBench: de 0.51 para 0.76
    • CodeUltraFeedback: de 0.69 para 0.72
    • MMEval: de 0.80 para 0.84

    As melhoria maiores em JudgeBench (49% de aumento) e RMBench refletem melhor tratamento de cenários de avaliação complexos.

    Calibração de Decisões

    Durante treinamento e pós-processamento, a capacidade do juiz de tomar decisões bem calibradas é avaliada. O objetivo é alinhar confiança com precisão: o juiz LLM deveria ser mais preciso ao tomar decisões de alta confiança e permitido ser menos preciso com baixa confiança. Essa metodologia resulta em tomada de decisão consistente em conjuntos de dados dentro e fora da distribuição.

    Também são avaliadas as distribuições de pontuações geradas para diferentes critérios, buscando uma distribuição aproximadamente normal sobre pontuações de escala Likert no conjunto de avaliação. Esse processo de calibração duplo ajuda a identificar melhores checkpoints do juiz.

    Implementação Prática: Avaliando Modelos no SageMaker AI

    A solução apresenta um fluxo completo: começar com um conjunto de dados de teste, gerar respostas de modelos candidatos, e usar o juiz baseado em rubrica para comparação automática.

    Neste exemplo, questões foram amostradas do Stanford Question Answering Dataset (SQuAD), respostas foram geradas de dois modelos Qwen (1.5B e 7B), e os resultados foram salvos em um arquivo JSONL. O arquivo foi enviado para um bucket Amazon S3, e um job de treinamento PyTorch foi lançado para executar a avaliação do juiz usando SageMaker AI com instâncias GPU.

    O resultado inclui rubricas geradas dinamicamente, pontuações por critério, justificativas comparativas, contagens de preferência e medidas de confiança — tudo salvo em S3 para análise posterior.

    Imagem original — fonte: Aws

    Casos de Uso Avançados

    Avaliação de Sistemas RAG

    Em Retrieval Augmented Generation (Geração Aumentada por Recuperação), o principal modo de falha é alucinação. Juízes de preferência tradicionais confundem “a resposta é boa?” com “é fluida?”, “bem formatada?”, “a lógica interna é sólida?”. Uma resposta fluida mas factualmente incorreta frequentemente parece mais credível que uma desajeitada mas precisa.

    Uma avaliação focada em factualidade ajuda a selecionar modelos de resumo porque resultados de recuperação não têm alucinações. O juiz baseado em rubrica permite entender se a preferência baseia-se em critérios como fluência e formatação, ou se é baseada em critérios relevantes como fidedignidade, relevância de contexto. Usuários podem descartar pontuações de critérios irrelevantes e reavaliar julgamentos com base em um subconjunto de critérios que importam para sua aplicação.

    Crítica Criativa

    Em outro extremo, há casos onde criatividade e originalidade são desejáveis sobre fidelidade aos fatos reais ou contexto anterior. Um caso de uso envolvendo geração de histórias curtas ou scripts que sejam originais requer que gerações sejam suficientemente diferentes dos exemplos fornecidos, criativas, originais e sem emprestar diretamente de dados de treinamento existentes.

    Usuários finais podem focar em critérios como originalidade, coerência e engajamento para otimizar julgamentos de preferência adequados para esse caso de uso. Justificativas explícitas para pontuações de critérios fornecem visão sobre que tipo específico de originalidade e criatividade é desejável.

    Fonte

    Evaluate generative AI models with an Amazon Nova rubric-based LLM judge on Amazon SageMaker AI (Part 2) (https://aws.amazon.com/blogs/machine-learning/evaluate-generative-ai-models-with-an-amazon-nova-rubric-based-llm-judge-on-amazon-sagemaker-ai-part-2/)