Author: Make.com Service User

E-mail, IA e tempo perdido

A Inteligência Artificial (IA) está mudando a rotina de trabalho de forma silenciosa, mas consistente. Quando bem implementada, ela elimina tarefas repetitivas sem que o usuário precise pensar nisso. Um estudo recente da Gartner aponta que a IA economiza quase cinco horas por semana para profissionais de vendas — e o e-mail costuma ser o primeiro lugar onde essa economia aparece.

À medida que uma empresa cresce, o volume de mensagens acompanha esse crescimento. Equipes distribuídas em fusos horários diferentes acabam gastando boa parte do dia lendo threads intermináveis, identificando pendências e reconstruindo contextos que uma IA poderia entregar em segundos. É exatamente esse problema que a AWS propõe resolver com a integração entre o Microsoft Outlook e o Amazon Quick.

O que é o Amazon Quick

O Amazon Quick é um assistente de IA generativa da AWS voltado para o ambiente corporativo. Ele se conecta aos dados e sistemas da empresa para responder perguntas, executar ações e automatizar processos em nome do usuário. Ao ser integrado ao Outlook, o Quick passa a atuar diretamente na caixa de entrada: resume threads longas, sugere respostas com contexto relevante, agenda reuniões e aciona fluxos de trabalho em outros sistemas.

A proposta não é apenas de produtividade individual, mas de automação em escala organizacional — desde o atendimento ao cliente até a coordenação entre departamentos.

Visão geral da solução

A integração entre Outlook e Amazon Quick é construída sobre três capacidades principais do serviço, cada uma com um nível diferente de complexidade e automação:

• Amazon Quick Chat Agents: permitem criar assistentes de IA personalizados que redigem respostas contextuais e resumem threads longas sem que o usuário precise sair da caixa de entrada. Esses agentes também acessam bases de conhecimento internas, documentações de produtos e wikis corporativas, o que ajuda a manter consistência e qualidade nas respostas.
• Amazon Quick Flows: permitem construir fluxos de trabalho automatizados para tarefas rotineiras de e-mail, como geração automática de briefings antes de reuniões, extração de itens de ação de threads e roteamento de solicitações de clientes para as equipes corretas.
• Amazon Quick Automate: orquestra processos complexos e de múltiplas etapas que cruzam e-mail, calendário e outros sistemas corporativos. É a camada mais avançada, indicada para automações como onboarding de clientes, aprovações de compras e coordenação entre departamentos.

Pré-requisitos para a integração

Antes de iniciar a configuração, a AWS recomenda verificar os seguintes requisitos:

• Acesso administrativo ao Microsoft Entra Admin Center, o serviço de gerenciamento de identidade e acesso da Microsoft (anteriormente chamado de Azure AD — Diretório Ativo do Azure).
• Permissões de Desenvolvedor de Aplicativos (Application Developer) ou superior no tenant Microsoft da organização.
• Acesso ao Amazon Quick dentro da conta AWS.
• Familiaridade com fluxos de autenticação OAuth 2.0 — o protocolo padrão da indústria que o Quick utiliza para acessar o Outlook de forma segura, sem armazenar senhas. Com ele, o usuário concede permissões específicas (como leitura de e-mails ou gerenciamento de calendário) em vez de compartilhar credenciais.

Passo a passo da configuração

A integração utiliza a Microsoft Graph API para conectar o Outlook ao Amazon Quick via autenticação OAuth 2.0. O processo é dividido em cinco etapas:

Etapa 1: Adicionar o conector do Microsoft Outlook

No menu de navegação do Amazon Quick, acesse Connect apps and data (Conectar aplicativos e dados) e depois Connectors (Conectores). Pesquise por “Outlook” e selecione Connect (Conectar).

Etapa 2: Autorizar a integração

Uma página de login será exibida para que você entre com sua conta do Outlook. Caso já tenha feito login anteriormente com outros endereços, escolha o que deseja utilizar. Para uma configuração inicial, selecione Add account (Adicionar conta) ou Use another account (Usar outra conta) e faça login com seu e-mail e senha.

Etapa 3: Autorizar o acesso do Amazon Quick ao Outlook

Após o login no Outlook, selecione sua conta atual do Amazon Quick para autorizar o acesso ao e-mail do Microsoft Outlook.

Etapa 4: Verificar o status da conexão

Após a autorização, o conector exibirá o status Signed in, Ready (Conectado, Pronto). Opcionalmente, é possível testar a conexão clicando em Try it (Testar).

Etapa 5 (opcional): Testar ações de e-mail no Outlook

Para validar a integração, o usuário pode escolher uma das perguntas de exemplo disponíveis, como verificar e-mails, redigir uma mensagem ou resumir eventos do calendário.

Casos de uso por ferramenta

Com o Outlook integrado ao Amazon Quick, a AWS descreve cenários práticos agrupados por ferramenta:

Quick Chat Agents

• Suporte ao cliente por e-mail: equipes de suporte podem usar os agentes de chat para redigir respostas profissionais e consistentes a solicitações de clientes. O agente acessa a base de conhecimento, documentação de produtos e resoluções anteriores de casos para sugerir respostas contextualmente adequadas, reduzindo o tempo médio de resposta sem abrir mão da qualidade.
• Suporte a comunicações executivas: assistentes executivos e lideranças encontram nos agentes de chat uma forma eficiente de resumir threads longas e identificar itens de ação críticos. Os agentes também redigem comunicações com o tom e a formalidade adequados para diferentes públicos, liberando executivos do gerenciamento excessivo de e-mails.
• Capacitação de equipes de vendas: representantes comerciais podem consultar os agentes diretamente pelo Outlook para obter informações de preços, posicionamento competitivo e histórico de clientes, incorporando esses dados às comunicações com prospects sem precisar alternar entre aplicativos.

Quick Flows

• Briefings automáticos para reuniões: fluxos configurados para rodar antes de reuniões agendadas buscam automaticamente e-mails, documentos e contextos relevantes, compilando um resumo entregue diretamente na caixa de entrada — com potencial de economia de tempo significativa na preparação para reuniões.
• Geração de relatórios de status semanais: fluxos programados podem agregar comunicações por e-mail, extrair atualizações de projetos e compilar relatórios de status, reduzindo o tempo gasto manualmente na compilação de informações por membro de equipe.
• Extração de itens de ação e criação de tarefas: é possível criar fluxos que monitoram e-mails recebidos, identificam compromissos e pendências e criam tarefas automaticamente em ferramentas de gestão de projetos como Asana ou Monday.com, reduzindo prazos perdidos por falta de rastreamento.

Quick Automate

• Orquestração de onboarding de clientes: quando um novo cliente assina um contrato (detectado via e-mail), o Quick Automate dispara automaticamente o provisionamento de conta, agenda reuniões de kickoff, envia comunicações de boas-vindas e notifica stakeholders internos — acelerando o onboarding e reduzindo erros de coordenação manual.
• Coordenação entre departamentos: processos complexos que envolvem múltiplas áreas — como o onboarding de novos colaboradores, que exige coordenação entre RH (Recursos Humanos), TI (Tecnologia da Informação), facilities e o gestor contratante — podem ser orquestrados com o e-mail funcionando tanto como canal de notificação quanto como gatilho para os próximos passos do fluxo.

Recursos adicionais

Para quem quiser se aprofundar no Amazon Quick, a AWS disponibiliza os seguintes materiais:

• Documentação do Amazon Quick
• Preços do Amazon Quick
• Guia do usuário do Quick — com informações sobre suporte a idiomas e outros detalhes úteis

Fonte

Integrating Outlook with Amazon Quick for AI-powered email automation (https://aws.amazon.com/blogs/machine-learning/integrating-outlook-with-amazon-quick-for-ai-powered-email-automation/)

Automações agênticas: o que muda na prática

Automações agênticas representam uma mudança significativa na forma como empresas conduzem seus processos. Em vez de seguir scripts rígidos, agentes de Inteligência Artificial (IA) raciocinam sobre o contexto, adaptam-se a variações e colaboram com pessoas e outros agentes para fazer o trabalho avançar.

O Amazon Quick Automate é a capacidade de automação multi-agente dentro do Amazon Quick. A proposta é ajudar organizações a construir, implantar e manter essas automações em escala, coordenando equipes de agentes entre departamentos, sistemas, interações de interface e API, e aplicações de terceiros.

À medida que times migram de projetos piloto para produção, aplicar os padrões de design corretos desde o início é o que separa automações confiáveis e resilientes de workflows frágeis e imprevisíveis. A AWS publicou um guia com boas práticas para quem está nessa jornada — e a CloudTroop traz os principais pontos aqui.

O processo importa mais do que a tecnologia

O erro mais comum que equipes cometem é pular direto para o design da automação antes de entender de verdade o processo que pretendem automatizar. Construir a automação não é a parte difícil — entender como o processo realmente funciona é o que determina se a automação vai ter sucesso.

Qualidade do processo determina qualidade do agente

O primeiro passo é identificar o processo certo. Boas automações partem de um problema de negócio concreto: alto custo operacional, baixa satisfação do cliente, tempo de resposta lento ou esforço manual que desgasta a equipe.

Processos que se encaixam bem em automações agênticas costumam ter algumas características em comum: coordenam vários sistemas de registro, recebem entradas não estruturadas ou semiestruturadas (como e-mails e documentos), envolvem decisões que exigem julgamento contextual, e lidam com exceções frequentes que scripts tradicionais não tratam bem.

Um exemplo clássico é o processamento de notas fiscais de fornecedores que chegam em PDF: precisam ser cruzadas com ordens de compra, roteadas para aprovação e lançadas no sistema de Planejamento de Recursos Empresariais (ERP). O onboarding de novos colaboradores é outro exemplo, pois aciona trabalho simultâneo em RH, TI e facilities — sistemas que raramente se comunicam entre si.

Antes de construir qualquer coisa, é fundamental definir o que significa sucesso. Metas concretas — redução de tempo de ciclo, menor taxa de erros, maior throughput, menor custo por transação — mantêm o projeto honesto e ajudam a resistir ao escopo crescente.

O passo que equipes mais frequentemente pulam é o design do processo futuro. Migrar de um processo manual para um agêntico não é copiar os passos antigos e adicionar um agente por cima — é uma oportunidade de repensar como o trabalho deve fluir quando um agente capaz está fazendo grande parte dele. Etapas que existiam apenas para conectar sistemas desconectados devem simplesmente desaparecer. Uma boa regra prática: delete cada etapa que puder. Se você não se vê obrigado a adicionar algumas de volta, é porque não cortou o suficiente.

Projete agentes com responsabilidades claras e delimitadas

Um único agente que tenta fazer tudo é difícil de construir, difícil de depurar e difícil de confiar. Também é mais caro de operar, porque um agente genérico precisa de mais instruções, mais ferramentas e geralmente mais etapas de raciocínio para cada tarefa.

O princípio a seguir é que cada agente dentro de uma automação deve ter uma responsabilidade coesa e bem delimitada. Em uma automação de processamento de notas fiscais, por exemplo, um agente lê e estrutura a nota recebida, outro confere os dados extraídos contra ordens de compra e contratos para identificar discrepâncias, e um terceiro decide o caminho de aprovação correto com base em valor e categoria. Cada um desses agentes é pequeno o suficiente para ser testado isoladamente e melhorado sem impactar o restante do workflow.

Dois recursos do Quick Automate tornam agentes focados especialmente eficazes. O primeiro é a capacidade de restringir as instruções, ferramentas e ações disponíveis para cada agente — por exemplo, dar a um agente de extração de documentos acesso ao Amazon Textract ou ao Amazon Bedrock Data Automation, sem expor ferramentas que ele não precisa. O Assistente de Automação cuida de boa parte dessa configuração automaticamente, restringindo as ferramentas adequadas conforme constrói a automação a partir da descrição do processo fornecida.

O segundo recurso é o Structured Output (Saída Estruturada), que permite definir o formato exato dos dados que um agente deve retornar. Um agente de extração pode ser obrigado a produzir nome do fornecedor, número da nota, itens de linha e total em um esquema definido — em vez de texto livre. Isso torna a passagem de dados para a próxima etapa confiável e elimina toda uma categoria de erros de parsing.

Combine agentes com etapas determinísticas

Nem toda etapa de um workflow precisa ser um agente. Uma das forças do Quick Automate é justamente a possibilidade de misturar etapas agênticas com etapas determinísticas — aplicando julgamento onde o trabalho realmente precisa e recorrendo à execução previsível em todo o resto.

O Quick Automate oferece etapas determinísticas que rodam sem um modelo de linguagem. Etapas de código executam lógica exata definida pelo desenvolvedor, ideal para transformações de dados, cálculos e integrações com contrato fixo. Um fluxo de controle determinístico avalia campos estruturados e direciona o trabalho por um caminho fixo sem nenhum raciocínio de modelo — como uma verificação de limite de aprovação que roda da mesma forma em toda execução.

Às vezes o comportamento desejado é justamente que a automação falhe ao encontrar um desvio, em vez de ter um agente improvisando uma solução. Uma etapa determinística oferece exatamente essa parada previsível.

Vale notar que o Quick Automate cobra por hora de agente — ou seja, pela duração da execução, não por tokens. O benefício prático de sequências e etapas determinísticas é que elas rodam rapidamente e encurtam o tempo total de execução.

Uma boa regra prática: se você consegue escrever a regra completamente, use uma etapa determinística. Se a ação correta depende de interpretar conteúdo não estruturado ou pesar contexto, use um agente.

Use revisão humana para casos de alto risco e exceções

Automação totalmente autônoma raramente é a escolha certa para processos de negócio de alto risco. A boa notícia é que não é preciso escolher entre autonomia total e supervisão constante. Com o Quick Automate, é possível incorporar revisão humana no loop (HITL) nos momentos que realmente importam, com dois padrões distintos.

Uma etapa de revisão humana bloqueante faz o agente pausar e aguardar uma resposta antes de continuar. Considere uma nota fiscal que não corresponde a nenhuma ordem de compra claramente: em vez de adivinhar, o agente pausa, apresenta o caso para um revisor financeiro e retoma apenas após confirmação. Liberar um pagamento grande, enviar um contrato ao cliente ou lançar uma correção em um sistema de registro são casos similares.

Uma etapa de revisão humana não bloqueante, por sua vez, notifica uma pessoa e continua para a próxima transação sem esperar. Isso funciona bem quando se quer supervisão sem desacelerar o processo, ou quando o humano responde de forma assíncrona dentro de um prazo.

Decidir quanto de revisão humana incluir é uma questão de calibração. Se você roteia casos demais para humanos, cria falsos positivos — os revisores começam a aprovar tudo sem analisar, o que derrota o propósito. Se roteia de menos, cria falsos negativos — o agente avança em casos que deveria ter escalado, e esses são os erros que destroem a confiança. Comece mais conservador do que você acha necessário e meça com que frequência os revisores realmente mudam a ação proposta pelo agente. Quando os dados mostrarem que o agente é confiável em uma determinada faixa de casos, aumente gradualmente o limiar para tratamento automático.

Onde quer que você coloque uma etapa de revisão, forneça ao revisor contexto suficiente para decidir rapidamente — incluindo as imagens e PDFs originais junto ao resumo do agente. E sempre defina o que acontece quando um revisor não responde a tempo, pois uma etapa bloqueante sem timeout pode travar todo o processo.

Avalie seus workflows agênticos

Como o comportamento de um agente pode variar de uma execução para outra, a avaliação importa mais aqui do que em automações tradicionais. Ela deve ser tratada como uma disciplina contínua, não como um teste único antes do lançamento.

Uma boa avaliação começa com dados representativos — e na maioria dos casos você já os tem. O histórico de trabalho do seu processo fornece um conjunto grande de entradas reais com os resultados que as pessoas chegaram, formando a base do seu conjunto de avaliação. Cubra toda a variedade que os agentes encontrarão em produção: casos limpos, casos confusos, exceções genuínas e entradas inválidas que o agente deve rejeitar. Dados históricos capturam problemas de formatação estranha, campos ausentes e contradições que exemplos sintéticos raramente reproduzem.

O Quick Automate ajuda a avaliar no nível do agente individual por meio do recurso de testes unitários de agente personalizados. Com ele, você define entradas e saídas esperadas para um único agente e o executa em isolamento — confirmando que o agente de extração puxa os campos certos, ou que o agente de roteamento escolhe o caminho correto, antes de montar o workflow completo. Quando você altera as instruções ou ferramentas de um agente, reexecutar os testes unitários indica imediatamente se houve melhora ou regressão.

Construa observabilidade na automação

Automações baseadas em agentes precisam de observabilidade mais profunda do que workflows tradicionais, porque o caminho de um agente por uma tarefa pode diferir de uma execução para outra. Você não pode melhorar o que não consegue ver.

O Quick Automate oferece essa visibilidade como parte do produto. Ele captura cada execução com suas etapas, as ferramentas que cada agente invocou, as entradas recebidas e o caminho tomado até uma decisão. Quando um resultado parece errado, você abre aquela execução específica e vê exatamente o que aconteceu. As métricas fluem para o Amazon CloudWatch, o que significa que você pode monitorar suas automações junto com o restante das ferramentas operacionais, construir dashboards e configurar alarmes sem precisar de um sistema separado.

Gerencie identidade e acesso com cuidado

Agentes que atuam em sistemas corporativos precisam de credenciais, e a forma como você lida com autenticação define tanto a segurança quanto o alcance das suas automações. O Quick suporta dois modelos.

Para automações corporativas que rodam por agendamento ou gatilho sem uma pessoa presente, o Quick suporta autenticação de serviço — a automação em si possui uma identidade e as permissões necessárias para agir. Esse modelo é adequado para processos não supervisionados e sempre ativos, pois a automação pode rodar de forma confiável por conta própria e cada ação é atribuível àquela identidade de serviço.

Para chat, agentes e Flows pessoais que atuam em nome de um indivíduo, o Quick suporta OAuth de três pernas baseado no usuário. A automação opera com o consentimento e o acesso daquele usuário, em vez de uma credencial de serviço compartilhada.

Conclusão

Automatizar processos de negócio com agentes representa uma mudança de scripts rígidos baseados em regras para workflows adaptativos que raciocinam sobre contexto e melhoram com o tempo. As automações que têm sucesso tendem a partir de um problema de negócio real e de um processo-alvo redesenhado. Usam agentes focados com ferramentas restritas e saída estruturada, reservam etapas agênticas para julgamento genuíno e se apoiam em sequências determinísticas em todo o resto. Acima de tudo, aplicam revisão humana onde ela realmente agrega valor e tratam avaliação e observabilidade como disciplinas contínuas.

Para começar, a AWS recomenda visitar o Amazon Quick Automate ou consultar a documentação do Quick Automate.

Fonte

Best practices for building agentic automations with Amazon Quick Automate (https://aws.amazon.com/blogs/machine-learning/best-practices-for-building-agentic-automations-with-amazon-quick-automate/)

Disponibilidade expandida das instâncias P6-B300

A AWS anunciou que as instâncias Amazon EC2 P6-B300 já estão disponíveis na região Ásia-Pacífico (Jacarta). Trata-se de mais um passo na expansão geográfica dessa família de instâncias de alto desempenho voltada para cargas de trabalho de Inteligência Artificial (IA) em larga escala.

O que são as instâncias P6-B300?

As instâncias EC2 P6-B300 são equipadas com 8 GPUs NVIDIA Blackwell Ultra e oferecem uma combinação impressionante de recursos de hardware:

• 2,1 TB de memória GPU de alta largura de banda
• 6,4 Tbps de rede EFA (Elastic Fabric Adapter)
• 300 Gbps de throughput dedicado via ENA (Elastic Network Adapter)
• 4 TB de memória de sistema

Comparadas às instâncias P6-B200, as novas P6-B300 entregam 2x mais largura de banda de rede, 1,5x mais memória GPU e 1,5x mais TFLOPS de GPU (em FP4, sem esparsidade). Esses ganhos tornam as P6-B300 especialmente adequadas para treinar e implantar modelos de fundação (FMs) com trilhões de parâmetros, incluindo Modelos de Linguagem de Grande Escala (LLMs) que utilizam técnicas sofisticadas de treinamento.

Por que isso importa para cargas de trabalho de IA?

A combinação de maior largura de banda de rede com memória GPU ampliada resulta em dois benefícios práticos e diretos: tempos de treinamento mais rápidos e maior throughput de tokens para aplicações de IA. Para equipes que trabalham com modelos generativos de grande porte, essas melhorias têm impacto real no custo e na velocidade dos ciclos de desenvolvimento.

Regiões disponíveis e tamanho de instância

As instâncias P6-B300 estão disponíveis no tamanho p6-b300.48xlarge nas seguintes regiões AWS:

• US West (Oregon)
• AWS GovCloud (US-East)
• US East (N. Virginia)
• Asia Pacific (Hyderabad, Jacarta, Seul)
• América do Sul (São Paulo)

Vale destacar que a região de São Paulo já conta com suporte às P6-B300, o que é uma boa notícia para times brasileiros e latino-americanos que precisam manter dados e processamento dentro da América do Sul.

Saiba mais

Para conhecer todos os detalhes técnicos e verificar a disponibilidade atualizada, a AWS disponibiliza a documentação oficial das instâncias. Acesse instâncias Amazon EC2 P6 para mais informações.

Fonte

Amazon EC2 P6-B300 instances are now available in the AWS Asia Pacific (Jakarta) Region (https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-ec2-p6-b300-instances-available-asia-pacific-jakarta)

Expansão das instâncias P6-B200 para mais uma região AWS

A AWS anunciou que as instâncias Amazon EC2 P6-B200, aceleradas pelas GPUs NVIDIA Blackwell, estão agora disponíveis na região Ásia-Pacífico (Hyderabad). Para equipes que desenvolvem e executam cargas de trabalho de Inteligência Artificial na Índia ou em regiões próximas, essa é uma novidade relevante: mais poder computacional com menor latência geográfica.

O que torna as instâncias P6-B200 especiais

Em comparação com as instâncias P5en — que já eram referência em workloads de IA — as P6-B200 entregam até 2x mais desempenho tanto para treinamento quanto para inferência de modelos de Inteligência Artificial (IA). Esse salto de desempenho é resultado de uma combinação de hardware de ponta:

• 8 GPUs NVIDIA Blackwell por instância
• 1.440 GB de memória de GPU de alta largura de banda
• 60% mais largura de banda de memória de GPU em relação às P5en
• Processadores Intel Xeon de 5ª Geração (codinome Emerald Rapids)
• Até 3,2 terabits por segundo de rede via Adaptador de Malha Elástica (EFAv4)

Escalabilidade segura com o AWS Nitro System

As instâncias P6-B200 são alimentadas pelo AWS Nitro System, a arquitetura de virtualização proprietária da AWS que garante isolamento de segurança e desempenho consistente. Graças a isso, é possível escalar cargas de trabalho de IA de forma confiável dentro dos Amazon EC2 UltraClusters, chegando a dezenas de milhares de GPUs trabalhando em conjunto.

Esse nível de escala é especialmente relevante para organizações que treinam modelos de linguagem de grande porte (LLMs) ou executam pipelines de inferência em larga escala.

Regiões disponíveis e tamanho de instância

As instâncias P6-B200 estão disponíveis no tamanho p6-b200.48xlarge nas seguintes regiões AWS:

• US West (Oregon)
• US East (N. Virginia e Ohio)
• AWS GovCloud (US-West e US-East)
• Ásia-Pacífico (Hyderabad e Mumbai)

Para times brasileiros que operam com requisitos de latência para o mercado asiático ou que utilizam as regiões de Mumbai e Hyderabad como base, a disponibilidade nessas localidades amplia as opções de arquitetura sem abrir mão do desempenho.

Saiba mais

Para conhecer todos os detalhes técnicos, especificações e casos de uso das instâncias P6-B200, a AWS disponibiliza documentação completa. Acesse a página oficial das instâncias Amazon EC2 P6 para aprofundar o conhecimento.

Fonte

Amazon EC2 P6-B200 instances are now available in the AWS Asia Pacific (Hyderabad) Region (https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-ec2-p6-b200-instances-available-asia-pacific-hyderabad)

O problema que o AgentCore resolve na prática

Equipes de engenharia que tentam adotar o Ciclo de Desenvolvimento Orientado por Inteligência Artificial (AI-DLC) frequentemente esbarram num obstáculo concreto: a distância entre a teoria e o código que realmente funciona. O Amazon Bedrock AgentCore é o serviço da AWS voltado para construir, conectar e otimizar agentes em escala, com suporte a qualquer framework ou modelo. O AI-DLC posiciona a IA como colaboradora central ao longo do ciclo de vida do desenvolvimento de software, assumindo a execução de tarefas rotineiras enquanto humanos mantêm o controle das decisões críticas.

Para fechar essa lacuna entre conceito e implementação, a AWS publicou duas implementações de referência que demonstram padrões concretos da fase de construção do AI-DLC usando o Amazon Bedrock AgentCore, o Kiro e ferramentas de codificação agêntica local. Este artigo percorre a arquitetura, as decisões de design e os padrões de código por trás dessas duas soluções.

Padrões de construção AI-DLC na prática

Na fase de construção do AI-DLC, a IA propõe arquiteturas, gera planos de implementação, produz código e cria artefatos de implantação, enquanto os membros da equipe fornecem orientação em tempo real sobre decisões técnicas. As duas implementações mapeiam diretamente esse padrão:

• Geração automatizada de artefatos: um agente recebe entrada estruturada (arquivos de esquema SQL), cria um plano detalhado, gera a saída (diagramas ER em Mermaid) e armazena os resultados para revisão humana.
• Verificação contínua de qualidade de código: um sistema multi-agente analisa código enviado por pipelines de Integração Contínua e Entrega Contínua (CI/CD), produzindo avaliações de segurança, verificações de Vulnerabilidades e Exposições Comuns (CVE) e relatórios de conformidade de políticas.

Ambos os sistemas compartilham uma base arquitetural comum construída sobre o AgentCore, demonstrando como equipes podem compor fluxos orientados por IA a partir de componentes modulares e gerenciáveis.

Solução 1: geração de diagrama ER a partir de esquema SQL

O primeiro projeto auto-gera diagramas ER em Mermaid a partir de arquivos de esquema SQL usando um fluxo de trabalho agêntico no Amazon Bedrock AgentCore. Após o desenvolvedor fazer o commit do código SQL, um gatilho no Amazon Simple Storage Service (Amazon S3) aciona uma função AWS Lambda que invoca o runtime do AgentCore. O agente analisa as instruções de Linguagem de Definição de Dados (DDL) e produz um arquivo .mmd salvo de volta no Amazon S3. O sistema lê apenas metadados do esquema — tabelas, restrições e chaves estrangeiras — nunca dados de linha.

Desafio de negócio

Times de banco de dados que gerenciam esquemas SQL em evolução precisam de documentação de relacionamento entre entidades sempre atualizada. A criação manual de diagramas ER é demorada e a documentação frequentemente fica defasada em relação ao esquema real. Quando mudanças chegam via pull requests, as equipes precisam de diagramas atualizados sem adicionar etapas manuais ao fluxo de desenvolvimento.

Arquitetura da Solução 1

O sistema usa uma arquitetura serverless orientada a eventos com os seguintes componentes:

• Gatilho S3: arquivos SQL enviados a um bucket Amazon S3 acionam uma função AWS Lambda que inicia o fluxo de análise.
• Autenticação: o Amazon Cognito fornece autenticação máquina a máquina (M2M) via OAuth2. As credenciais do cliente ficam armazenadas no AWS Systems Manager Parameter Store.
• Runtime do AgentCore: um agente em container construído com o framework Strands roda no runtime do AgentCore. O agente usa o Claude Sonnet 4 via Amazon Bedrock para analisar instruções DDL e gerar a sintaxe do diagrama ER em Mermaid. (Para disponibilidade do modelo por região AWS, consulte a disponibilidade regional por modelos.)
• Memória do AgentCore: fornece contexto de sessão persistente com validade de 90 dias, além de suporte a busca semântica em análises anteriores e compreensão incremental do esquema.
• Armazenamento de saída: os arquivos .mmd gerados são salvos no Amazon S3 com metadados rastreando o arquivo de origem e o timestamp de geração.

Detalhes de implementação

A implementação do agente usa o wrapper de runtime BedrockAgentCoreApp com o decorador @app.entrypoint para registrar o handler:

from bedrock_agentcore.runtime import BedrockAgentCoreApp
from bedrock_agentcore.memory import MemoryClient
from strands import Agent
from strands.models import BedrockModel

app = BedrockAgentCoreApp()
model = BedrockModel(model_id="us.anthropic.claude-sonnet-4-5-20250929-v1:0", region_name="us-west-2")
erdiagram_agent = Agent(model=model)
memory_client = MemoryClient(region_name="us-west-2")

@app.entrypoint
async def generate_er_diagram(payload: Dict[str, Any]) -> Dict[str, Any]:
    sql_content = payload.get("sql_content", "")
    file_name = payload.get("file_name", "unknown_file.sql")
    # Generate diagram, store in memory, save to S3
    ...

As principais decisões de design incluem:

• Processamento em chunks: arquivos SQL grandes são divididos em segmentos gerenciáveis, analisados independentemente e depois consolidados em um diagrama unificado. Isso permite lidar com esquemas de centenas de tabelas sem ultrapassar os limites de contexto.
• Prompting estruturado: o agente usa um prompt de análise sistemático que extrai tabelas, colunas, tipos de dados, chaves primárias e relacionamentos de chave estrangeira antes de gerar a sintaxe do diagrama.
• Rastreamento com OpenTelemetry: cada etapa é instrumentada com spans e atributos, oferecendo observabilidade sobre duração do processamento, contagem de chunks e atribuição de erros.

A implementação completa, incluindo skills do OpenAI Codex e integração com servidor MCP (Protocolo de Contexto de Modelo), está disponível no repositório no GitHub.

Solução 2: handoffs seguros de software

A segunda solução é um sistema serverless de análise de segurança de código que usa o Amazon Bedrock AgentCore para escanear automaticamente código Python ou Java em busca de vulnerabilidades de segurança, riscos de CVE em dependências e violações de políticas. A análise é acionada quando código é enviado de um pipeline GitLab para o Amazon S3. Um agente baseado no framework Strands então avalia o código usando modelos Anthropic Claude Sonnet no Amazon Bedrock, chamando ferramentas MCP que rodam no AWS Lambda para verificações de CVE e políticas. (Para disponibilidade por região, consulte a disponibilidade regional por modelos.)

Os resultados — incluindo pontuações de qualidade de 1 a 10 e recomendações — são armazenados na memória do AgentCore com busca semântica e exibidos em um dashboard web em tempo real baseado em sessão. O Amazon Cognito cuida da autenticação, enquanto o AgentCore Observability e o Amazon CloudWatch fornecem monitoramento.

Desafio de negócio

Revisões de código para conformidade de segurança exigem conhecimento especializado em bases de dados CVE, políticas de codificação organizacionais e padrões de segurança específicos de cada linguagem. Revisões manuais criam gargalos nos pipelines de entrega, e a aplicação inconsistente de padrões entre equipes leva a variações na qualidade do código.

Arquitetura da Solução 2

Esta solução oferece análise automatizada de segurança de código por meio de uma arquitetura multi-agente para handoffs seguros de software entre estágios de desenvolvimento:

• Arquivos de código são enviados a um bucket Amazon S3 (manualmente ou via pipeline CI/CD).
• Um gatilho AWS Lambda detecta novos uploads e inicia o fluxo de análise do AgentCore com autenticação OAuth2.
• AgentCore Gateway com ferramentas MCP: o gateway orquestra chamadas a integrações externas — uma Lambda de verificação de políticas e uma Lambda de verificação de banco de dados CVE.
• Runtime do AgentCore (framework Strands): o agente central realiza revisão profunda de código, incluindo avaliação de estrutura, qualidade lógica, análise de memória e desempenho, detecção de problemas de segurança e conformidade com boas práticas.
• Memória do AgentCore: armazena resultados de análise com capacidades de busca semântica, suportando comparação histórica e análise de tendências.
• Lambda de Dashboard: serve uma interface web que exibe resultados baseados em sessão com navegação em múltiplas abas por arquivos, violações e métricas de qualidade.

Capacidades principais

O sistema avalia código em múltiplas dimensões: qualidade estrutural, eficiência algorítmica, postura de segurança e conformidade com padrões. Três estratégias de memória distintas atendem a necessidades diferentes:

• Estratégia semântica: armazena descobertas detalhadas de análise de código, resultados de CVE e violações de políticas para recuperação por contexto.
• Estratégia de resumo: mantém métricas agregadas e tendências para visualização no dashboard.
• Estratégia de preferências do usuário: rastreia layout do dashboard e preferências de filtro entre sessões.

Para saber mais, consulte a documentação sobre estratégias de memória do AgentCore.

Detalhes de implementação

O agente de análise segue o mesmo padrão de runtime do AgentCore da Solução 1, com o acréscimo de chamadas a ferramentas MCP roteadas pelo AgentCore Gateway:

from bedrock_agentcore.runtime import BedrockAgentCoreApp
from bedrock_agentcore.memory import AgentCoreMemory
from strands import Agent
from strands.models import BedrockModel

app = BedrockAgentCoreApp()
model = BedrockModel(model_id="us.anthropic.claude-sonnet-4-5-20250929-v1:0", region_name="us-west-2")
analysis_agent = Agent(model=model, tools=[analyze_code, check_quality])
memory = AgentCoreMemory(namespace="code-analysis")

@app.entrypoint
async def analyze_uploaded_code(payload: Dict[str, Any]) -> Dict[str, Any]:
    file_content = payload.get("file_content", "")
    file_name = payload.get("file_name", "unknown.py")
    session_id = payload.get("session_id", "")
    # Analyze code, store results in memory, return quality score
    ...

As principais decisões de design incluem separação de responsabilidades entre agentes (o agente de análise foca apenas em qualidade; verificação de políticas e CVE são delegadas a funções Lambda dedicadas), persistência de resultados por sessão e invocação de ferramentas externas mediada pelo Gateway usando MCP — o que desacopla o agente dos detalhes de implementação das ferramentas e permite adicionar novas ferramentas sem modificar o código do agente.

A implementação completa está disponível no repositório no GitHub.

Ferramentas agênticas locais: Kiro, OpenAI Codex e Claude Code

Enquanto o AgentCore fornece o runtime em nuvem para cargas de trabalho agênticas implantadas e orientadas a eventos, o fluxo de desenvolvimento em si se beneficia de ferramentas agênticas locais que implementam padrões AI-DLC na estação de trabalho do desenvolvedor.

Kiro

O Kiro suporta as fases de concepção e construção do AI-DLC por meio de especificações estruturadas e skills de agente customizadas. Ele transforma requisitos em linguagem natural em especificações estruturadas com critérios de aceitação, e depois gera planos de implementação a partir dessas especificações — mapeando diretamente o padrão AI-DLC de a IA criar planos e buscar validação humana antes da execução. Equipes também podem definir skills de agente reutilizáveis que codificam padrões organizacionais para que o código gerado por IA atenda consistentemente aos requisitos de qualidade corporativos.

OpenAI ChatGPT Codex

O repositório inclui uma integração com o OpenAI Codex que demonstra como o mesmo fluxo de geração de diagramas ER se estende a outros agentes de codificação via MCP e skills customizadas. Um servidor MCP local baseado em stdio conecta o Codex a bancos de dados MySQL ou Amazon Aurora MySQL por meio do INFORMATION_SCHEMA, expondo três ferramentas (schema_summary, generate_er_markdown e generate_mermaid) sem acessar dados de linha. As credenciais de banco de dados são recuperadas do AWS Secrets Manager com verificação TLS.

Claude Code

O Claude Code opera como agente local de linha de comando que complementa implantações no AgentCore: antes de implantar no runtime do AgentCore, desenvolvedores usam o Claude Code para iterar sobre lógica de agentes, testar prompts e validar padrões de integração de ferramentas localmente. Ele também gera scripts de implantação, Dockerfiles, políticas do AWS Identity and Access Management (IAM) e templates do AWS CloudFormation, além de realizar revisões de primeira passagem antes que o código entre no pipeline CI/CD.

O fluxo combinado

Um ciclo típico de trabalho AI-DLC usando essas ferramentas segue este padrão:

• Concepção (Kiro): transformar requisitos de negócio em especificações com critérios de aceitação, validadas pela equipe.
• Construção (Claude Code e Kiro): gerar código de implementação, scripts de implantação e suítes de teste.
• Validação (AgentCore): código enviado via CI/CD aciona análise automatizada de segurança, com avaliação de qualidade antes do merge.
• Operações (AgentCore): agentes em produção rodam continuamente no runtime do AgentCore, acionados por eventos, processando cargas de trabalho em escala com observabilidade completa.

Boas práticas

Com base nas implementações descritas, a AWS recomenda as seguintes práticas:

• Separe as responsabilidades dos agentes: projete cada agente com uma única responsabilidade bem definida. A composabilidade vem da orquestração, não de sobrecarregar agentes individuais.
• Use a memória do AgentCore para continuidade de contexto: memória persistente permite que agentes aprendam com interações anteriores e mantenham estado entre sessões sem reprocessar tudo.
• Instrumente com OpenTelemetry desde o início: rastreamento fornece visibilidade sobre o comportamento do agente, duração do processamento e modos de falha.
• Armazene configuração no Parameter Store: desacople configuração do código. Credenciais do Cognito, IDs de memória, seleções de modelo e nomes de buckets devem ser recuperáveis em tempo de execução.
• Implemente processamento em chunks para entradas grandes: projete agentes para lidar com entradas que excedam janelas de contexto do modelo dividindo, analisando independentemente e consolidando resultados.
• Proteja com autenticação M2M do Cognito: use o fluxo de credenciais de cliente OAuth2 para comunicação serviço a serviço. Evite credenciais hardcoded ou tokens de longa duração.
• Integre via CI/CD, não por upload manual: em produção, conecte agentes a eventos de repositório em vez de exigir uploads manuais de arquivos.
• Aplique Amazon Bedrock Guardrails para saídas de agentes em produção: configure políticas de filtragem de conteúdo, detecção de tópicos negados e validação de fundamentação para garantir que respostas geradas por agentes atendam aos padrões de IA responsável.

Conclusão

A metodologia AI-DLC se torna prática quando respaldada por padrões concretos de implementação. O Amazon Bedrock AgentCore fornece a infraestrutura de runtime — agentes em container, memória persistente, gateways seguros e integração com ferramentas externas — enquanto ferramentas locais como Kiro e Claude Code aceleram o próprio fluxo de desenvolvimento.

Para começar, a AWS sugere partir pelo exemplo SQL-to-ER-Diagram para implantar o primeiro agente AgentCore, depois estender o padrão com coordenação multi-agente, integrações MCP e gatilhos orientados a CI/CD usando o exemplo de Handoffs Seguros de Software. Para aprofundar, a AWS publicou um guia complementar sobre como levar agentes de IA do proof of concept à produção com o Amazon Bedrock AgentCore. Para detalhes completos do serviço, referências de API e orientações de configuração, consulte a documentação do Amazon Bedrock AgentCore.

Fonte

AI-driven development lifecycle using Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/ai-driven-development-lifecycle-using-amazon-bedrock-agentcore/)

Modelos OpenAI disponíveis no Bedrock a partir da Austrália

A AWS anunciou que equipes australianas que trabalham com modelos OpenAI podem agora acessar as versões mais recentes diretamente pelo Amazon Bedrock. Os modelos disponíveis são o GPT-5.6 Sol, o Terra e o Luna, todos acessíveis com inferência global entre regiões (global cross-Region inference) a partir das regiões AWS da Ásia-Pacífico (Sydney) e Ásia-Pacífico (Melbourne).

O funcionamento é direto: a aplicação faz a chamada ao endpoint do Amazon Bedrock Runtime em Sydney ou Melbourne, e o próprio Bedrock se encarrega de rotear a requisição para uma região comercial AWS suportada. Isso amplia o acesso a um pool de capacidade maior sem que as aplicações precisem gerenciar o roteamento de destino manualmente.

Cada modelo tem um perfil de uso bem definido:

• GPT-5.6 Sol: voltado para cargas de trabalho exigentes de raciocínio, codificação e agentes autônomos.
• Terra: equilibra desempenho e custo para uso em produção no dia a dia.
• Luna: oferece inferência rápida e econômica para aplicações de alto volume e sensíveis à latência.

Os três modelos aceitam entradas de texto e imagem, geram texto e suportam janelas de contexto de até 1 milhão de tokens.

Perfis de inferência global GPT-5.6

A tabela abaixo lista os três IDs de perfil global e as regiões de origem australianas cobertas:

• global.openai.gpt-5.6-sol
• global.openai.gpt-5.6-terra
• global.openai.gpt-5.6-luna

As regiões de origem são Ásia-Pacífico (Sydney) — ap-southeast-2 — e Ásia-Pacífico (Melbourne) — ap-southeast-4. As requisições são roteadas para regiões comerciais AWS suportadas. Vale destacar que a disponibilidade dos perfis pode mudar; consulte a documentação de suporte à inferência entre regiões antes de colocar em produção.

Pré-requisitos

Antes de começar, é recomendado seguir o post sobre GPT-5.6 para configurar os seguintes itens:

• Uma conta AWS com a região Ásia-Pacífico (Sydney) ou Ásia-Pacífico (Melbourne) habilitada como região de origem.
• Se a organização usa Política de Controle de Serviço (SCP — Service Control Policy), verifique se ela permite os perfis de inferência global do GPT-5.6 na região selecionada.
• Uma função ou usuário do Gerenciamento de Identidade e Acesso da AWS (IAM — Identity and Access Management) com permissões adequadas para invocar os perfis de inferência do GPT-5.6.
• Python 3.9 ou superior com os pacotes openai, boto3 e aws-bedrock-token-generator instalados.

Verificando os perfis de inferência ativos

Via Interface de Linha de Comando da AWS (AWS CLI)

Os comandos a seguir listam os perfis GPT-5.6 ativos e inspecionam o perfil Terra a partir da região Sydney. Para usar Sol ou Luna, basta alterar o ID do perfil. Para executar a mesma verificação a partir de Melbourne, substitua ap-southeast-2 por ap-southeast-4.

aws bedrock list-inference-profiles \
  --region ap-southeast-2 \
  --type-equals SYSTEM_DEFINED \
  --query "inferenceProfileSummaries[?contains(inferenceProfileId, 'openai.gpt-5.6')].[inferenceProfileId,status]" \
  --output table

aws bedrock get-inference-profile \
  --region ap-southeast-2 \
  --inference-profile-identifier global.openai.gpt-5.6-terra

Via console do Amazon Bedrock

No console do Amazon Bedrock, selecione Sydney ou Melbourne como região, acesse Inference profiles em Infer e filtre por Global OpenAI GPT-5.6 Terra para visualizar o perfil ativo na região de origem.

Invocando o GPT-5.6 pelo Amazon Bedrock Runtime

O GPT-5.6 suporta três caminhos de acesso pelo endpoint do Amazon Bedrock Runtime: a Responses API da OpenAI, a Chat Completions API da OpenAI e a Converse API do Amazon Bedrock. As APIs compatíveis com OpenAI são chamadas nos caminhos /openai/v1 desse endpoint — não pelos SDKs da AWS. O endpoint aceita tanto AWS Signature Version 4 (SigV4) quanto uma chave de API de inferência de modelo do Amazon Bedrock.

Os exemplos a seguir utilizam o AWS Bedrock Token Generator para Python para criar uma chave de API de inferência de curta duração a partir das credenciais AWS atuais, eliminando a necessidade de armazenar uma chave estática.

OpenAI Responses API

Para aplicações que já utilizam o SDK da OpenAI com a Responses API, basta apontar o cliente para o endpoint regional do Amazon Bedrock Runtime:

from aws_bedrock_token_generator import provide_token
from openai import OpenAI

region = "ap-southeast-2"  # Use "ap-southeast-4" for Melbourne.
model_id = "global.openai.gpt-5.6-terra"
prompt = (
    "In three short bullet points, explain how Availability Zones "
    "help make an AWS application highly available."
)

openai_client = OpenAI(
    base_url=f"https://bedrock-runtime.{region}.amazonaws.com/openai/v1",
    api_key=provide_token(region=region),
)

responses_result = openai_client.responses.create(
    model=model_id,
    input=prompt,
    max_output_tokens=300,
)
print(responses_result.output_text)

Para saída em streaming, defina stream=True e itere sobre os eventos de resposta:

response_stream = openai_client.responses.create(
    model=model_id,
    input=prompt,
    max_output_tokens=300,
    stream=True,
)
for event in response_stream:
    if event.type == "response.output_text.delta":
        print(event.delta, end="", flush=True)

OpenAI Chat Completions API

Para aplicações que já utilizam a Chat Completions API:

from aws_bedrock_token_generator import provide_token
from openai import OpenAI

region = "ap-southeast-2"  # Use "ap-southeast-4" for Melbourne.
model_id = "global.openai.gpt-5.6-terra"
prompt = (
    "In three short bullet points, explain how Availability Zones "
    "help make an AWS application highly available."
)

openai_client = OpenAI(
    base_url=f"https://bedrock-runtime.{region}.amazonaws.com/openai/v1",
    api_key=provide_token(region=region),
)

chat_result = openai_client.chat.completions.create(
    model=model_id,
    messages=[{"role": "user", "content": prompt}],
    max_completion_tokens=300,
    reasoning_effort="low",
)
print(chat_result.choices[0].message.content)

Amazon Bedrock Converse API

Para aplicações que já utilizam o SDK da AWS, a Converse API é a opção recomendada. O Boto3 resolve as credenciais pela cadeia padrão de credenciais AWS:

import boto3

region = "ap-southeast-2"  # Use "ap-southeast-4" for Melbourne.
model_id = "global.openai.gpt-5.6-terra"
prompt = (
    "In three short bullet points, explain how Availability Zones "
    "help make an AWS application highly available."
)

messages = [
    {
        "role": "user",
        "content": [{"text": prompt}],
    }
]

bedrock_client = boto3.client("bedrock-runtime", region_name=region)
converse_result = bedrock_client.converse(
    modelId=model_id,
    messages=messages,
    inferenceConfig={"maxTokens": 300},
)
print(converse_result["output"]["message"]["content"][0]["text"])

Para saída em streaming com a Converse API, use converse_stream com a mesma região e ID de perfil, iterando sobre o stream de eventos retornado:

stream_result = bedrock_client.converse_stream(
    modelId=model_id,
    messages=messages,
    inferenceConfig={"maxTokens": 300},
)
for event in stream_result["stream"]:
    if "contentBlockDelta" in event:
        delta = event["contentBlockDelta"]["delta"]
        if "text" in delta:
            print(delta["text"], end="", flush=True)
print()

Para executar qualquer um dos exemplos acima a partir de Melbourne, basta definir a região como ap-southeast-4.

Trabalhando com cache de prompts

O cache de prompts (prompt caching) do GPT-5.6 está disponível pelas APIs suportadas. O modelo oferece dois modos no Amazon Bedrock: o cache implícito, habilitado por padrão sem necessidade de alterações no código, e o cache explícito, no qual é possível definir o prefixo reutilizável, o limite de cache e a chave de cache. O post sobre GPT-5.6 traz exemplos que ilustram essa capacidade.

Configurando o Codex com GPT-5.6 no Amazon Bedrock

O Codex pode usar os mesmos perfis de inferência global pelo Amazon Bedrock Runtime. Para isso, instale a versão mais recente do Codex CLI com suporte nativo ao provedor Amazon Bedrock Runtime:

npm install -g @openai/codex@alpha
codex --version

Para organizações cujo provedor de identidade é Okta, Auth0, Microsoft Entra ID, Amazon Cognito ou AWS IAM Identity Center, o repositório AWS OIDC Auth Helper disponibiliza um auxiliar de credenciais de exemplo. Após configurar o provedor de identidade, o recurso de federação AWS correspondente e uma função IAM com as permissões necessárias no Bedrock, adicione um perfil nomeado ao arquivo ~/.aws/config:

[profile <AWS_OIDC_PROFILE>]
credential_process = <ABSOLUTE_PATH_TO_CREDENTIAL_PROCESS> --profile <OIDC_HELPER_PROFILE>
region = ap-southeast-2
output = json

Esse auxiliar de federação troca um token OpenID Connect (OIDC — OpenID Connect) por credenciais AWS temporárias, e o Codex as lê pela cadeia padrão de credenciais AWS sem configuração adicional. Em seguida, crie ou atualize o arquivo ~/.codex/config.toml referenciando o perfil AWS — consulte a referência de configuração do Codex para outras opções suportadas:

model = "global.openai.gpt-5.6-sol"
model_provider = "amazon-bedrock-runtime"
model_reasoning_effort = "high"

[model_providers.amazon-bedrock-runtime.aws]
profile = "<AWS_OIDC_PROFILE>"
region = "ap-southeast-2"

Se o auxiliar não tiver uma sessão em cache válida, ele abrirá a página de login configurada no navegador. Após a autenticação, as credenciais AWS temporárias são retornadas via credential_process. As requisições são assinadas com AWS SigV4, sem envolvimento de chave de API no caminho de inferência. Para usar com Melbourne, defina a região como ap-southeast-4 tanto no perfil AWS quanto na configuração do Codex.

Gerenciamento de cotas

As cotas sob demanda do GPT-5.6 são medidas em requisições por minuto (RPM — Requests Per Minute) e tokens por minuto (TPM — Tokens Per Minute). O consumo de tokens é calculado a partir dos tokens de entrada, tokens de entrada gravados em cache e tokens de saída multiplicados pela taxa de consumo (burndown rate) do modelo. Para o GPT-5.6, tokens de entrada e tokens de entrada gravados em cache contam na proporção 1:1, enquanto cada token de saída consome 10 tokens da cota.

É recomendado revisar as cotas do GPT-5.6 no console do Service Quotas a partir da região de origem utilizada pela aplicação: Ásia-Pacífico (Sydney) — ap-southeast-2 — ou Ásia-Pacífico (Melbourne) — ap-southeast-4. Antes de ir para produção, solicite aumentos de cota com antecedência, monitore a utilização e teste prompts representativos, tamanhos de saída, comportamento de streaming, concorrência e tráfego de pico. Consulte as cotas do Amazon Bedrock para os valores atuais e taxas de consumo de tokens.

Monitoramento e registro de logs

Como as requisições do GPT-5.6 utilizam a API do Amazon Bedrock Runtime, as chamadas feitas pelos perfis de inferência global aparecem no registro de invocações de modelos (model invocation logging) como qualquer outra requisição sob demanda. Com o logging habilitado, os registros incluem o ID do modelo ou perfil de inferência utilizado na chamada e os metadados de invocação.

O Codex usa OpenTelemetry (OTel) e exporta métricas via OTLP/HTTP — veja como configurar o OpenTelemetry para o OpenAI Codex para mais detalhes. O CloudWatch Coding Agent Insights oferece um painel para telemetria do Codex, incluindo uso de tokens, requisições de API, usuários ativos, atividade de conversas e dimensões organizacionais opcionais.

Há dois caminhos para configurar o Coding Agent Insights no CloudWatch para o Codex: usando Bearer token ou rollout empresarial (Enterprise rollout). O exemplo abaixo demonstra a abordagem com Bearer token. Primeiro, obtenha uma chave de API de métricas do CloudWatch e, em seguida, adicione as seguintes seções ao arquivo ~/.codex/config.toml:

[otel]
environment = "production"

[otel.metrics_exporter]
otlp-http = { endpoint = "https://monitoring.ap-southeast-2.amazonaws.com/v1/metrics", protocol = "binary", headers = { "Authorization" = "Bearer YOUR_CLOUDWATCH_METRICS_API_KEY" } }

Substitua YOUR_CLOUDWATCH_METRICS_API_KEY pela chave criada no CloudWatch e inicie o Codex. Essa chave autoriza a exportação para o endpoint regional do CloudWatch. Após a chegada da telemetria, acesse o console do CloudWatch na região Ásia-Pacífico (Sydney), selecione GenAI Observability, depois Coding Agent Insights e a aba Codex. O painel exibirá uso de tokens, atividade de requisições, taxa de acerto de cache e muito mais.

Para popular os filtros de Organization, Environment, Department, Cost Center, Location, Team e User, forneça os valores correspondentes por meio de OTEL_RESOURCE_ATTRIBUTES. A AWS classifica a chave de API de métricas do CloudWatch como credencial de longa duração e recomenda seu uso apenas quando credenciais de curta duração não são viáveis. Trate o config.toml como segredo e restrinja suas permissões de arquivo. Para organizações que federam a identidade dos desenvolvedores via single sign-on corporativo, o rollout empresarial é a abordagem recomendada — nesse caso, um coletor local assina a exportação com SigV4 usando as credenciais federadas do desenvolvedor, sem distribuição de token.

Conclusão

A AWS demonstrou como descobrir e invocar os perfis de inferência global GPT-5.6 Sol, Terra e Luna a partir das regiões Ásia-Pacífico (Sydney) e Ásia-Pacífico (Melbourne). Também foi apresentado como configurar o Codex para usar o Amazon Bedrock Runtime e exportar a telemetria do Codex para o CloudWatch Coding Agent Insights. Para começar, siga os exemplos deste artigo e teste os modelos GPT-5.6 na sua conta. Se você já utiliza o Codex, configure o provedor Amazon Bedrock Runtime e habilite o CloudWatch Coding Agent Insights no Console AWS para monitorar o consumo. Para detalhes de preços, consulte a página de preços do Amazon Bedrock.

Fonte

Accessing OpenAI models on Amazon Bedrock from Australia with global cross-Region inference (https://aws.amazon.com/blogs/machine-learning/accessing-openai-gpt-5-6-models-on-amazon-bedrock-from-australia-with-global-cross-region-inference/)

O problema que toda equipe de suporte conhece

Escalar operações de suporte sem aumentar proporcionalmente o número de pessoas é um dos maiores desafios de times de TI e operações. O volume de chamados cresce, os Acordos de Nível de Serviço (SLA) ficam mais exigentes, as regulamentações mudam — e a documentação nunca acompanha esse ritmo.

Na prática, o conhecimento necessário para resolver um chamado está espalhado por Procedimentos Operacionais Padrão (SOP) desatualizados, gravações de treinamento que ninguém mais assiste e na cabeça de dois ou três analistas seniores. O resultado é previsível: analistas juniores escalam tudo, seniores viram gargalos e a qualidade do atendimento oscila conforme quem está de plantão.

Para endereçar esse cenário, a AWS publicou uma arquitetura detalhada de solução baseada em IA generativa que ataca o problema de forma sistêmica — não otimizando chamados individualmente, mas redesenhando os processos que determinam como o trabalho flui entre equipes.

A solução em duas camadas

A arquitetura proposta organiza a solução em duas camadas fortemente integradas: um espaço de trabalho de inteligência operacional, usado pelos analistas no dia a dia, e uma camada de analytics e inteligência de decisão, voltada tanto para analistas quanto para líderes. O que diferencia essa abordagem é que as duas camadas formam um ciclo: a inteligência gerada em uma alimenta e melhora a outra continuamente.

Camada 1: Espaço de trabalho de inteligência operacional

Essa camada é construída sobre o Amazon Bedrock e o AWS Strands Agents SDK, e reúne três capacidades principais.

1.1 Conversão automática de vídeos em SOPs

Equipes de suporte dependem fortemente de gravações de tela, sessões de treinamento e demonstrações ao vivo para transferir conhecimento. O problema é que esse conteúdo fica preso em arquivos de vídeo que ninguém tem tempo de rever — e quando alguém precisa, já está desatualizado.

A ferramenta Video-to-SOP resolve isso com um pipeline multimodal automatizado construído sobre o Amazon Bedrock. Quando um vídeo é carregado, ele é processado pelo modelo Marengo Embed 2.7, que divide o vídeo em segmentos configuráveis e gera embeddings vetoriais densos representando simultaneamente o conteúdo visual, a fala e o contexto da interface. Esses embeddings são indexados no Amazon OpenSearch Serverless, criando uma base de conhecimento pesquisável a partir de toda a biblioteca de vídeos históricos.

Em paralelo, o mesmo vídeo é analisado pelo modelo Pegasus 1.2, responsável pela compreensão generativa: ele produz resumos passo a passo, segmentação por capítulos e descrições estruturadas de ações e estados da interface, extraindo metadados operacionais como entradas necessárias, saídas do sistema, lógica condicional e pontos de aprovação.

Toda essa representação estruturada é então passada para o modelo Claude Sonnet 4.6, disponível no Amazon Bedrock, que gera a documentação formal: sequências de passos estruturadas, capturas de tela incorporadas, verificações de validação e resultados esperados.

Um diferencial importante é o editor interativo de SOPs com reprodução vinculada a timestamps: cada passo documentado está anotado com o momento exato do vídeo original onde aquela ação ocorre. O revisor pode validar cada passo sem precisar percorrer a gravação inteira. O SOP final pode ser exportado como documento Word com capturas de tela incorporadas.

Em ambientes de produção, essa abordagem reduziu o tempo de criação de SOPs em 80%, mantendo qualidade por meio de validação humana no processo.

1.2 Analisador de chamados com RAG

Depois que os SOPs estão capturados, o próximo desafio é aplicá-los de forma consistente. Chamados chegam com contexto incompleto, linguagem ambígua e anexos que exigem interpretação manual.

O componente de análise de chamados combina Processamento de Linguagem Natural (NLP), recuperação semântica e Geração Aumentada por Recuperação (RAG) para entregar orientação contextual diretamente no fluxo de trabalho. Quando um novo chamado entra no sistema, seu conteúdo é normalizado e enriquecido por Modelos de Linguagem de Grande Escala (LLM). Entidades-chave, sinais de intenção e dependências são extraídos de campos de texto livre e anexos. A representação enriquecida é convertida em embeddings vetoriais e armazenada no Amazon OpenSearch Serverless.

Para gerar orientação de resolução, o sistema recupera os SOPs, políticas e resoluções históricas mais relevantes e os fornece como contexto para um modelo de fundação no Amazon Bedrock. O modelo gera orientação passo a passo fundamentada no conhecimento organizacional verificado. O Amazon Bedrock Guardrails é usado para filtragem de conteúdo e validação de aderência às políticas.

Além da orientação, o sistema incorpora fluxos agênticos construídos com o AWS Strands Agents SDK, onde múltiplos agentes autônomos colaboram para executar tarefas operacionais como marcação de chamados, inserção de comentários e atualização de status — sempre dentro de um framework com humano no processo, garantindo que analistas revisem e aprovem as recomendações antes da execução.

1.3 Inteligência de fluxo de valor

Mesmo quando chamados são resolvidos com sucesso, as equipes raramente enxergam como o trabalho realmente flui entre papéis e sistemas. Esse componente apresenta os fluxos de resolução como mapas interativos de raias (swim lanes), mostrando como o trabalho se move entre equipes e sistemas, destacando gargalos, ineficiências e atividades sem valor agregado.

Ao conectar dados de processos upstream e downstream, o componente permite que as equipes avaliem quais fluxos estão prontos para automação — identificando o que deve ser eliminado, otimizado ou mantido como manual antes de escalar. Isso fornece uma base estruturada para iniciativas de melhoria contínua.

Camada 2: Analytics e inteligência de decisão

Enquanto a documentação automatizada e a resolução guiada melhoram o tratamento individual de chamados, líderes também precisam de visibilidade clara sobre distribuição de carga, volumes e risco de SLA. Essa camada é construída sobre o Amazon QuickSight e oferece três capacidades centrais.

2.1 Gestão de carga de trabalho e visibilidade de capacidade

Os dashboards mostram como os chamados estão distribuídos entre os analistas por volume e complexidade, com indicadores de disponibilidade e tendências semanais que destacam sobrecarga e subutilização. Gráficos de barras empilhadas segmentados por complexidade tornam visível como o trabalho de alto, médio e baixo esforço está sendo distribuído, apoiando um planejamento de capacidade mais consistente e baseado em dados.

2.2 Categorização de chamados e previsão de risco de SLA com ML

O sistema aplica modelos de aprendizado de máquina (ML) para analisar o conteúdo dos chamados e prever o risco de descumprimento do SLA. O processo começa com uma consulta no Amazon Redshift que extrai chamados ativos com características operacionais calculadas. Uma camada de processamento realiza engenharia de features — incluindo sinais como número de dias em aberto, dias restantes no mês, nível de complexidade, número de escalonamentos anteriores e indicadores de carga de trabalho.

Os chamados são primeiro categorizados por lógica de classificação baseada em regras em sete clusters de negócio (por exemplo, Suporte Geral, Gestão de Exceções, Acesso e Permissões, Fusão de Contas). Para a previsão de risco de SLA, o sistema usa um modelo XGBoost que gera uma pontuação de probabilidade (0–1) representando a chance de descumprimento, mapeada para categorias de risco:

• Alto Risco: probabilidade ≥ 0,7 de descumprimento do SLA
• Médio Risco: probabilidade ≥ 0,4 de descumprimento do SLA
• Baixo Risco: probabilidade < 0,4 de descumprimento do SLA

Os resultados são gravados no Amazon S3 como arquivos Parquet particionados com timestamps e surfaceados nos dashboards do Amazon QuickSight. Em produção, essa abordagem contribuiu para melhorar o desempenho de SLA de 89,5% para 95%, apoiando intervenção mais precoce em chamados de alto risco.

2.3 Experiência agêntica incorporada

Para fechar a lacuna entre insight e ação, a solução incorpora capacidades agênticas diretamente na experiência de analytics. Um agente inteligente do Amazon QuickSight atua como consultor de analytics de carga de trabalho, entregando recomendações concisas e orientadas a resultados para rebalancear atribuições e melhorar o desempenho.

O agente se integra com fluxos de trabalho existentes — sistemas de chamados, Slack e e-mail — para que os usuários recebam insights acionáveis sem precisar navegar manualmente pelos dashboards. Após analistas revisarem e aprovarem as ações recomendadas, o agente as executa — como atualizar status de chamados, encaminhar aprovações ou fechar chamados — gerando automaticamente trilhas de auditoria para conformidade.

Resultados mensuráveis

A AWS relata que, em pilotos internos, a abordagem entregou impacto de negócio mensurável:

• Retorno sobre investimento de 4:1
• Redução de entradas de chamados imprecisas de 45,3% para 10%
• Melhoria no cumprimento de SLA de 89,5% para 95%
• Aumento de 80% na eficiência de criação de documentação com geração automatizada de SOPs

Esses ganhos se traduzem em tempos de resolução mais rápidos, menor risco operacional e qualidade de serviço mais consistente. Ao combinar IA multimodal no Amazon Bedrock, RAG e analytics operacional no Amazon QuickSight, a solução transforma a atividade cotidiana de suporte em uma fonte contínua de aprendizado e melhoria.

Fonte

Modernizing and scaling support operations with generative AI on AWS (https://aws.amazon.com/blogs/machine-learning/modernizing-and-scaling-support-operations-with-generative-ai-on-aws/)

Busca na web chega ao Amazon Bedrock no GovCloud

A AWS anunciou a disponibilidade da ferramenta integrada de busca na web (Web Search) do Amazon Bedrock na região AWS GovCloud (US-West). A novidade amplia o alcance desse recurso para ambientes governamentais e do setor público, que possuem requisitos rigorosos de conformidade e tratamento de dados.

O que é o Web Search no Amazon Bedrock

O Web Search é uma ferramenta nativa do lado do servidor (built-in server-side tool) que permite aos modelos de linguagem fundamentarem suas respostas em informações atuais da web. O recurso é compatível com modelos OpenAI GPT suportados pelo Amazon Bedrock e inclui citações das fontes consultadas, permitindo rastrear cada afirmação até sua origem na web.

Isso é especialmente útil em situações onde a resposta depende de informações que mudam com o tempo ou que são mais recentes do que os dados de treinamento do modelo — como eventos atuais, lançamentos recentes ou preços em tempo real.

Sem infraestrutura para gerenciar

Por ser executado dentro do Amazon Bedrock, o Web Search elimina a necessidade de hospedar um índice de busca próprio, gerenciar crawlers ou escrever o loop de chamada de ferramentas manualmente. A AWS cuida de toda essa camada de infraestrutura, servindo os resultados a partir de um índice web e cache mantidos pela própria Amazon.

Governança e controle de acesso

O recurso foi projetado para atender aos padrões de governança e tratamento de dados exigidos pelos clientes do AWS GovCloud (US). Por padrão, os dados das requisições permanecem dentro do perímetro da AWS. Como capacidade nativa gerenciada pelo Gerenciamento de Identidade e Acesso da AWS (IAM — AWS Identity and Access Management), administradores podem permitir ou negar o uso do Web Search no nível da conta ou da organização, além de restringi-lo por região, garantindo controle centralizado.

Como começar a usar

Para utilizar o recurso, basta adicionar uma ferramenta do tipo web_search ao array tools na requisição da API de Respostas da OpenAI (OpenAI Responses API), utilizando a biblioteca cliente OpenAI existente com uma chave de API do Amazon Bedrock. O modelo aciona a ferramenta automaticamente apenas quando identifica que a requisição exige informações atuais.

Modelos e regiões suportados

No lançamento para o AWS GovCloud (US-West), o Web Search suporta os modelos GPT-5.4, GPT-5.6 Terra e Luna. Além da região GovCloud (US-West), o recurso também está disponível em US East (Norte da Virgínia), US East (Ohio) e US West (Oregon).

Para aprofundar o entendimento técnico, a AWS disponibiliza um blog técnico de introdução ao Web Search. Para orientações de implementação, consulte a documentação oficial do Web Search. Informações sobre preços estão disponíveis na página de preços do Amazon Bedrock.

Fonte

Web Search on Amazon Bedrock is now available in AWS GovCloud (US-West) (https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-bedrock-web-aws-govcloud/)

Mais controle sobre conectores no Amazon Quick

O Amazon Quick acaba de receber duas novidades relevantes para quem gerencia conectores na plataforma: novas configurações de ferramentas e suporte à sincronização com servidores MCP (Protocolo de Contexto de Modelo). As atualizações foram anunciadas pela AWS e chegam para dar mais controle a administradores e proprietários de conectores sobre como essas integrações são implantadas e mantidas atualizadas.

O que são os conectores do Amazon Quick?

Os conectores do Amazon Quick permitem que usuários utilizem ferramentas e serviços externos — como Outlook, Slack, Salesforce, Jira e servidores MCP próprios — diretamente em seus fluxos de trabalho. Isso vale para diferentes contextos dentro da plataforma: chat, agentes, aplicativos, flows e pesquisa aprofundada (deep research).

O que mudou com as novas configurações

Habilitação seletiva de ferramentas

Agora, proprietários de conectores e administradores podem habilitar ou desabilitar ferramentas individuais dentro de um conector. Na prática, isso significa que é possível garantir que apenas as ferramentas aprovadas fiquem disponíveis para os usuários finais — um controle importante em ambientes corporativos onde nem toda funcionalidade de um serviço externo deve estar acessível.

Configurações de permissão por ferramenta

Além da habilitação seletiva, as novas configurações de permissão permitem que proprietários de conectores definam quais ferramentas exigem consentimento explícito do usuário antes de serem executadas. Também é possível deixar essa decisão nas mãos dos próprios usuários finais, oferecendo maior flexibilidade conforme a política de cada organização.

Sincronização automática com servidores MCP externos

O recurso de sincronização MCP garante que os conectores se mantenham atualizados automaticamente à medida que os servidores MCP externos evoluem — seja adicionando novas ferramentas, atualizando descrições ou expandindo suas capacidades. Com isso, os usuários sempre têm acesso às informações mais recentes sem precisar de intervenção manual para atualizar os conectores.

Disponibilidade

Todos esses recursos já estão disponíveis em todas as regiões da AWS onde o Amazon Quick está presente. Para saber mais sobre como configurar e aproveitar essas novidades, a AWS disponibiliza o Guia do Usuário do Amazon Quick.

Fonte

Amazon Quick adds new tool settings and Model Context Protocol (MCP) sync support for connectors (https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-quick-adds-tool-settings-mcp-sync/)