Três novos modelos especializados chegam ao SageMaker JumpStart
A AWS anunciou a disponibilidade de três novos modelos de fundação no Amazon SageMaker JumpStart: o granite-speech-4.1-2b da IBM, o kanana-2-30b-a3b-instruct da Kakao e o OpenFold3 do OpenFold Consortium. A adição amplia o portfólio da plataforma com capacidades especializadas em reconhecimento de fala multilíngue, IA agêntica bilíngue e predição de estruturas biomoleculares.
Conheça cada modelo
granite-speech-4.1-2b — Reconhecimento de fala multilíngue da IBM
Desenvolvido pela IBM, o granite-speech-4.1-2b foi criado especificamente para Reconhecimento Automático de Fala (ASR) multilíngue e Tradução de Fala Bidirecional (AST), com suporte a inglês, francês, alemão, espanhol, português e japonês. Apesar de compacto — apenas 2 bilhões de parâmetros —, o modelo entrega uma taxa de erro de palavras de 5,33% com um fator de tempo real de aproximadamente 231, posicionando-o entre os modelos ASR mais eficientes de sua categoria. Distribuído sob a licença Apache 2.0, ele se integra a fluxos de trabalho corporativos de voz para transcrição, tradução e processamento de áudio em escala.
kanana-2-30b-a3b-instruct — IA agêntica bilíngue da Kakao
Criado pela Kakao, o kanana-2-30b-a3b-instruct se destaca em seguimento de instruções bilíngue coreano-inglês e em fluxos de trabalho de IA agêntica. Sua arquitetura combina Atenção Latente Multi-cabeça (MLA) e Mistura de Especialistas (MoE), ativando apenas 3 bilhões dos 30 bilhões de parâmetros totais a cada passagem direta — o que garante alta eficiência de processamento. O modelo passou por ajuste fino supervisionado e aprendizado por reforço, suporta até 128 mil tokens via escalonamento YaRN e foi projetado para atuar como um colaborador de IA capaz de entender contexto e agir de forma proativa.
OpenFold3 — Predição de estruturas biomoleculares
Desenvolvido pelo OpenFold Consortium em parceria com o AlQuraishi Lab da Universidade de Columbia, o OpenFold3 realiza predição de estruturas de complexos biomoleculares em nível atômico completo, abrangendo proteínas, DNA, RNA e ligantes de pequenas moléculas. Baseado em difusão, o modelo vai além da predição de proteínas individuais para modelar complexos de múltiplas cadeias e interações biomoleculares heterogêneas. Suas aplicações incluem design de fármacos assistido por computador e pesquisa acadêmica e farmacêutica.
Como acessar os modelos no SageMaker JumpStart
Com o SageMaker JumpStart, qualquer um desses modelos pode ser implantado com poucos cliques diretamente pelo console do SageMaker ou via SDK Python do SageMaker. Para mais detalhes sobre como implantar e utilizar modelos de fundação na plataforma, a AWS disponibiliza a documentação oficial do Amazon SageMaker JumpStart.
O problema: infraestrutura de consentimento OAuth que cada equipe precisava construir do zero
Agentes de IA frequentemente precisam acessar serviços externos — como GitHub e Slack — em nome de um usuário real. Para isso, o usuário precisa se autenticar com o provedor e aprovar explicitamente os acessos solicitados. O sistema, por sua vez, precisa associar com segurança essa autorização ao usuário que a concedeu. Esse processo é chamado de vinculação de sessão (session binding).
Até recentemente, quem usava o fluxo OAuth de três pernas (3LO) — também conhecido como fluxo de código de autorização do OAuth 2.0 — dentro do AgentCore Identity precisava construir e hospedar toda essa infraestrutura por conta própria. Isso incluía exibir a URL de autorização, hospedar um callback HTTPS público, autenticar o usuário de retorno, gerenciar sessões de navegador e chamar o endpoint CompleteResourceTokenAuth para concluir o fluxo.
A AWS anunciou uma solução gerenciada para esse problema: o Consent Portal, uma experiência web integrada ao AgentCore Identity, que elimina a necessidade de construir essa infraestrutura manualmente.
O que é o Consent Portal e como ele funciona
O Consent Portal é uma interface web gerenciada e um endpoint de vinculação de sessão para o AgentCore Gateway. O administrador cria um portal associado a um gateway e compartilha a URL com os usuários. A partir daí, o fluxo é completamente gerenciado:
O usuário se autentica com o Provedor de Identidade (IdP) da organização.
O portal lista os serviços disponíveis para o agente e seus respectivos status de conexão.
O usuário concede consentimento individualmente para cada provedor (por exemplo, GitHub ou Slack).
O portal gerencia os redirecionamentos do navegador e a vinculação de sessão.
O AgentCore Identity armazena os tokens resultantes em seu cofre de tokens.
Essa funcionalidade é especialmente útil para agentes acessados via Ambiente de Desenvolvimento Integrado (IDE) e clientes do Protocolo de Contexto de Modelo (MCP), como Kiro, Claude Code, Cursor e Visual Studio Code. O usuário concede o consentimento antes de invocar uma ferramenta, e as chamadas subsequentes já usam o token armazenado para aquele usuário.
Cenário de exemplo: assistente de desenvolvimento com acesso ao GitHub e Slack
Para ilustrar o funcionamento, a AWS usa o exemplo de uma empresa fictícia chamada Example Corp, que fornece aos seus desenvolvedores um assistente de codificação com IA via AgentCore Gateway. O assistente possui dois alvos configurados:
Um alvo GitHub, capaz de listar repositórios e criar issues.
Um alvo Slack, capaz de listar canais públicos e postar mensagens.
A empresa usa seu IdP corporativo para autenticar funcionários. O objetivo é que cada autorização OAuth do GitHub e do Slack fique vinculada ao funcionário que a aprovou, e que os desenvolvedores possam conectar cada provedor de forma independente, sem precisar repetir o processo toda vez que voltam à IDE.
Permissão para registrar a URL de callback do AgentCore Identity em cada aplicativo provedor.
Configuração pelo administrador (Passos 1 a 6)
Passo 1: Preparar o IdP corporativo e as conexões do gateway
O administrador precisa anexar uma política do Gerenciamento de Identidade e Acesso (IAM) à sua identidade para executar os passos iniciais. A política cobre ações como criar o Consent Portal, gerenciar provedores de credenciais OAuth2, listar e atualizar alvos do gateway, e criar e repassar a role de execução. O trecho abaixo mostra a política exata documentada pela AWS:
Passo 2: Configurar o aplicativo no IdP corporativo
No IdP corporativo, o administrador cria um aplicativo web OpenID Connect (OIDC) para o Consent Portal. É necessário habilitar o grant de código de autorização, gerar um client ID e um client secret, e configurar os escopos de login — no mínimo openid. O administrador também deve registrar a URL de descoberta OIDC, que o portal usa para localizar o endpoint de autorização, o endpoint de token e as chaves de assinatura.
Um ponto importante: o IdP precisa emitir um Token Web JSON (JWT) de acesso que o portal consiga validar. No caso do Okta, isso exige um servidor de autorização customizado com uma política de acesso adequada. No Auth0, pode ser necessário configurar um audience para que o IdP retorne um JWT assinado em vez de um token opaco.
Passo 3: Criar o provedor de credenciais do IdP
O portal lê o client ID e o client secret do IdP a partir de um provedor de credenciais OAuth2. No console do Amazon Bedrock AgentCore, em Build > Identity > Outbound Auth, o administrador adiciona um novo cliente OAuth com o nome, o client ID, o client secret e a configuração de descoberta OIDC do IdP corporativo.
Passo 4: Verificar os pré-requisitos de saída
Antes de criar o Consent Portal, é necessário confirmar que:
Os aplicativos OAuth do GitHub e do Slack estão registrados, com seus client secrets armazenados no AWS Secrets Manager.
O AgentCore Identity possui provedores de credenciais OAuth separados para GitHub e Slack, e a URL de callback gerada por cada um está registrada no respectivo aplicativo provedor.
Os alvos do gateway para GitHub e Slack usam o grant de código de autorização, solicitam apenas os escopos necessários e estão com status Ready.
A role de execução do Consent Portal consegue ler os secrets gerenciados pelo cliente referenciados pelos provedores de credenciais de saída.
Passo 5: Criar o Consent Portal
Na página de Identity do console, a seção Consent portals lista os portais existentes na conta e região. Para criar um novo portal, o administrador define um nome (de 1 a 50 caracteres, usando letras, números, hífens e underscores), uma descrição opcional de até 512 caracteres, e seleciona o gateway do assistente de desenvolvimento.
Vale destacar: o nome do gateway fica visível para os usuários finais no Consent Portal, então é importante escolher um nome claro e reconhecível. Além disso, cada gateway suporta apenas um Consent Portal, e o gateway não pode ser alterado após a criação.
Nas configurações de credenciais do IdP, o administrador seleciona o provedor OAuth2 criado no Passo 3 e mantém o escopo openid como obrigatório. Para as permissões, o console oferece a opção de criar automaticamente uma service role com as permissões necessárias.
Enquanto o portal está sendo provisionado, o Número de Recurso da Amazon (ARN) e a role de execução já ficam visíveis, mas a URL ainda não é atribuída. Quando o provisionamento termina, o status muda para Active e a URL do portal passa a aparecer no console, seguindo o padrão https://<gateway-name>.consent-portal.bedrock-agentcore.<region>.amazonaws.com.
Passo 6: Registrar as URLs de callback e compartilhar o portal
Com a URL do portal em mãos, o administrador precisa atualizar as configurações de callback em três lugares distintos:
No aplicativo do IdP corporativo (Cognito, Okta, Auth0, etc.): substituir o callback temporário por <portal-url>/callback.
Em cada alvo 3LO do gateway: definir a URL de retorno padrão como <portal-url>/connect/callback.
Nos aplicativos GitHub e Slack: confirmar que a callbackUrl gerada pelo AgentCore Identity já está registrada (isso deve ter sido feito no Passo 4).
Após validar tudo em um navegador, o administrador compartilha a URL do portal com a equipe de desenvolvimento por um canal de comunicação aprovado.
Experiência do usuário final (Passo 7)
Com a URL em mãos, o desenvolvedor acessa o portal no navegador, clica em Sign in e é redirecionado para o IdP corporativo. Após autenticar com as credenciais corporativas, o portal usa sua role de execução IAM para recuperar os alvos configurados no gateway e seus estados de conexão.
Na página de Conexões, o desenvolvedor vê os clientes OAuth do GitHub e do Slack com seus respectivos status. Ao clicar em Connect para o GitHub, o GitHub exibe os escopos e os acessos de organização solicitados pelo aplicativo OAuth para que o usuário os aprove.
Após o GitHub retornar o resultado da autorização, o portal conclui a vinculação de sessão e exibe o cliente OAuth e o alvo como Connected. O Slack, por sua vez, permanece como Not connected — demonstrando que os consentimentos são independentes para cada provedor.
Se o agente precisar do Slack, o desenvolvedor pode conectar esse provedor de forma análoga. Caso contrário, basta deixar desconectado até que seja necessário. Após conceder o acesso, o desenvolvedor retorna à IDE ou ao cliente MCP configurado para usar o mesmo AgentCore Gateway e executa normalmente as chamadas de ferramentas do GitHub ou Slack.
O que acontece por baixo dos panos
O fluxo técnico interno funciona da seguinte forma:
O portal valida a resposta do IdP e estabelece uma sessão de navegador criptografada.
Usando sua role de execução, o portal lista os alvos 3LO do gateway associado.
Quando o usuário clica em Connect, o portal chama GetResourceOauth2Token e recebe uma URL de autorização e um URI de sessão.
Após o provedor retornar o código de autorização ao AgentCore Identity, o navegador é redirecionado para o endpoint gerenciado de vinculação de sessão do portal.
O portal chama CompleteResourceTokenAuth com o contexto do usuário autenticado.
Quando o provedor retorna um refresh token, o AgentCore Identity o armazena e o usa automaticamente para obter novos access tokens após a expiração do token atual.
Caso nenhum refresh token válido esteja disponível — porque o provedor não emitiu um, ou ele expirou ou foi revogado — o usuário precisa retornar ao Consent Portal e reautorizar. A AWS recomenda configurar os provedores para emitir refresh tokens sempre que suportado: por exemplo, habilitando a expiração de tokens user-to-server no GitHub ou a rotação de tokens no Slack.
Na próxima vez que o desenvolvedor abrir o portal, os provedores já conectados continuam visíveis como conectados. Não é necessário aprovar novamente, a menos que o grant seja revogado, expire ou exija novo consentimento. O desenvolvedor também pode desconectar um provedor e reconectá-lo posteriormente.
Auditoria com AWS CloudTrail
O Amazon Bedrock AgentCore registra as operações de consentimento no AWS CloudTrail. Para auditar a atividade, basta filtrar o histórico de eventos pela fonte bedrock-agentcore.amazonaws.com e revisar os seguintes eventos:
GetResourceOauth2Token: quando o portal inicia a autorização OAuth para um provedor.
CompleteResourceTokenAuth: quando a vinculação de sessão é concluída.
GetWorkloadAccessTokenForJWT: quando o portal obtém acesso ao gateway para o usuário autenticado.
Um evento GetResourceOauth2Token identifica o provedor de credenciais, os escopos solicitados, o fluxo OAuth, a role de execução do portal e a região. Valores sensíveis de token e estado são ocultados. O exemplo abaixo mostra a estrutura do evento:
Em caso de falhas, os campos errorCode e errorMessage, combinados com o horário do evento, a role assumida, a região, o provedor de credenciais e os escopos solicitados, ajudam a identificar a causa.
Limpeza dos recursos
Quando os recursos não forem mais necessários, a AWS recomenda a seguinte ordem de remoção:
Excluir o Consent Portal no console do Amazon Bedrock AgentCore.
Remover as URLs de callback do portal no aplicativo do IdP corporativo e nos alvos do gateway.
Excluir os alvos do gateway que referenciam os provedores de credenciais de saída.
Excluir os provedores de credenciais OAuth de saída e o provedor de credenciais do IdP corporativo, se não estiverem sendo usados em outro lugar.
Excluir a role de execução do portal, se nenhum outro recurso a utilizar.
Atenção: é necessário excluir o alvo do gateway antes de excluir seu provedor de credenciais de saída. Um provedor ainda referenciado por um alvo não pode ser excluído.
Exemplos e documentação adicional
Para exemplos completos usando Microsoft Entra ID e Okta, a AWS disponibilizou repositórios no GitHub com os seguintes materiais:
A semana marcou uma virada na maturidade operacional de IA na AWS. O GPT-6 Astra chegou ao Bedrock com contexto de 1M tokens, enquanto melhorias no SageMaker reduziram latência de LLMs em até 77% e cold start de 30 minutos para segundos. No serverless, Lambda ganhou timeout de 90 minutos e suporte a agentes resilientes com Pydantic AI. Na contramão do entusiasmo, um benchmark revelou que nenhum modelo de IA é confiável para segurança em produção. O recado da semana: a infraestrutura amadureceu, mas governança e avaliação criteriosa de modelos nunca foram tão necessárias.
O que muda na prática
Workloads longos no Lambda (inferência de IA, transcodificação, cálculos financeiros) agora rodam até 90 minutos sem precisar migrar para EC2 ou containers — elimina gambiarras arquiteturais que muitos times ainda mantêm.
Avaliar modelo de IA só pelo preço por token está errado: o custo real por resposta correta pode ser menor em modelos mais caros, o que muda como times de produto e engenharia devem justificar escolhas de modelo.
Usar IA para detectar vulnerabilidades de segurança em produção ainda é arriscado — o Deception Benchmark mostrou que todos os 12 modelos testados geram falsos positivos em volume inaceitável para ambientes críticos.
Ações da semana
Se você opera endpoints de LLM no SageMaker, habilite o prefix-aware routing esta semana: sem mudança no contêiner do modelo, você pode reduzir o tempo até o primeiro token em até 77% em cargas com prompts repetitivos.
Revise a estratégia de seleção de modelos no Bedrock usando o framework de custo por resposta correta — compare seu modelo atual com o GPT-6 Astra em pelo menos um caso de uso real antes de fechar o orçamento do próximo trimestre.
O modelo mais avançado da OpenAI, com contexto de 1M tokens e uso autônomo de computador, já pode ser usado via Bedrock com governança e segurança AWS.
Para quem: Arquitetos e engenheiros de IA que avaliam modelos de fronteira para aplicações empresariais.
O primeiro benchmark público focado em distinguir vulnerabilidades reais de falsos positivos revelou que nenhum dos 12 modelos testados é adequado para uso em produção em segurança.
Para quem: Times de segurança e engenheiros que avaliam ou já usam IA para análise de código e detecção de vulnerabilidades.
O aumento de 6x no limite de timeout elimina gambiarras arquiteturais para cargas longas como inferência de IA, transcodificação e cálculos financeiros.
Para quem: Arquitetos serverless e engenheiros que precisam executar workloads de longa duração sem migrar para EC2 ou containers.
O suporte a mTLS no backend elimina certificados autoassinados e garante renovação automática, fechando uma lacuna crítica de segurança em APIs corporativas.
Para quem: Engenheiros de segurança e arquitetos de APIs que precisam de autenticação mútua em integrações com backends sensíveis.
O framework mostra que o custo real por resposta correta pode ser menor em modelos mais caros por token, mudando como times devem avaliar e selecionar modelos.
Para quem: Engenheiros e gestores que tomam decisões de custo e qualidade na escolha de modelos de IA generativa para produção.
Pré-carregamento de pesos e imagens de contêiner reduz em 60% o tempo de scale-out, tornando inferência de modelos grandes como DeepSeek-R1 viável em produção.
Para quem: Engenheiros de infraestrutura de ML que operam clusters de inferência com autoscaling e modelos de grande porte.
Quando equipes de engenharia vão comparar modelos de IA generativa, o caminho mais óbvio é olhar para o preço por milhão de tokens. É o número que aparece em todas as páginas de precificação e, naturalmente, acaba sendo o número que domina as planilhas de decisão. O problema é que cargas de trabalho reais não compram tokens — elas compram resultados: um ticket de suporte resolvido, um resumo financeiro correto, um relatório de pesquisa completo.
Entre a página de preços e o resultado final existem multiplicadores que o preço nominal ignora: com que frequência o modelo acerta, quantos tokens ele precisa para chegar lá e, em cargas de trabalho agênticas, quantos turnos ele leva — porque cada turno reenvia o histórico crescente da conversa para o modelo.
A AWS publicou um estudo baseado em um harness de benchmarking de código aberto que mede esses multiplicadores em cinco modelos: os modelos OpenAI no Amazon Bedrock (gpt-5.6-luna, gpt-5.6-terra e gpt-5.6-sol) e dois modelos cost-efficient da API OpenAI (gpt-5.4-mini e gpt-5.4-nano). Os dois últimos foram escolhidos como linha de base porque a pergunta mais comum das equipes é: “Usamos mini ou nano hoje — vale migrar para um modelo mais novo no Amazon Bedrock?”
O estudo foca em três perguntas centrais: quanto custa uma resposta correta (não um token); quanto custam trajetórias de agentes completas, já que o número de turnos pode dominar a fatura; e se o modelo consegue produzir entregas que um profissional aprovaria, medidas em tarefas reais de trabalho, não em questões de quiz.
Todo o benchmarking é reproduzível: o repositório openai-on-aws/benchmarks-openai roda o mesmo caminho de código (a Responses API da OpenAI) contra ambas as plataformas, e a AWS encoraja que cada equipe rode os testes com suas próprias tarefas antes de tomar qualquer decisão.
Como o estudo foi estruturado
O harness avalia os cinco modelos por meio do mesmo cliente da Responses API, alternando apenas o backend e o ID do modelo enquanto mantém a lógica de avaliação constante. Os modelos no Amazon Bedrock rodaram com raciocínio (reasoning) desabilitado, enquanto os modelos da API OpenAI rodaram com as configurações padrão. Ou seja, é uma comparação de configurações práticas de implantação, não uma medição controlada de capacidade intrínseca dos modelos.
Três dimensões foram medidas: precisão em chamada única e custo em benchmarks que ainda diferenciam modelos de ponta (matemática de competição AIME, ciência de nível de pós-graduação GPQA Diamond e MMLU-Pro); trajetórias de agentes em tarefas reais de pesquisa na web; e entregas profissionais avaliadas por rubrica.
Medindo o custo de uma resposta correta
Para cada benchmark, o estudo divide o gasto total de um modelo — considerando tentativas certas e erradas — pelo número de respostas corretas. Isso estima o custo observado de uma resposta correta na amostra.
Dois pontos chamam atenção nos resultados. Primeiro, os níveis de capacidade são visíveis na amostra: o sol resolve 75% dos problemas do AIME contra 37% do mini, e lidera também no GPQA Diamond (68% contra 43%) e no MMLU-Pro (82% contra 59%). Segundo, a eficiência de tokens já decidia a fatura antes mesmo dos preços mudarem — e os preços mudaram.
Com o seu preço original (cerca de 1,5× o do mini), o luna já era 25% mais barato por resposta correta no AIME nessa configuração, porque com o raciocínio desabilitado ele usava menos tokens faturados do que o mini com suas configurações padrão. Após a redução de preços do GPT-5.6 Luna e Terra no Amazon Bedrock em 30 de julho de 2026 (luna −80%, terra −20%), o custo registrado por resposta correta no AIME passou a ser US$ 0,0021 para o luna contra US$ 0,0139 para o mini. Nas amostras analisadas, o luna apresentou o menor custo observado por resposta correta, inclusive contra o nano, mesmo que o preço nominal por token do nano seja ligeiramente menor.
Nota sobre preços: os arquivos de resultado utilizam US$ 0,22/US$ 1,32 por milhão de tokens de entrada/saída para o luna e US$ 2,20/US$ 13,20 para o terra. Confirme o nível de inferência aplicável no Amazon Bedrock e a região na página de preços atualizada antes de tomar decisões.
O custo das trajetórias de agentes
A precificação por chamada única ignora uma característica central de cargas de trabalho agênticas. O harness usa histórico gerenciado pelo cliente com store: false, o que significa que cada turno reenvia o prompt de sistema, os resultados anteriores de ferramentas e todo o contexto da conversa. O contexto por turno cresce de forma aproximadamente linear. Assim, o total de tokens de entrada faturados pode crescer de forma aproximadamente quadrática com o número de turnos. Cada turno também adiciona latência de ida e volta. Um modelo que termina em cinco turnos em vez de oito pode economizar muito mais do que os 37% de redução de turnos sugerem isoladamente.
Para medir isso em uma carga de trabalho real, o estudo rodou uma amostra estratificada de 50 questões do DeepSearchQA — perguntas de pesquisa na web em múltiplas etapas — por meio de um loop de agente ao vivo com ferramentas reais de web_search e fetch_page. As respostas foram pontuadas com uma pré-verificação determinística seguida de um avaliador automático (autorater) baseado no gpt-5.5. Uma questão passa com F1 ≥ 0,7.
O mini foi o modelo com mais turnos por questão entre todos (7,6 turnos, principalmente em loops de nova pesquisa), e cada turno extra reenviava um contexto acumulado com resultados de busca. Ao final, isso representou 2,3× o volume de tokens de entrada do terra (114 mil contra 50 mil tokens por questão). Nessa amostra, o preço maior por token do terra foi compensado por menos turnos e maior qualidade: US$ 0,31 por resposta aprovada contra US$ 0,40 do mini, com F1 médio de 0,50 contra 0,39.
As três configurações GPT-5.6 registraram F1 médio maior do que as duas linhas de base. O luna combinou menos turnos do que o mini com US$ 0,05 por resposta aprovada contra US$ 0,40 do mini. O preço nominal por token do nano era menor, mas com taxa de aprovação de 18%, seu custo observado por resposta aprovada foi de US$ 0,07 contra US$ 0,05 do luna.
A lição prática: a eficiência de turnos é uma variável de precificação que simplesmente não aparece na página de preços. Se os seus agentes encadeiam chamadas de ferramentas — pesquisa, consultas em múltiplos saltos, recuperação iterativa — é fundamental medir o custo da trajetória completa, não apenas o custo por chamada.
Avaliando entregas profissionais com o GDPval
Benchmarks avaliam respostas. Mas grande parte do que as equipes realmente entregam são documentos — pareceres de conformidade, planos financeiros, protocolos de atendimento — onde “correto” é uma rubrica, não uma correspondência de string. Por isso o estudo incluiu 48 tarefas do GDPval: entregas profissionais reais criadas por profissionais com média de 14 anos de experiência, cada uma avaliada contra sua rubrica de referência. Uma entrega passa com ≥ 70% dos pontos ponderados da rubrica.
As três configurações gpt-5.6 alcançaram pontuações de rubrica observadas mais altas do que mini e nano com raciocínio desabilitado. As maiores diferenças apareceram em tarefas de direito, enfermagem e consultoria financeira, onde as rubricas exigem ressalvas específicas, estrutura e completude.
O luna pontuou acima do mini em 31 das 48 entregas, abaixo em 9 e empatou em 8. Ele passou em 27 entregas contra 20 do mini. Como essa carga de trabalho é de chamada única sem efeitos de turno, antes da redução de preços o mini e o nano eram mais baratos por entrega aprovada, e o gpt-5.6 comprava apenas taxa de aprovação. Após a redução, o luna passou a ter o menor custo observado nessa amostra: US$ 0,010 por entrega aprovada contra US$ 0,030 do mini e US$ 0,012 do nano, com taxa de aprovação de 56% contra 42% do mini e 35% do nano.
O terra e o sol ainda têm um custo maior por aprovação, mas registram desempenho de rubrica mais alto. Se esse custo adicional se justifica depende do custo de revisão e retrabalho no fluxo de trabalho alvo.
Ressalva do GDPval: as saídas foram limitadas a 8.192 tokens, truncando 6 entregas do luna, 9 do terra, 7 do sol, 0 do mini e 1 do nano. Esses são resultados reais sob o limite testado. Um limite maior pode melhorar a qualidade, mas também pode aumentar o custo — é importante testar os dois juntos.
Framework de decisão por tipo de carga de trabalho
Para quem usa gpt-5.4-mini ou nano hoje, a questão de migração depende do perfil da carga de trabalho:
Tarefas de alto volume e baixa complexidade, onde falhas são baratas: comece com o gpt-5.6-luna no Amazon Bedrock. O luna registrou o menor custo por resultado bem-sucedido nas amostras analisadas.
Aplicações interativas onde precisão importa e há Objetivos de Nível de Serviço (SLOs) de latência: faça benchmark do gpt-5.6-luna no Amazon Bedrock primeiro. Os resultados de latência são um retrato pontual regional — meça novamente em relação aos seus SLOs.
Agentes que encadeiam chamadas de ferramentas (pesquisa, consultas em múltiplos saltos): faça benchmark do gpt-5.6-luna e do gpt-5.6-terra no Amazon Bedrock. Ambos registraram F1 mais alto no DeepSearchQA com menos turnos do que o mini. O luna custou cerca de 8× menos por resposta aprovada nessa amostra de 50 questões.
Produção de documentos com controle de qualidade: o gpt-5.6-luna no Amazon Bedrock teve a maior taxa de aprovação entre os modelos cost-efficient no GDPval (27/48 contra 20/48 do mini) ao menor custo por entrega aprovada (US$ 0,010 contra US$ 0,030).
Precisão como requisito rígido em trabalhos genuinamente difíceis: faça benchmark do gpt-5.6-sol no Amazon Bedrock. Ele representa um nível diferente de capacidade e preço (AIME 75%, GDPval 31/48). Considere-o quando as configurações de menor custo não atingirem o seu limite de qualidade.
Latência: um retrato pontual
O estudo também mediu a latência dos mesmos modelos nas duas plataformas com o mesmo harness de streaming. Nas execuções de julho de 2026 (us-west-2, região única, retrato pontual), o tempo mediano até o primeiro token no Amazon Bedrock foi em média 21% menor para o luna e 5% menor para o terra nas 12 configurações correspondentes. O throughput do luna foi em média 43% maior no Amazon Bedrock em saídas com ≥ 500 tokens (terra +4%). As proporções piores-caso de tempo até o primeiro token para a mediana foram de 2,1–2,5× no Amazon Bedrock contra 4,6–6,6× na API OpenAI.
O sol tem comportamento diferente: é um modelo de raciocínio profundo com tempo até o primeiro token inerentemente longo e variável, e suas execuções no Amazon Bedrock usaram us-east-1. Os detalhes por configuração para os três modelos estão documentados na seção de performance do repositório.
Como rodar o benchmark na sua própria carga de trabalho
Os resultados refletem as escolhas de configuração do estudo: 50–198 questões por conjunto (DeepSearchQA 50, AIME 60, MMLU-Pro 140, GPQA Diamond 198), 48 entregas e raciocínio desabilitado para os modelos no Amazon Bedrock — um piso deliberado de custo. Habilitar o raciocínio aumenta tanto a qualidade quanto o gasto. As suas tarefas não são as tarefas do estudo.
A metodologia é a parte durável. Para reproduzir os benchmarks:
git clone https://github.com/openai-on-aws/benchmarks-openai
pip install -r requirements.txt
export OPENAI_API_KEY=sk-... # sua própria chave; não é armazenada
export AWS_REGION=us-west-2 # mais suas credenciais AWS padrão
python quality/quick_evals.py # precisão + custo por resposta correta
python quality/deepsearchqa/run_deepsearchqa.py # trajetórias de agentes com web ao vivo
python quality/gdpval_eval.py # entregas profissionais, avaliadas por rubrica
performance/run_all.sh # latência, ambas as plataformas
Substitua por 50–100 das suas próprias tarefas com saídas conhecidas e os mesmos scripts produzem números de custo por resultado no seu domínio, na sua conta.
Conclusão
O preço por token é uma entrada para a decisão, não a decisão em si. Nas configurações testadas, normalizar o custo por resultados bem-sucedidos mudou o ranking dos modelos depois que precisão, eficiência de tokens e comprimento de trajetória foram considerados. As páginas de preços também mudam — como as reduções de julho de 2026 para o GPT-5.6 demonstraram.
A recomendação é definir o resultado e o limite de qualidade que a sua aplicação precisa, medir o custo completo de sucessos e falhas, e repetir a avaliação quando preços, modelos ou padrões de carga de trabalho mudarem. Para começar com os modelos OpenAI no Amazon Bedrock, consulte a documentação do Amazon Bedrock. Para reproduzir os benchmarks nas suas próprias tarefas, clone o repositório openai-on-aws/benchmarks-openai.
À medida que os usuários passam a interagir com serviços digitais por meio de hosts de Inteligência Artificial (IA) como o ChatGPT e o Claude, as organizações enfrentam um desafio concreto: como tornar seus serviços acessíveis dentro dessas plataformas com interfaces ricas, e não apenas respostas em texto simples? E como fazer isso sem ficar preso a um único host?
É exatamente para isso que a AWS combina o MCP Apps com o Amazon Bedrock AgentCore. O MCP Apps é uma extensão do Protocolo de Contexto de Modelo (MCP) que permite entregar widgets HTML interativos renderizados diretamente dentro dos hosts de IA. Já o Amazon Bedrock AgentCore é a plataforma da AWS para construir, conectar e otimizar agentes em escala, com qualquer framework ou modelo.
Para o caso específico de MCP Apps, dois componentes do AgentCore entram em ação: o AgentCore runtime, que fornece um ambiente serverless, seguro e com isolamento de sessão para hospedar o servidor MCP; e o AgentCore Gateway, que expõe esse servidor por meio de um único endpoint gerenciado que os hosts compatíveis com MCP Apps conseguem acessar.
A aplicação de exemplo: Unicorn Rentals
Para demonstrar o conceito na prática, a AWS publicou uma aplicação de exemplo chamada Unicorn Rentals — um serviço fictício de aluguel de unicórnios. Com ela, os usuários podem visualizar unicórnios disponíveis, fazer reservas, consultar aluguéis ativos e devolver um unicórnio. Tudo isso por meio de linguagem natural dentro do ChatGPT ou do Claude.
O fluxo funciona assim na prática:
Listar unicórnios disponíveis: ao perguntar “pode me mostrar todos os unicórnios?”, o host interpreta a solicitação e renderiza cards interativos para cada unicórnio — com imagem, nome, descrição, valor por hora e disponibilidade.
Fazer uma reserva: dizendo “quero alugar o Stardust”, o sistema registra a reserva e confirma imediatamente com ID de reserva, data, valor e o unicórnio escolhido.
Consultar reservas ativas: ao pedir “mostre minhas reservas”, o app retorna o aluguel em andamento com duração e custo acumulado — neste caso, em formato de texto simples, sem card, pois nem toda resposta precisa de interface rica.
Devolver o unicórnio: com “quero devolver meu unicórnio”, o sistema encerra o aluguel, calcula o custo total com base na duração e no valor por hora, e exibe o resultado na conversa.
O ponto mais relevante aqui é que toda essa experiência é servida por um único servidor MCP rodando no AgentCore runtime, independentemente do host utilizado. Por ser baseado no padrão aberto MCP Apps, o mesmo servidor funciona tanto no ChatGPT quanto no Claude ou qualquer outro host que suporte a extensão.
Arquitetura da solução
A solução implanta um MCP App no Amazon Bedrock AgentCore que expõe lógica de negócio e widgets HTML interativos via Protocolo de Contexto de Modelo. Os usuários interagem com hosts de IA, que renderizam esses widgets usando o padrão MCP Apps. A lógica de negócio fica em uma função AWS Lambda dedicada, com o Amazon DynamoDB como camada de persistência.
O fluxo de registro e descoberta funciona da seguinte forma: ao registrar o MCP App em um host de IA, o host realiza chamadas tools/list e resources/list para o endpoint do AgentCore Gateway. O servidor MCP responde com a lista de ferramentas disponíveis (como list_unicorns, book_unicorn, view_bookings e return_unicorn) e os recursos de widget associados. O AWS WAF valida as requisições por meio de lista de permissões de IP e regras gerenciadas antes de chegarem ao Gateway.
Quando um usuário faz uma solicitação, o fluxo se divide em duas fases:
Fase 1 — Chamada de ferramentas: o host traduz a solicitação em linguagem natural para uma mensagem tools/call do MCP e a envia ao endpoint do AgentCore Gateway. O Gateway repassa ao AgentCore runtime, que aciona a Lambda de negócio. A Lambda executa as operações no DynamoDB e retorna o resultado, que o servidor MCP formata e devolve ao host.
Fase 2 — Renderização de widgets: se a ferramenta tiver um URI de recurso associado (como ui://widget/unicorn-list), o host inicia uma requisição resources/read para esse URI. O servidor MCP retorna o HTML do widget como conteúdo independente. O host renderiza esse HTML em um iframe isolado, injetando os dados estruturados retornados pela chamada de ferramenta. As imagens do widget são servidas pelo Amazon CloudFront, que usa o Amazon Simple Storage Service (Amazon S3) como origem. Ferramentas sem widget associado, como view_bookings e return_unicorn, retornam apenas texto e pulam essa fase.
Como o servidor MCP é construído
Estrutura do MCP App
O MCP App da solução é uma aplicação TypeScript construída sobre o SDK oficial @modelcontextprotocol/sdk, com a extensão @modelcontextprotocol/ext-apps — que fornece uma forma padronizada de entregar widgets interativos a partir de servidores MCP. A aplicação roda como um servidor HTTP Express.js gerenciado internamente pelo AgentCore runtime.
Ferramentas MCP
O app registra as ferramentas MCP (list_unicorns, book_unicorn, view_bookings e return_unicorn) que os hosts de IA podem invocar. O registro é feito com a função registerAppTool, fornecendo o nome da ferramenta, sua configuração e uma função de handler com a lógica de negócio. O campo _meta.ui.resourceUri na configuração da ferramenta indica ao host qual widget renderizar para exibir a resposta. O structuredContent na resposta da chamada contém o payload de dados que será injetado no widget durante a renderização.
Recursos MCP
Os widgets são registrados como Recursos MCP que os hosts de IA podem consumir. O registro usa a função registerAppResource, fornecendo nome, URI e um handler que retorna o HTML do widget. Cada recurso responde tanto a requisições de descoberta (resource/list) quanto de leitura (resource/read).
Hospedagem no AgentCore runtime
O processo de implantação empacota o código do MCP App em um arquivo zip, faz upload para um bucket S3 e cria um recurso de runtime no AgentCore referenciando esse pacote. A configuração especifica o ambiente NODE_22, o ponto de entrada e o modo de protocolo MCP. O runtime escala automaticamente conforme o volume de requisições. Políticas baseadas em recursos restringem quais entidades podem invocar o runtime — nesta solução, apenas a role de execução do AgentCore Gateway tem permissão.
Expondo o servidor via AgentCore Gateway
O AgentCore runtime suporta autenticação via Gerenciamento de Identidade e Acesso (IAM) com SigV4 e OAuth. A solução coloca um AgentCore Gateway na frente do runtime para que hosts externos acessem o servidor MCP por um único endpoint gerenciado. O Gateway aceita requisições sem autenticação do lado do cliente e invoca o runtime usando sua própria role IAM via SigV4 — ou seja, os chamadores não precisam gerenciar credenciais AWS. O AWS WAF protege o endpoint com lista de permissões de IP, regras de detecção de ameaças e limitação de taxa.
Camada de lógica de negócio
Uma função AWS Lambda implementa toda a lógica de negócio do serviço de aluguel, lidando com consultas de inventário e operações de reserva no DynamoDB. Essa Lambda não sabe nada sobre MCP — ela é apenas um serviço de backend. Em implementações reais, essa camada poderia ser serviços existentes rodando no Amazon Elastic Container Service (Amazon ECS), no Amazon Elastic Kubernetes Service (Amazon EKS) ou em qualquer outro serviço de computação. O servidor MCP atua como um adaptador de protocolo fino: a lógica de negócio permanece onde já está, conectada à camada MCP por padrões de invocação padrão como chamadas HTTP ou clientes SDK.
Kit de Desenvolvimento em Nuvem da AWS (AWS CDK) CLI instalado globalmente. Veja as instruções em Primeiros passos com o AWS CDK.
Implantação
A implantação usa um único script deploy.sh que orquestra o build e a implantação das stacks do CDK. Os passos são:
Passo 1: Baixe o código da solução:
git clone https://github.com/aws-samples/sample-agentcore-mcp-apps.git
cd sample-agentcore-mcp-apps
Passo 2: Implante os recursos necessários na sua conta AWS executando o script de implantação:
bash deploy.sh
Anote as saídas exibidas após a implantação. Você precisará do valor de GatewayResourceUrl para conectar um host de IA.
Conectando hosts de IA
Como o servidor MCP implementa o padrão aberto MCP Apps, qualquer host que suporte a extensão pode se conectar e renderizar a experiência completa com widgets interativos.
ChatGPT: acesse https://chatgpt.com/, vá em Perfil do Usuário → Plugins → Modo Desenvolvedor e ative-o. Em Plugins, escolha Novo Plugin. Defina o nome como UnicornRentals, adicione uma descrição, informe o valor de GatewayResourceUrl como Connection e selecione No Auth como autenticação. Clique em Create.
Claude.ai: acesse https://claude.ai, vá em Customize → Connectors → Add Connector. Defina o nome como UnicornRentals, informe o valor de GatewayResourceUrl como URL do servidor MCP remoto e salve.
Considerações para produção
Ao levar esta solução para produção, a AWS recomenda atenção a alguns pontos:
Monitoramento e observabilidade: use o Amazon CloudWatch para monitorar métricas de requisições do AgentCore Gateway, invocações da Lambda e saúde dos containers do AgentCore runtime. Configure alarmes para taxas de erro e latência, e ative logs para rastrear chamadas de métodos MCP.
Otimização de custos: o AgentCore runtime usa precificação baseada em consumo, com base no tempo de execução do container e nas invocações. Dimensione corretamente a memória e CPU do container e revise as configurações de concorrência da Lambda conforme os padrões de tráfego esperados.
IA responsável: adicione controles de segurança nos limites de confiança. Valide os argumentos das ferramentas com schemas rigorosos no servidor MCP e revalide-os na Lambda de negócio. Para textos não estruturados que cruzam esses limites, use o Amazon Bedrock Guardrails para filtrar conteúdo prejudicial, bloquear tópicos negados e redigir dados sensíveis como Informações de Identificação Pessoal (PII) antes que as respostas cheguem ao cliente.
Para remover todos os recursos criados pelas stacks do CDK, execute:
cd infrastructure/cdk
npx cdk destroy
Por que essa abordagem é relevante
O que torna esse padrão arquitetural poderoso é justamente o que você não precisa construir. O AgentCore runtime cuida do escalonamento, do isolamento de sessão, do monitoramento de saúde e do gerenciamento de infraestrutura. A equipe foca na lógica de negócio e nos widgets — e escreve apenas um adaptador de protocolo fino apontando para os serviços existentes.
Por ser construída sobre o padrão aberto MCP Apps, a solução não fica presa a um único host de IA. O mesmo servidor, as mesmas ferramentas e os mesmos widgets interativos funcionam em qualquer host que suporte a extensão. E como a arquitetura separa claramente o tratamento de protocolo da lógica de negócio, cada parte pode evoluir de forma independente — trocar o banco de dados, adicionar novas ferramentas, redesenhar widgets ou conectar novos serviços de backend sem precisar rearquitetar a implantação.
O código-fonte e as instruções completas de implantação estão disponíveis no repositório GitHub da solução em aws-samples.
A AWS anunciou a disponibilidade do TwelveLabs Marengo 3.0 como modelo de embedding no Amazon Bedrock Managed Knowledge Base. Com essa integração, equipes de desenvolvimento passam a contar com suporte nativo para criar embeddings multimodais a partir de conteúdos de vídeo, áudio e imagem — tudo isso dentro do ecossistema gerenciado do Bedrock, sem necessidade de gerenciar infraestrutura própria.
Além da transcrição: o que muda com o Marengo 3.0
O Amazon Bedrock Managed Knowledge Base já oferecia uma forma de busca em mídia: transcrevia o áudio e o vídeo para texto e gerava embeddings baseados nesse texto. Funciona bem para muitos cenários, mas tem uma limitação clara — significados que estão na imagem, no tom de voz ou em elementos visuais simplesmente se perdem na transcrição.
O Marengo 3.0 vai além disso. Em vez de converter tudo para texto antes de processar, o modelo codifica diretamente cenas visuais, fala e pistas de vídeo em embeddings multimodais. Isso significa que o sistema consegue capturar nuances de significado que a transcrição sozinha não conseguiria representar.
Como funciona na prática
O fluxo de uso é direto: basta fazer o upload dos arquivos de mídia a partir de fontes de dados como o Amazon S3, sincronizar e realizar buscas usando linguagem natural. Não há infraestrutura para configurar ou gerenciar.
O Marengo 3.0 gera vetores compactos de 512 dimensões, com precisão de recuperação considerada estado da arte. Um detalhe relevante para aplicações práticas: os resultados incluem os tempos de início e fim de cada segmento, o que permite que a aplicação leve o usuário diretamente ao momento relevante dentro de um vídeo — sem precisar assistir tudo do começo.
O modelo também oferece opções configuráveis de segmentação, para que a estrutura do conteúdo seja respeitada conforme a necessidade de cada projeto.
Casos de uso desbloqueados
Com essa capacidade, a AWS aponta para uma série de aplicações que antes seriam difíceis ou impraticáveis com busca baseada apenas em texto:
Esportes e entretenimento: localizar jogadas específicas em temporadas inteiras de footage de partidas
Educação: encontrar trechos de aulas por conceito, não apenas por palavras-chave
Segurança: busca semântica em gravações de câmeras e registros de áudio
Varejo: indexação e recuperação de conteúdo visual de produtos
Mídia: organização e busca em grandes acervos audiovisuais
O problema do cold start em inferência de LLMs em escala
Quem trabalha com inferência de Grandes Modelos de Linguagem (LLM) em escala sabe bem o quanto o cold start pode ser um gargalo real. Em cargas de trabalho como assistentes de chat, pipelines agênticos, RAG (Geração Aumentada por Recuperação) e análise de documentos, cada evento de deploy ou scale-out exige o download de imagens de contêiner e dos pesos do modelo — e esse processo consome a maior parte do tempo antes que o serviço consiga atender qualquer requisição.
O cenário piora conforme o tamanho dos modelos cresce. Modelos grandes podem levar dezenas de minutos para ficarem prontos para servir tráfego, tornando o autoscaling lento e impraticável em situações de pico.
O que a AWS anunciou
A AWS anunciou que o Amazon SageMaker HyperPod agora conta com suporte a cache de modelos, uma otimização de inferência que pré-carrega os pesos do modelo e as imagens de contêiner diretamente nos nós do cluster. Com isso, os pods passam a iniciar em segundos — em vez de minutos.
Duas capacidades independentes
O cache de modelos no HyperPod funciona por meio de duas capacidades que operam de forma independente:
Cache de pesos (weights cache): armazena os pesos do modelo no armazenamento NVMe local do nó. Assim, os pods leem os dados diretamente do armazenamento local rápido, sem precisar baixá-los do S3 ou do FSx pela rede.
Cache de imagem (image cache): faz o pré-download da imagem de contêiner, eliminando completamente o tempo de download do ECR (Elastic Container Registry) no momento da inicialização do pod.
Um ponto importante de confiabilidade: se um pod for alocado em um nó sem cache aquecido, o sistema automaticamente realiza o fallback para a fonte original — sem risco de pods travados ou com falha.
Resultados de benchmark
Os benchmarks realizados com modelos entre 57 GB e 145 GB mostram resultados expressivos:
Aproximadamente 60% de redução no tempo de scale-out com o cache de pesos.
Mais de dois minutos eliminados no tempo de download de imagem, representando uma redução de 97% com o cache de imagem.
O ganho cresce proporcionalmente ao tamanho do modelo, mantendo a confiabilidade do caminho de origem original como fallback.
Como habilitar o recurso
Os clientes podem ativar o cache de modelos por meio do HyperPod Inference Operator, adicionando uma seção modelCacheConfig ao recurso InferenceEndpointConfig ou JumpStartModel. O operador gerencia todo o ciclo de vida do cache sem necessidade de configuração manual ou limpeza por parte do usuário.
Disponibilidade
O cache de modelos está agora em disponibilidade geral em todas as regiões onde o SageMaker HyperPod está disponível. Para começar, a AWS disponibiliza a documentação oficial do SageMaker HyperPod com todos os detalhes de configuração.
Proteção contra loops recursivos chega à Europe Sovereign Cloud
A AWS expandiu a disponibilidade da detecção de loops recursivos do Lambda para funções que rodam na Europe Sovereign Cloud. O recurso, que já estava disponível em outras regiões, agora protege também os ambientes soberanos europeus contra um dos problemas mais silenciosos — e potencialmente caros — em arquiteturas orientadas a eventos.
O problema: loops recursivos não intencionais
Em aplicações orientadas a eventos, é comum usar fontes de eventos como Amazon S3, Amazon SQS e Amazon SNS para acionar funções Lambda. O problema surge quando uma má configuração ou um defeito no código faz com que o evento seja reenviado para a mesma origem que disparou a função — criando um loop recursivo que se retroalimenta indefinidamente.
Esse tipo de situação pode passar despercebido por algum tempo, gerando uso não intencional e, consequentemente, cobranças inesperadas na conta da AWS. É exatamente esse cenário que a detecção de loops recursivos foi projetada para evitar.
Como a detecção funciona
Quando a AWS identifica um loop recursivo em andamento, o processamento do evento é interrompido automaticamente. Além disso, o usuário recebe uma notificação no AWS Health Dashboard com orientações de diagnóstico para ajudar a identificar a causa raiz do problema.
O recurso fica ativado por padrão em funções Lambda que utilizam uma versão do SDK compatível, sem necessidade de configuração adicional.
E se o loop for intencional?
Existem cenários legítimos em que uma função Lambda precisa invocar a si mesma ou acionar recursivamente outros serviços de forma controlada. Para esses casos, a AWS disponibiliza a API PutFunctionRecursionConfig, que permite desativar a detecção de loops recursivos em funções específicas.
Ou seja, quem precisa do comportamento recursivo intencional não fica bloqueado — basta ajustar a configuração da função individualmente.
Por que isso importa para quem usa a Europe Sovereign Cloud
A Europe Sovereign Cloud é voltada para organizações com requisitos rigorosos de residência de dados e conformidade regulatória na Europa. Com essa expansão, os clientes que operam nesse ambiente passam a contar com o mesmo nível de proteção operacional já disponível nas demais regiões da AWS — o que é especialmente relevante em ambientes onde qualquer anomalia de custo ou comportamento precisa ser detectada e contida rapidamente.
Para saber mais sobre como o recurso funciona em detalhes, a AWS disponibiliza a documentação oficial do Lambda com todas as informações técnicas necessárias.
O problema: questionários RFI são trabalhosos e propensos a erros
Empresas de todos os tamanhos precisam responder a questionários de Solicitação de Informações (RFI — Request for Information) com frequência. Uma grande organização pode receber centenas desses documentos por ano, e cada um costuma chegar como uma planilha complexa com múltiplas abas, conjuntos hierárquicos de perguntas, metadados de categorias e diferentes tipos de resposta.
O processo manual de extrair, estruturar e responder essas perguntas é custoso: exige coordenação entre equipes, gera atrasos e introduz erros sempre que o formato do questionário muda. A AWS apresentou uma solução para esse desafio usando o Amazon Quick Automate, serviço que permite criar automações multi-agente para processos empresariais complexos.
O que é o Amazon Quick Automate
O Amazon Quick Automate é um serviço voltado para a automação de processos empresariais que podem envolver diferentes departamentos, sistemas, interações de interface e APIs, além de integrações com sistemas de terceiros. Ele utiliza um conjunto de agentes para simplificar o gerenciamento de processos e reduzir a sobrecarga de manutenção.
O diferencial está na forma de uso: em vez de escrever código, o usuário descreve em linguagem natural o que a automação deve fazer. O serviço interpreta essas instruções e gera um fluxo de trabalho executável cobrindo ingestão, transformação, validação e saída de dados. É possível refinar o fluxo por meio de conversas, executá-lo contra dados reais e promover versões validadas entre Regiões AWS.
Visão geral da solução
O tutorial publicado pela AWS demonstra como construir uma automação completa que:
Grava um arquivo CSV (Comma-Separated Values — valores separados por vírgula) limpo de volta no Amazon S3.
O fluxo segue sete etapas principais: configurar o conector de ação S3, adicionar a integração a um grupo de automação, criar um projeto de automação, descrever a lógica de processamento em linguagem natural, refinar o fluxo por conversa, validar os resultados e promover a versão validada com o recurso de Importação/Exportação.
Conhecimento básico de buckets, prefixos e objetos do Amazon S3.
Criando a função IAM necessária
É preciso criar uma função IAM (Identity and Access Management — Gerenciamento de Identidade e Acesso) que conceda ao Amazon Quick Automate permissão para acessar o bucket S3. Os passos são:
Com a função IAM criada, o próximo passo é configurar o conector S3 no console do Amazon Quick. O processo envolve acessar Manage Account > Permissions > AWS Actions, criar uma nova ação do tipo Amazon S3, informar um nome para o conector (por exemplo, ExampleBucket-S3-Connection), uma descrição e colar o ARN da função IAM criada anteriormente. O console valida automaticamente a política de confiança da função.
Após confirmar a conexão bem-sucedida, compartilhe o conector com os usuários e grupos que irão construir e executar os fluxos de trabalho.
Criando o grupo e o projeto de automação
O próximo passo é criar um grupo de automação — uma unidade organizacional que agrupa o conector S3 e os projetos relacionados. No console do Amazon Quick, acesse Automations > Create Group, nomeie o grupo (por exemplo, RFI-Processing-Group) e selecione o conector S3 criado anteriormente.
Com o grupo configurado, crie o projeto de automação. É nele que a lógica de processamento será descrita e onde o fluxo gerado ficará armazenado. Na aba Projects, escolha Create Project, informe um nome, selecione o grupo de automação e, opcionalmente, adicione uma descrição. A seção de business case é opcional e serve para rastrear o retorno sobre o investimento.
Descrevendo a lógica de processamento em linguagem natural
Esta é a etapa central da solução. No projeto de automação, o usuário descreve o que a automação deve fazer usando linguagem natural — pode digitar diretamente na área de prompt ou fazer upload de um arquivo com os requisitos. O assistente de inteligência artificial interpreta as instruções e gera os passos executáveis do fluxo.
Exemplo de prompt para leitura e extração
O tutorial apresenta o seguinte exemplo de prompt:
"Connect to my S3 bucket using the ExampleBucket-S3-Connection connector. Read the file SampleDepartment_Version2.xlsx from the sample-folder prefix. Open the Strategy sheet and extract all survey questions. Identify main questions and subquestions based on numbering and indentation. Structure the data with columns for Serial Number, Category, Question, and Response Type. Write the output as a CSV file to the output-folder prefix in the same bucket."
O que o assistente gera automaticamente
Após o envio do prompt, o assistente de IA gera um fluxo com múltiplos passos, cada um mapeando uma parte das instruções:
Leitura dos dados: conecta ao S3, baixa a planilha e lê a aba de destino com cabeçalhos;
Extração e transformação: identifica perguntas principais e subperguntas por numeração e indentação, e extrai metadados de categoria dos cabeçalhos de coluna;
Estruturação da saída: converte subperguntas em registros independentes, mesclando o contexto da pergunta pai, e define o esquema de saída;
Gravação dos resultados: salva a saída estruturada como arquivo CSV no local S3 especificado.
Como o assistente utiliza IA generativa, os passos exatos e a redação podem variar entre execuções, mas a lógica operacional permanece a mesma com base nas instruções fornecidas.
Executando e validando o fluxo
Após a geração, basta escolher Run para executar o fluxo contra a planilha real. A validação deve confirmar que todas as perguntas foram extraídas (principais e subperguntas), que o texto de categoria corresponde exatamente aos cabeçalhos da fonte, que as subperguntas incluem o contexto da pergunta pai e que os tipos de resposta foram preservados como estão na origem.
Refinando o fluxo por conversa
Quando a saída precisa de ajustes, a interface de conversa permite solicitar mudanças específicas referenciando o passo exato e descrevendo o comportamento esperado. O tutorial apresenta exemplos de prompts de refinamento:
“O passo que lê a aba Strategy também deve capturar os cabeçalhos de coluna como metadados.”
“O campo de categoria não corresponde aos cabeçalhos da fonte. Atualize a extração para usar o texto exato do cabeçalho.”
“No passo de transformação de subperguntas, mescle o contexto da pergunta pai no texto da pergunta.”
O ciclo recomendado é: identificar o problema, solicitar uma atualização específica, revisar o fluxo atualizado e re-executar para validar a correção. A AWS recomenda validar incrementalmente — rodando e verificando a saída após cada refinamento, em vez de acumular múltiplas mudanças — e tratar casos extremos explicitamente, descrevendo como o fluxo deve se comportar quando dados estiverem ausentes, duplicados ou com formatação inconsistente.
Promovendo a automação com Importação/Exportação
O recurso de Import/Export (Importação/Exportação) do Amazon Quick Automate permite a promoção controlada de versões do ambiente de pré-produção para produção e a reutilização consistente entre Regiões AWS.
Para exportar, acesse o projeto de automação, vá até a aba Versions e escolha Export version para a versão validada. Copie o link gerado com atenção — ele expira após um período determinado. Para importar, abra ou crie um projeto Amazon Quick Automate na conta ou Região de destino, escolha Import version, cole o link e conclua o processo. Após a importação, configure os conectores, credenciais e configurações de implantação no ambiente de destino.
Limpeza do ambiente
Após os testes, a AWS orienta excluir o projeto de automação e o grupo de automação, remover o conector S3 se nenhum outro fluxo o utilizar, e apagar as funções IAM de teste e os objetos S3 de teste quando não forem mais necessários. Mais detalhes de limpeza estão disponíveis na documentação do Amazon Quick Automate.
Possibilidades de extensão
A AWS destaca que a mesma abordagem pode ser adaptada para outros cenários de negócio:
Processamento Inteligente de Documentos (IDP — Intelligent Document Processing): extração de dados estruturados de faturas, contratos ou formulários;
Consolidação de relatórios: unificação de relatórios financeiros com múltiplas abas em um único conjunto de dados;
Automação de interface: automatização de tarefas repetitivas em navegadores que alimentam análises posteriores;
Agregação de dados de pesquisas: consolidação de respostas de múltiplas fontes em uma única saída.
Para saber mais sobre as capacidades de automação, conectores de ação e fluxos em linguagem natural, a AWS disponibiliza a documentação do Amazon Quick. Para começar a usar o serviço, acesse o guia de introdução ao Amazon Quick.
A AWS anunciou a integração entre o AWS Lambda Durable Functions e o Pydantic AI, framework open source para construção de agentes de Inteligência Artificial (IA) em Python. A novidade foi divulgada em setembro de 2026 e está disponível em todas as regiões da AWS onde o Lambda Durable Functions já opera.
Como a integração funciona
O AWS Lambda Durable Functions passa a salvar automaticamente o progresso do agente Pydantic AI durante a execução. Isso significa que, se ocorrer uma interrupção — como um timeout — o agente retoma a execução a partir do último passo já concluído, em vez de começar tudo do zero.
Cada chamada de modelo e cada chamada de ferramenta feita pelo agente é tratada como um passo de execução durável. Ou seja, se a execução for interrompida no meio do caminho, os passos que já foram concluídos não são repetidos.
O ponto importante aqui é que o desenvolvedor não precisa escrever a lógica de checkpoint e retry por conta própria — a tolerância a falhas vem embutida na integração.
Por que isso importa na prática
A integração resolve dois problemas concretos que afetam agentes de IA em produção:
Custo de reprocessamento: em fluxos que envolvem várias chamadas de modelo — como revisar um conjunto de documentos ou pesquisar um tema em múltiplas fontes — reiniciar a execução do zero significa pagar novamente pelos tokens já consumidos. Com a execução durável, apenas os passos pendentes são executados.
Efeitos colaterais indesejados: retomar uma execução sem controle pode causar ações duplicadas, como cobrar um cliente duas vezes. A durabilidade evita esse tipo de problema ao garantir que cada passo seja executado exatamente uma vez.
Infraestrutura e disponibilidade
Por rodar sobre o AWS Lambda, a solução mantém o modelo serverless: sem servidores para gerenciar e com cobrança apenas pelo tempo de computação efetivamente utilizado. A integração pode ser usada em qualquer função Python que utilize o AWS Lambda Durable Functions.
