O problema: agentes que esquecem tudo entre sessões

Quem trabalha com IDEs agênticas sabe bem a frustração: você passa dias ou semanas desenvolvendo em uma base de código complexa, com requisitos de negócio específicos, preferências de projeto bem definidas — e toda vez que abre uma nova sessão, o agente começa do zero. Nenhuma memória das conversas anteriores, nenhum contexto acumulado, nenhuma preferência salva.

O resultado prático é que o desenvolvedor precisa repassar as mesmas informações contextuais repetidamente, o que impacta diretamente a produtividade. É exatamente esse problema que a AWS abordou em um tutorial recente, demonstrando como estender a memória conversacional do Kiro CLI por meio de um servidor Protocolo de Contexto de Modelo (MCP) personalizado integrado ao Amazon Bedrock AgentCore Memory.

O que é o Kiro CLI e o Bedrock AgentCore Memory

O Kiro CLI é uma ferramenta que permite interagir com os agentes de IA do Kiro diretamente pelo terminal. Já o Amazon Bedrock AgentCore Memory é um serviço totalmente gerenciado pela AWS que permite que agentes de IA retenham informações de interações passadas, tornando as conversas mais inteligentes e conscientes do contexto.

O serviço oferece capacidades tanto para memória de curto prazo (contexto de trabalho imediato) quanto para memória de longo prazo (aprendizado acumulado entre sessões), com busca semântica integrada. Isso possibilita que agentes retenham contexto, aprendam com interações anteriores e entreguem experiências verdadeiramente personalizadas.

Visão geral da solução

A arquitetura proposta pela AWS é composta por três componentes principais que trabalham em conjunto:

• Amazon Bedrock AgentCore Memory: serviço gerenciado responsável por armazenar e recuperar o contexto das conversas, com busca semântica nativa.
• Servidor MCP personalizado: expõe as capacidades do AgentCore Memory por meio do protocolo MCP, tornando as operações de memória acessíveis a clientes compatíveis.
• Kiro CLI: conecta-se ao servidor MCP via protocolos STDIO para armazenar e recuperar o histórico conversacional.

O servidor MCP atua como uma ponte entre o Kiro CLI e o Amazon Bedrock AgentCore Memory, permitindo que o Kiro mantenha histórico e contexto de conversas entre sessões.

Ferramentas disponíveis no servidor MCP

O servidor MCP organiza suas ferramentas em três categorias:

• Ferramentas de conversa: permitem buscar histórico por tópico ou período, armazenar conversas com rastreamento consistente de sessão, recuperar o conteúdo completo de conversas e listar sessões anteriores.
• Ferramentas de monitoramento: permitem visualizar estatísticas de uso de memória e a configuração do servidor MCP.
• Ferramentas de gerenciamento: permitem deletar sessões específicas e remover dados armazenados quando necessário.

Estratégia de recuperação em dois estágios

A solução adota uma estratégia de recuperação em cascata: primeiro tenta a busca semântica usando a API retrieve_memory_records do Bedrock AgentCore Memory para correspondência conceitual; caso não encontre resultados adequados, recorre à correspondência direta no conteúdo dos eventos, varrendo os payloads brutos das conversas armazenadas nas sessões do AgentCore Memory.

Essa abordagem garante que as conversas sejam recuperáveis independentemente de o processamento semântico já ter sido concluído. Também é possível usar expressões de tempo em linguagem natural nas consultas, como “recente”, “ontem à noite” ou “semana passada”, para localizar conversas relevantes.

Pré-requisitos

Para seguir o tutorial, é necessário ter:

• Acesso a uma conta AWS via Console de Gerenciamento e Interface de Linha de Comando da AWS (AWS CLI).
• Um usuário do Gerenciamento de Identidade e Acesso da AWS (IAM) com as permissões necessárias para realizar chamadas aos serviços e gerenciar os recursos mencionados — seguindo sempre o princípio do menor privilégio.
• Um AWS Builder ID.
• Kiro CLI instalado e configurado no computador.

Passo a passo da configuração

1. Clonar o repositório

git clone https://github.com/aws-samples/sample-amazon-bedrock-agentcore-memory-mcp-server.git

2. Criar ambiente virtual Python e instalar dependências

cd sample-amazon-bedrock-agentcore-memory-mcp-server
python3 -m venv venv; source venv/bin/activate; pip3 install -r requirements.txt;

3. Criar o recurso de memória e gerar a configuração do agente Kiro

Este passo pode levar alguns minutos para ser concluído:

python3 setup_bedrock_agentcore_memory.py

Durante a execução, será solicitado que você escolha um tipo de identificador de ator. As conversas ficam associadas a esse identificador:

• Opção 1 — User ID (padrão): recomendado para uso pessoal. Utiliza o nome de usuário do sistema a partir da variável de ambiente USER. Define ACTOR_ID_TYPE=userid no arquivo agent/kiro_memory.json.
• Opção 2 — Project ID: recomendado para isolamento de memória por equipe ou projeto. Requer que você forneça o projectid e o your-project-id. Define ACTOR_ID_TYPE=projectid e PROJECT_ID=your-project-id no arquivo agent/kiro_memory.json.

A estratégia de namespace utilizada é: /strategy/semanticMemoryStrategy/actor/{actorId}/session/{sessionId}

4. Configurar o agente Kiro

mkdir -p ~/.kiro/agents/
mkdir -p ~/.kiro/hooks/
cp -p agent/kiro_memory.json ~/.kiro/agents/
cp -p hooks/cache-prompt.sh ~/.kiro/hooks/
cp -p hooks/load-preferences.sh ~/.kiro/hooks/
cp -p hooks/store-conversation.sh ~/.kiro/hooks/
chmod 755 ~/.kiro/hooks/*

Para definir o agente kiro_memory como padrão, adicione o seguinte ao arquivo cli.json no diretório ~/.kiro/settings/:

{"chat.defaultAgent": "kiro_memory"}

5. Fazer login no Kiro CLI

Para autenticar no Kiro CLI, é necessário ter um AWS Builder ID ou uma assinatura ativa do Kiro pela organização. Caso não tenha, é possível criar um AWS Builder ID seguindo as instruções da documentação oficial.

kiro-cli login --use-device-flow

Selecione a opção Use for Free with Builder ID usando as teclas de seta e pressione Enter. Uma URL será gerada para autenticação. Acesse-a no navegador, faça login com o Builder ID criado, confirme a solicitação e autorize o acesso. Ao retornar ao terminal, a mensagem Logged in successfully confirmará o login.

6. Iniciar o Kiro CLI e verificar as ferramentas disponíveis

kiro-cli --classic

Após iniciar, execute /mcp para listar os servidores MCP configurados na sessão. Depois que o servidor MCP for inicializado com sucesso, execute /tools para listar as ferramentas disponíveis. As seguintes ferramentas estarão acessíveis por meio do agentcore-memory-mcp-server:

• clear_all_data — exclui informações de um namespace específico na memória
• delete_session — exclui uma sessão específica
• get_direct_conversation_history — acessa o conteúdo completo de sessões específicas
• get_memory_stats — usa list_memory_records para fornecer uma visão geral da memória
• get_server_config — exibe a configuração do servidor MCP
• get_session_details — fornece informações sobre uma sessão específica
• list_sessions — lista sessões armazenadas anteriormente
• search_conversation_history — busca histórico de conversas por tópico ou período
• search_memories — outra ferramenta para busca em memória de longo prazo
• store_conversation — armazena conversas com IDs de sessão consistentes

Testando a solução na prática

O Kiro CLI invoca os servidores MCP conforme a funcionalidade necessária para responder ao prompt. Os hooks do Kiro CLI são acionados automaticamente para armazenar a conversa após cada interação.

Um exemplo prático de uso seria perguntar ao Kiro sobre um serviço da AWS — como o AWS DevOps Agent — e autorizar o acesso às ferramentas solicitadas. Ao encerrar a sessão com /quit e fazer login novamente, é possível perguntar “O que discutimos sobre o AWS DevOps Agent?” e o Kiro usará o agentcore-memory-mcp-server para buscar as informações relevantes no Bedrock AgentCore Memory.

A partir daí, é possível fazer perguntas de acompanhamento — como integrações disponíveis ou informações de preço — e o contexto acumulado nas sessões anteriores será aproveitado automaticamente. Ao encerrar e retornar em outro momento, o Kiro consegue apresentar um resumo das discussões anteriores em linguagem natural.

Limpeza dos recursos

Caso tenha seguido o tutorial apenas para fins de demonstração e queira evitar cobranças futuras, execute o seguinte comando para excluir os recursos criados:

python3 cleanup_bedrock_agentcore_memory.py

Também é necessário excluir manualmente a configuração do agente em ~/.kiro/agents/kiro_memory.json e os hooks em ~/.kiro/hooks/.

Conclusão

A AWS demonstrou com esse tutorial como é possível resolver um dos principais pontos de atrito no uso de IDEs agênticas: a perda de contexto entre sessões. Ao combinar o Kiro CLI com um servidor MCP personalizado integrado ao Amazon Bedrock AgentCore Memory, a solução entrega persistência de contexto de forma confiável — sem que o desenvolvedor precise repetir as mesmas informações a cada nova sessão.

Recursos como busca semântica, expressões de tempo em linguagem natural e a estratégia de recuperação em cascata tornam o histórico conversacional acessível de forma inteligente, elevando significativamente a produtividade no desenvolvimento com agentes de IA.

Fonte

Extending conversational memory in Kiro CLI using Amazon Bedrock AgentCore Memory (https://aws.amazon.com/blogs/machine-learning/extending-conversational-memory-in-kiro-cli-using-amazon-bedrock-agentcore-memory/)

O que mudou no SageMaker Feature Store

O Amazon SageMaker Feature Store é um repositório gerenciado e dedicado para armazenar, compartilhar e gerenciar features para modelos de Aprendizado de Máquina (ML). O serviço já suportava formato de tabela Apache Iceberg, ingestão via streaming e ingestão em lote escalável — e agora a AWS anuncia três novas capacidades que chegam juntas no SageMaker Python SDK v3.8.0.

Dois problemas operacionais aparecem de forma consistente quando times de ML escalam suas plataformas do ambiente experimental para produção. O primeiro é garantir controle de acesso a dados sensíveis de features sem criar overhead manual para cada novo grupo de features. O segundo é manter os custos de armazenamento previsíveis quando workloads de streaming de alta frequência geram volumes crescentes de metadados Apache Iceberg.

Um exemplo concreto ilustra bem o segundo problema: um time de analytics de varejo descobriu que seu offline store baseado em Apache Iceberg havia acumulado mais de 50 TB de arquivos de metadados em menos de um ano, gerando cobranças inesperadas e substanciais no Amazon Simple Storage Service (Amazon S3).

As três novas capacidades

A AWS anunciou as seguintes adições disponíveis no SageMaker Python SDK v3.8.0:

• Integração nativa com AWS Lake Formation – Permite registrar o offline store no Lake Formation durante a criação do grupo de features, ou em grupos já existentes, para aplicar controle de acesso em nível de coluna, linha e célula. Sem necessidade de configuração manual do Lake Formation.
• Propriedades adicionais de tabela Apache Iceberg – Controle de políticas de retenção de metadados e ciclo de vida de snapshots na criação ou em grupos de features existentes, prevenindo acúmulo de metadados e reduzindo custos de armazenamento.
• Suporte ao Feature Store no SageMaker Python SDK v3 – O SDK v3.8.0 modernizado traz o conjunto completo de capacidades do Feature Store, incluindo as novidades, em um pacote modular, mais rápido e mais leve.

Pré-requisitos

Para acompanhar os exemplos, são necessários:

• Uma conta AWS com permissões para criar recursos do Amazon SageMaker AI.
• Uma execution role do Amazon SageMaker AI com acesso ao Amazon S3, AWS Glue e AWS Lake Formation.
• SageMaker Python SDK v3.8.0 ou superior. Instale com o comando:

pip install --upgrade "sagemaker>=3.8.0"

• Para integração com Lake Formation: ao menos um Administrador do Data Lake (Data Lake Administrator) configurado na conta. O Feature Store valida isso antes de ativar o controle de acesso.
• Um bucket Amazon S3 existente para os dados do offline store.

Feature Store no SageMaker Python SDK v3

O SageMaker Python SDK v3.8.0, lançado em 16 de abril de 2026, é a base das capacidades descritas neste post. O SDK modernizado introduz arquitetura modular, melhor desempenho e remoção de dependências legadas (como PyTorch), resultando em instalação mais rápida e ambientes mais enxutos.

As seguintes capacidades do Feature Store estão disponíveis no SDK v3:

• Gerenciamento do ciclo de vida de grupos de features: criar, descrever, atualizar, deletar e listar.
• Operações de registro: PutRecord, GetRecord e BatchGetRecord.
• Extração de dataset de treinamento: queries com correção de ponto no tempo (point-in-time–correct).
• Ingestão de DataFrame: FeatureGroupManager.ingest() a partir de DataFrames Pandas e Spark.
• Novos parâmetros para offline store: IcebergProperties e LakeFormationConfig suportados nos fluxos de criação e atualização.

A superfície de API do Feature Store é consistente com o SDK v2, portanto o código existente funciona com mudanças mínimas. Consulte o changelog do SDK v3 para detalhes sobre breaking changes em outras áreas.

Início rápido com o SDK v3

Veja como criar um grupo de features com os novos parâmetros de Lake Formation e Iceberg:

fg = FeatureGroupManager.create(
    feature_group_name="my-features",
    record_identifier_feature_name="user_id",
    event_time_feature_name="event_time",
    feature_definitions=df,
    role_arn=role,
    online_store_config={"EnableOnlineStore": True},
    offline_store_config=OfflineStoreConfig(
        s3_storage_config=S3StorageConfig(s3_uri=f"s3://{bucket}/feature-store/"),
        table_format="Iceberg",
    ),
    lake_formation_config=LakeFormationConfig(
        enabled=True,
        hybrid_access_mode_enabled=True,
        acknowledge_risk=True,
    ),
    iceberg_properties=IcebergProperties(
        properties={
            "write.metadata.delete-after-commit.enabled": "true",
            "write.metadata.previous-versions-max": "10",
        }
    ),
)

Governança do offline store com integração nativa ao Lake Formation

Configurar o AWS Lake Formation em dados do Feature Store anteriormente exigia diversas etapas manuais: registrar localizações no S3, revogar o grupo IAMAllowedPrincipals e configurar filtros de dados para cada grupo de features. O processo era demorado, sujeito a erros e precisava ser repetido para cada novo grupo. Organizações de serviços financeiros, saúde e outros setores regulados, que precisam de controle de acesso em nível de coluna, linha e célula, sentiam esse peso de forma especial.

Agora é possível ativar o controle de acesso do Lake Formation no offline store de um grupo de features no momento da criação, passando um LakeFormationConfig para o FeatureGroupManager.create(). Também é possível ativá-lo em grupos de features existentes usando FeatureGroupManager.enable_lake_formation().

Quando essa configuração é ativada, o Feature Store executa automaticamente as seguintes operações:

• Adiciona o local de dados S3 ao Lake Formation. O prefixo S3 do offline store é registrado como um local de data lake governado pelo Lake Formation. Os serviços analíticos confiáveis (Amazon Athena, AWS Glue, Amazon EMR, Amazon Redshift Spectrum) passam a receber credenciais temporárias do Lake Formation para consultar os dados.
• Desativa o modo de acesso híbrido (opcional). Quando hybrid_access_mode_enabled=False, o SDK revoga o grant IAMAllowedPrincipal na tabela do AWS Glue, forçando o acesso exclusivamente pelo modelo de permissões do Lake Formation. Com hybrid_access_mode_enabled=True, as políticas do AWS Identity and Access Management (IAM) e as permissões do Lake Formation coexistem — útil para migrações graduais. Saiba mais sobre o modo de acesso híbrido.
• Fornece uma política de deny recomendada para o S3. Para quem precisa de governança ponta a ponta, o SDK registra uma política de bucket recomendada como mensagem de aviso após a ativação. Aplique essa política ao bucket Amazon S3 para bloquear leituras diretas por principals não autorizados, fechando o último caminho que poderia contornar o Lake Formation.

Esta é uma configuração opcional por grupo de features. Se omitida, o comportamento permanece inalterado e os grupos de features existentes continuam funcionando com acesso baseado em IAM.

Exemplo de código — criação com Lake Formation

O código a seguir cria um novo grupo de features com controle de acesso do Lake Formation ativado. Para opções adicionais de configuração, consulte Ativar Lake Formation com Feature Groups.

fg = FeatureGroupManager.create(
    feature_group_name="governed-customer-features",
    record_identifier_feature_name="customer_id",
    event_time_feature_name="event_time",
    feature_definitions=customer_df,
    role_arn=role,
    online_store_config={"EnableOnlineStore": True},
    offline_store_config=OfflineStoreConfig(
        s3_storage_config=S3StorageConfig(s3_uri=f"s3://{bucket}/feature-store/"),
        table_format="Iceberg",
    ),
    lake_formation_config=LakeFormationConfig(
        enabled=True,
        hybrid_access_mode_enabled=True,
        acknowledge_risk=True,
    ),
)

Para ativar o Lake Formation em um grupo de features existente:

fg = FeatureGroupManager.get(
    feature_group_name="existing-feature-group",
)
fg.enable_lake_formation(
    hybrid_access_mode_enabled=True,
    acknowledge_risk=True,
)

Após a configuração do grupo de features, use o console ou a API do Lake Formation para conceder permissões granulares: acesso SELECT apenas a colunas específicas (filtragem por coluna), restrição de analistas a linhas de uma determinada região (filtragem por linha), ou combinação de ambos para controle em nível de célula.

Considerações importantes

• O online store não é afetado. O controle de acesso do Lake Formation se aplica apenas ao offline store. O online store continua usando autorização baseada em IAM, sem impacto na latência de inferência em tempo real.
• Funciona com AWS Glue e Iceberg. O controle de acesso do Lake Formation se aplica da mesma forma independentemente do formato de tabela usado no offline store.
• Compatível com múltiplas contas. Se você usa o AWS Resource Access Manager (AWS RAM) para compartilhar tabelas do Feature Store entre contas, os grants do Lake Formation continuam funcionando junto com os padrões existentes de compartilhamento entre contas. Observação: o modo de acesso híbrido deve ser desativado para acesso entre contas quando o formato de tabela é Iceberg.
• Pré-requisito: Data Lake Administrator. O sistema valida que ao menos um Administrador do Data Lake está configurado na conta antes de ativar o controle de acesso. Se nenhum existir, a chamada de criação retorna um erro imediato e descritivo, em vez de falhar de forma assíncrona.

Gerenciamento do offline store com propriedades adicionais do Iceberg

O Amazon SageMaker Feature Store suporta Apache Iceberg como formato de tabela para o offline store, melhorando o desempenho de queries via compactação e suportando operações em nível de registro. Esta seção apresenta novos parâmetros que oferecem controle sobre o ciclo de vida dos metadados Iceberg.

Em workloads com escrita de alta frequência — como pipelines de features via streaming que ingerem registros a cada poucos segundos — os arquivos de metadados Iceberg se acumulam a cada commit. Sem controles de ciclo de vida, esses metadados podem crescer exponencialmente. Um cliente com mais de 40 grupos de features em streaming viu seu bucket S3 crescer de alguns gigabytes para mais de 50 TB de metadados em menos de um ano. O Feature Store estava fazendo commits no offline store com alta frequência (menos de 10 minutos entre commits), e cada commit gerava novos arquivos de metadados. As operações de limpeza tentadas via Amazon Athena (OPTIMIZE e VACUUM) expiravam em tabelas acima de 50 TB, exigindo jobs custosos no Amazon EMR Serverless Spark e até a reescrita completa das tabelas.

A solução

Agora é possível passar uma configuração IcebergProperties ao criar um grupo de features no formato Iceberg. Essas propriedades são aplicadas à tabela Iceberg subjacente, dando controle sobre o ciclo de vida dos metadados desde o primeiro dia. Também é possível atualizar as propriedades Iceberg em grupos de features existentes usando FeatureGroupManager.update().

Alguns exemplos de propriedades suportadas:

• write.metadata.delete-after-commit.enabled — Padrão: false. Deleta os arquivos de metadados mais antigos após cada commit.
• write.metadata.previous-versions-max — Padrão: 100. Número máximo de versões anteriores de metadados a manter no histórico.
• history.expire.max-snapshot-age-ms — Padrão: 432000000 (5 dias). Idade máxima dos snapshots a manter ao expirar o histórico.
• history.expire.min-snapshots-to-keep — Padrão: 1. Número mínimo de snapshots a manter ao expirar o histórico.
• write.target-file-size-bytes — Padrão: 536870912 (512 MB). Tamanho-alvo para arquivos de dados gerados.
• write.parquet.row-group-size-bytes — Padrão: 134217728 (128 MB). Tamanho do row group Parquet.
• read.split.target-size — Padrão: 134217728 (128 MB). Tamanho-alvo ao combinar splits de entrada de dados.

Para a lista completa de propriedades suportadas, consulte o guia de gerenciamento de metadados Iceberg na documentação do SageMaker AI.

Exemplo de código — criação com IcebergProperties

fg = FeatureGroupManager.create(
    feature_group_name="streaming-click-features",
    record_identifier_feature_name="session_id",
    event_time_feature_name="event_time",
    feature_definitions=clicks_df,
    role_arn=role,
    offline_store_config=OfflineStoreConfig(
        s3_storage_config=S3StorageConfig(s3_uri=f"s3://{bucket}/feature-store/"),
        table_format="Iceberg",
    ),
    iceberg_properties=IcebergProperties(
        properties={
            "write.metadata.delete-after-commit.enabled": "true",
            "write.metadata.previous-versions-max": "10",
            "history.expire.max-snapshot-age-ms": "86400000",
            "history.expire.min-snapshots-to-keep": "5",
            "write.target-file-size-bytes": "536870912",
        }
    ),
)

Para atualizar propriedades Iceberg em um grupo de features existente:

fg = FeatureGroupManager.get(
    feature_group_name="existing-feature-group",
    include_iceberg_properties=True,
)
fg.update(
    iceberg_properties=IcebergProperties(
        properties={
            "write.metadata.delete-after-commit.enabled": "true",
            "write.metadata.previous-versions-max": "10",
        }
    )
)

Boas práticas

• Comece pela limpeza de metadados para workloads de streaming. Se o pipeline escreve no offline store mais de uma vez por minuto, defina write.metadata.delete-after-commit.enabled como "true" e limite o write.metadata.previous-versions-max. Essa é a mudança de configuração com maior impacto na prevenção de custos excessivos de armazenamento.
• Continue executando compactação. Essas propriedades gerenciam o ciclo de vida dos metadados, mas ainda é necessário executar a compactação Iceberg (usando Athena OPTIMIZE + VACUUM ou ações de manutenção do Spark) para mesclar arquivos de dados pequenos e otimizar o desempenho de queries.
• Ajuste a retenção de snapshots conforme necessidades de conformidade. Workloads com auditoria intensiva que exigem queries de time-travel devem usar valores maiores para history.expire.min-snapshots-to-keep e history.expire.max-snapshot-age-ms. Pipelines de streaming otimizados para custo se beneficiam de retenção menor.
• Defina as propriedades na criação. Essas propriedades entram em vigor em novos commits. Para grupos de features existentes com metadados acumulados, use FeatureGroupManager.update() para definir as propriedades e, em seguida, execute expiração de snapshots e deleção de arquivos órfãos para recuperar o espaço de armazenamento.

Combinando as duas capacidades

Ao combinar as duas capacidades em uma única chamada FeatureGroupManager.create(), o resultado é um grupo de features simultaneamente governado e otimizado para custo — sem necessidade de configuração adicional. Os metadados do offline store são gerenciados automaticamente e o controle de acesso do Lake Formation está ativo sem registro manual. O online store continua servindo features com baixa latência via autorização IAM.

fg = FeatureGroupManager.create(
    feature_group_name="real-time-user-signals",
    record_identifier_feature_name="user_id",
    event_time_feature_name="event_time",
    feature_definitions=signals_df,
    role_arn=role,
    online_store_config={"EnableOnlineStore": True},
    offline_store_config=OfflineStoreConfig(
        s3_storage_config=S3StorageConfig(s3_uri=f"s3://{bucket}/feature-store/"),
        table_format="Iceberg",
    ),
    lake_formation_config=LakeFormationConfig(
        enabled=True,
        hybrid_access_mode_enabled=True,
        acknowledge_risk=True,
    ),
    iceberg_properties=IcebergProperties(
        properties={
            "write.metadata.delete-after-commit.enabled": "true",
            "write.metadata.previous-versions-max": "10",
            "history.expire.max-snapshot-age-ms": "86400000",
            "history.expire.min-snapshots-to-keep": "5",
        }
    ),
)

Para notebooks completos com instruções passo a passo, consulte o notebook de governança com Lake Formation e o notebook de propriedades de tabela Iceberg no repositório do SageMaker Python SDK.

Limpeza de recursos

Para evitar cobranças contínuas, delete os grupos de features criados durante o walkthrough. Se você adicionou localizações Amazon S3 ao Lake Formation, cancele o registro delas pelo console do Lake Formation ou pela API DeregisterResource. Revogue também as permissões do Lake Formation concedidas durante os testes.

Conclusão

Em conjunto, essas melhorias tornam o Amazon SageMaker Feature Store mais simples de proteger, mais eficiente em custos e mais rápido de integrar aos pipelines de ML. Ao automatizar o controle de acesso do Lake Formation, expor configurações granulares de ciclo de vida do Iceberg e entregar tudo isso em um SDK modular e leve, a AWS removeu o trabalho repetitivo que antes separava as equipes de um gerenciamento de features pronto para produção em escala.

Para mais informações, consulte a documentação do Feature Store, o guia de controle de acesso com Lake Formation, o guia de gerenciamento de metadados Iceberg e as notas de versão do SDK v3. Para praticar, experimente o notebook do Lake Formation e o notebook de propriedades Iceberg.

Leituras relacionadas

• Understanding the Key Capabilities of Amazon SageMaker Feature Store
• Speed ML Development Using SageMaker Feature Store and Apache Iceberg Offline Store Compaction
• Control Access to Amazon SageMaker Feature Store Offline Using AWS Lake Formation
• Build an Offline Feature Store Using Amazon SageMaker Unified Studio and SageMaker Catalog

Fonte

Accelerate ML feature pipelines with new capabilities in Amazon SageMaker Feature Store (https://aws.amazon.com/blogs/machine-learning/accelerate-ml-feature-pipelines-with-new-capabilities-in-amazon-sagemaker-feature-store/)

Expansão do AWS Glue zero-ETL chega a Mumbai

A AWS anunciou a disponibilidade do AWS Glue zero-ETL na região Ásia-Pacífico (Mumbai). Com essa expansão, clientes que operam nessa região passam a contar com integrações zero-ETL para simplificar seus pipelines de dados, reduzir a latência na movimentação de informações e acelerar o tempo até a geração de insights em cargas de trabalho de analytics e aprendizado de máquina.

O que é o zero-ETL e por que isso importa

Para quem ainda não conhece o conceito: ETL é a sigla para Extração, Transformação e Carga (Extract, Transform, Load) — o processo tradicional de mover dados de uma fonte para um destino analítico. Construir e manter esses pipelines costuma consumir tempo e recursos consideráveis das equipes de engenharia de dados.

O zero-ETL da AWS é um conjunto de integrações totalmente gerenciadas que minimiza a necessidade de criar pipelines ETL manualmente para casos comuns de ingestão e replicação de dados. Em vez de escrever e manter código de integração, as equipes podem contar com um serviço que cuida disso automaticamente.

Fontes e destinos suportados

Com o zero-ETL, é possível replicar dados a partir de diversas origens diretamente para armazenamentos analíticos de destino, sem precisar escrever ou manter pipelines ETL. As fontes suportadas incluem:

• Amazon DynamoDB
• Oracle Database@AWS
• Bancos de dados autogerenciados: Oracle, SQL Server, MySQL e PostgreSQL
• Aplicações SaaS suportadas: Salesforce, SAP, Zendesk e Zoho CRM

O que o serviço gerencia automaticamente

Um dos pontos mais relevantes do zero-ETL é o que ele faz nos bastidores sem intervenção manual. O serviço cuida automaticamente de:

• Mapeamento de esquema: adapta automaticamente a estrutura dos dados entre origem e destino
• Captura de dados de alteração (CDC — Change Data Capture): detecta e propaga mudanças nos dados de forma contínua
• Replicação incremental de dados: envia apenas as alterações, e não o conjunto completo de dados a cada ciclo

Tudo isso acontece em tempo quase real, o que significa que os dados analíticos ficam atualizados sem a necessidade de processos agendados ou pipelines complexos mantidos pela equipe.

Impacto para as equipes de engenharia de dados

Com a eliminação da necessidade de construir e gerenciar pipelines complexos, as equipes de engenharia de dados ganham tempo para focar no que realmente gera valor: extrair insights dos dados. Menos tempo gerenciando infraestrutura de integração, mais tempo analisando e entregando resultados para o negócio.

Para saber mais sobre como utilizar o AWS Glue zero-ETL, a AWS disponibiliza a documentação oficial do AWS Glue.

Fonte

AWS Glue zero-ETL is now available in Asia Pacific (Mumbai) region (https://aws.amazon.com/about-aws/whats-new/2026/05/aws-glue-zero-etl-mumbai-region)

O desafio da moderação de conteúdo em escala

Moderar conteúdo gerado por usuários em larga escala é um problema de equilíbrio: um sistema que deixa passar conteúdo prejudicial coloca a plataforma em risco, mas um sistema excessivamente restritivo frustra o público legítimo. Além disso, cada organização define suas próprias políticas, o que torna praticamente impossível usar um único classificador genérico para todos os casos.

A AWS publicou um guia técnico detalhado sobre como usar técnicas de prompting no Amazon Nova 2 Lite para resolver esse problema — sem necessidade de dados de treinamento ou customização de modelo. A grande vantagem dessa abordagem é que, para atualizar as políticas de moderação, basta editar o prompt, sem precisar retreinar nenhum modelo.

Vale mencionar que a AWS já abordou anteriormente o tema de fine-tuning do Amazon Nova para moderação via Amazon SageMaker AI em um post anterior sobre customização de moderação de texto. O guia atual foca exclusivamente na abordagem por prompting.

O padrão AILuminate como base de política

A performance de qualquer sistema de moderação depende diretamente da qualidade da política que ele aplica. O guia utiliza como referência o MLCommons AILuminate Assessment Standard v1.1, que oferece uma taxonomia de 12 categorias de risco organizada em três grupos:

• Riscos Físicos (Physical hazards): como crimes violentos e suicídio/automutilação
• Riscos Não-Físicos (Non-Physical hazards): como crimes não-violentos, discurso de ódio e privacidade
• Riscos Contextuais (Contextual hazards): como aconselhamento especializado não qualificado

As técnicas de prompting apresentadas usam essa taxonomia como exemplo, mas funcionam igualmente bem com políticas customizadas. Basta substituir as definições de categoria — a estrutura do prompt permanece a mesma. Consulte o AILuminate Assessment Standard para ver as definições completas das 12 categorias.

Pipeline de moderação com Amazon Nova 2 Lite

O Amazon Nova 2 Lite é descrito pela AWS como um modelo multimodal de custo muito baixo e inferência rápida, características que o tornam adequado para pipelines de moderação de alto volume. O fluxo típico de moderação passa por quatro etapas:

1. O conteúdo gerado pelo usuário entra no sistema
2. Uma etapa de montagem de prompt envolve esse conteúdo junto com o papel do sistema, definições de política e exemplos opcionais (few-shot)
3. O prompt montado é enviado ao Amazon Nova 2 Lite via Amazon Bedrock, que retorna uma resposta de moderação
4. A saída — que inclui um indicador de violação (sim/não), as categorias violadas e uma explicação opcional — é usada para permitir, sinalizar, remover ou escalar o conteúdo

A AWS recomenda a configuração padrão de inferência: temperatura 0,7 e top-p 0,9 (amostragem por núcleo), que equilibram consistência de saída com variabilidade suficiente para lidar com conteúdo diverso. Para pipelines de alto volume, desativar o modo de raciocínio (reasoning mode) reduz latência e custo — mas é recomendável testar ambos os modos para confirmar a precisão no seu conteúdo específico.

Prompts estruturados: formato XML e JSON

Prompts estruturados são indicados quando o pipeline de moderação precisa de saída formatada que alimente sistemas automatizados diretamente. Os exemplos utilizam few-shot learning — ou seja, pares de entrada e saída de exemplo são incluídos no prompt para que o modelo aprenda o padrão de resposta esperado.

Formato XML

A abordagem XML envolve política, conteúdo e campos de saída em seções com tags. O template tem três componentes que trabalham juntos: uma instrução de abertura que define o papel de moderador e especifica o formato de saída exato; um bloco <EXAMPLE> com demonstração few-shot; e o conteúdo real a ser moderado dentro das tags <POLICY> e <TEXT>.

O template completo tem a seguinte estrutura:

User: You are a text content moderator that detects policy violations, describes violated categories, and explains the reasoning behind your decisions. You will see a policy list and a conversation to be moderated. Your moderation response should be formatted as follows. Start the response by indicating policy violation status using either <POLICY_VIOLATION>Yes</POLICY_VIOLATION> for content that violates policies, or <POLICY_VIOLATION>No</POLICY_VIOLATION> for content that does not violate policies. Then, list the specific violation categories between <CATEGORY_LIST> and </CATEGORY_LIST> tags. If there is no violation, then put C0 between the tags. End the response by providing an analysis explaining whether the content violates policies and why in <EXPLAIN> </EXPLAIN> tags.

Here is an example.
<EXAMPLE>
<POLICY>
{{Policy definitions and categories}}
</POLICY>
<TEXT>
{{Content to moderate}}
</TEXT>
<POLICY_VIOLATION>Yes/No</POLICY_VIOLATION>
<CATEGORY_LIST>Categories or C0</CATEGORY_LIST>
<EXPLAIN>Explanation</EXPLAIN>
</EXAMPLE>

Now, please moderate the following input policy and text.
<POLICY>
{{Policy definitions and categories}}
</POLICY>
<TEXT>
{{Content to moderate}}
</TEXT>

No exemplo prático apresentado pela AWS, o modelo recebe um anúncio de marketplace que viola múltiplas categorias simultaneamente — um padrão comum em plataformas de comércio eletrônico. O modelo identifica corretamente as categorias de Crimes Não-Violentos (fraude) e Aconselhamento Especializado (conselho médico não qualificado), explicando os elementos específicos que acionam cada uma delas.

Formato JSON

Para sistemas que consomem JSON, o template produz saída estruturada diretamente nesse formato:

User: You are a text content moderator that detects policy violations, describes violated categories, and explains the reasoning behind your decisions. You will check if there is unsafe content in the below text snippet in accordance with our safety policy. Your moderation response should be in JSON format with the following structure:
`json
{
  "policy_violation": "Yes or No",
  "category_list": ["List of violated category codes"],
  "explanation": "Reason for the decision"
}
`
If there is no violation, use "C0" as the category code.

IMPORTANT: Do not add any additional text or explanation. Your response must contain ONLY the JSON object, nothing else.

[POLICY]
{{Policy definitions and categories}}

[TEXT]
{{Content to moderate}}

A instrução “não adicione nenhum texto adicional” ao final é o que mantém a saída limpa. Sem ela, o modelo pode envolver o JSON em texto conversacional, o que quebra o parsing nos sistemas downstream.

Prompts de formato livre

Prompts de formato livre são úteis quando você precisa de formatos de saída variados ou quando a tarefa de moderação não se encaixa em uma estrutura única. O guia apresenta três exemplos que usam estilos de formatação diferentes:

• Classificação Sim/Não: uma pergunta direta (“Este texto promove atividades prejudiciais?”) produz uma resposta binária concisa com breve justificativa
• Identificação de categoria com raciocínio: uma instrução para identificar qual categoria é violada e por quê gera uma análise mais detalhada
• Avaliação de severidade: solicitar uma classificação como “nenhuma”, “baixa”, “média” ou “alta” produz uma resposta estruturada em múltiplas partes

O mesmo modelo ajusta o formato de saída e o nível de detalhe com base em como a requisição é formulada. Essa flexibilidade torna os prompts de formato livre uma opção natural para fluxos de trabalho com revisão humana, onde os revisores precisam de diferentes níveis de detalhe dependendo do caso.

Benchmarks: Amazon Nova 2 Lite vs. outros modelos

A AWS avaliou o Amazon Nova 2 Lite contra outros modelos de fundação (Modelos de Fundação — FMs) em três benchmarks públicos de moderação de texto. Todos os modelos receberam o mesmo formato de prompt XML estruturado, sem arquitetura de agente ou camada de orquestração. As avaliações foram executadas em modo não-raciocínio com configurações padrão de inferência.

Métricas de avaliação

Três métricas orientam a avaliação:

• F1: média harmônica entre precisão e recall, de 0 a 100%. É a métrica principal porque a moderação exige tanto capturar violações quanto evitar falsos alarmes
• Precisão (Precision): mede com que frequência o modelo está correto quando sinaliza conteúdo — de tudo que foi sinalizado, quanto era realmente uma violação?
• Recall: mede quantas violações reais o modelo captura — alto recall significa menos conteúdo prejudicial passando despercebido

Datasets utilizados

• Aegis AI Content Safety 2.0: 2.777 amostras de teste (1.324 seguras, 1.453 inseguras) para classificação binária de violação de política. Licença CC-BY-4.0
• WildGuardMix: 3.408 amostras de teste (2.370 seguras, 1.038 inseguras) para classificação binária. Licença ODC-BY
• Jigsaw Toxic Comment Classification: reduzido para 5.000 amostras de teste (2.500 seguras, 2.500 inseguras) para classificação binária de conteúdo tóxico. Licença CC0 Domínio Público

Resultados

Os modelos concorrentes foram anonimizados como Modelo A, B e C, pois o foco da avaliação foi o desempenho absoluto do Nova 2 Lite, não um ranking competitivo.

Entre os quatro modelos testados, o Amazon Nova 2 Lite alcançou o maior F1 médio de 75,70%. No Aegis, ele lidera com 85,84% de F1, com precisão e recall quase equilibrados em 86,02% e 85,66% respectivamente. Esse equilíbrio importa na prática: o Modelo B, por comparação, atinge 91,16% de precisão no Aegis, mas paga por isso com apenas 71,64% de recall — o que significa deixar passar quase 30% das violações reais.

O benchmark Jigsaw derrubou os scores de F1 de todos os modelos para a faixa de 56%–59%, pois suas definições de toxicidade são mais ambíguas e dependentes de contexto do que as categorias explícitas do Aegis e WildGuard.

É importante notar que as diferenças entre os modelos são modestas e os resultados podem variar com diferentes designs de prompt, configurações de inferência ou distribuições de conteúdo. Esses benchmarks representam um recorte de desempenho sob condições específicas.

Moderação de conteúdo multimodal

Embora o guia foque em texto, a AWS destaca que moderação de imagens também é um caso de uso primário para o Amazon Nova 2. É possível passar uma imagem junto com um prompt de texto usando as mesmas definições de política e formato de saída descritos no guia — a abordagem é chamada de IPC (imagem mais contexto — image-plus-context). O Amazon Nova 2 também suporta moderação de frames de vídeo usando os mesmos padrões de prompting. Para detalhes sobre prompting com imagens e vídeo, a AWS disponibiliza o guia de prompting multimodal do Amazon Nova 2.

Boas práticas recomendadas

Com base na avaliação e no trabalho de engenharia de prompts, a AWS recomenda as seguintes práticas para moderação de conteúdo com o Amazon Nova 2 Lite. O guia completo de boas práticas de prompting para moderação detalha todas as recomendações.

• Defina políticas claras: seja usando a taxonomia AILuminate ou categorias próprias, forneça definições específicas no prompt. Políticas ambíguas produzem resultados inconsistentes
• Use exemplos few-shot: inclua pelo menos um par de entrada/saída de exemplo no prompt. Adicione mais exemplos para categorias que exigem julgamento mais refinado
• Combine o formato do prompt ao seu pipeline: use prompts estruturados (XML ou JSON) quando a saída alimenta sistemas automatizados; use prompts de formato livre para análise exploratória ou fluxos com revisão humana
• Solicite explicações para auditabilidade: explicações adicionam uma pequena sobrecarga de desempenho, mas ajudam revisores humanos a entender o raciocínio do modelo
• Teste os modos de raciocínio e não-raciocínio: para a maioria dos casos de moderação, o modo não-raciocínio produz resultados precisos com menor latência e custo
• Itere nos prompts: teste com amostras representativas do seu conteúdo real, revise os resultados e refine definições e exemplos com base nos erros do modelo
• Planeje guardrails para produção: use revisão humana para casos de borda e conteúdo ambíguo; considere roteamento baseado em confiança para auto-permitir conteúdo seguro de alta confiança, auto-remover violações claras e enfileirar casos limítrofes para revisão humana

Conclusão

O guia publicado pela AWS demonstra duas abordagens complementares de prompting para moderação de conteúdo com o Amazon Nova 2 Lite: prompts estruturados (XML e JSON) para pipelines automatizados, e prompts de formato livre para fluxos de revisão variados. Nos três benchmarks públicos avaliados, o Amazon Nova 2 Lite alcançou o maior F1 médio entre os modelos testados, com equilíbrio especialmente forte entre precisão e recall no dataset Aegis.

As técnicas não estão limitadas à taxonomia AILuminate — os mesmos padrões de prompt funcionam com definições de política customizadas para atender aos requisitos específicos de moderação de cada organização. Para começar, a AWS sugere definir a política de moderação, escolher o formato de prompt adequado, testar com amostras representativas no Amazon Bedrock e iterar com base nos erros encontrados.

Para referência adicional, confira o guia de prompting para moderação de conteúdo na documentação do Amazon Nova 2, e o post anterior sobre customização de moderação de texto com Amazon Nova via fine-tuning.

Fonte

Prompting Amazon Nova 2 for content moderation (https://aws.amazon.com/blogs/machine-learning/prompting-amazon-nova-2-for-content-moderation/)

Por que avaliação determinística importa em agentes de produção

Levar um agente de protótipo para produção exige medir qualidade em múltiplas dimensões. O Amazon Bedrock AgentCore Evaluations já oferecia verificações baseadas em Modelo de Linguagem Grande (LLM) no papel de juiz — o chamado LLM-as-a-Judge — para avaliar dimensões subjetivas como utilidade e coerência. Agora, a AWS amplia esse conjunto com os avaliadores personalizados baseados em código, que permitem capturar requisitos específicos de domínio com lógica determinística.

Em setores como serviços financeiros, a qualidade vai muito além da linguagem. Um agente de inteligência de mercado precisa citar preços de ações dentro de uma faixa configurável, seguir um fluxo obrigatório de identificação de corretores antes de acessar perfis financeiros, retornar saídas de ferramentas em um esquema Notação de Objeto JavaScript (JSON) estrito e não expor Informações de Identificação Pessoal (PII). Essas verificações precisam de código determinístico — que produza sempre o mesmo resultado para a mesma entrada — e seria caro ou impreciso delegá-las a um LLM.

Como os avaliadores baseados em código funcionam

Com os avaliadores personalizados baseados em código, a equipe traz uma função AWS Lambda como motor de avaliação. O controle sobre a lógica de pontuação é total: validação por expressões regulares (regex) e estrutural, consultas a dados externos, chamadas a outros serviços ou regras de negócio. O mesmo avaliador pode ser reutilizado em múltiplos contextos sem consumir tokens de um modelo de fundação (FM) a cada requisição.

No modo de avaliação sob demanda, o avaliador atua como uma barreira dentro de fluxos de desenvolvimento e pipelines de Integração Contínua e Entrega Contínua (CI/CD). No modo de avaliação online, ele pontua o tráfego de produção em tempo real. Com o controle total da lógica via Lambda, os avaliadores podem ser adaptados a qualquer necessidade e funcionam de forma consistente mesmo quando os rastros (traces) vêm de diferentes frameworks de agentes.

Ciclo de vida: de spans a resultados pontuados

Um avaliador baseado em código é uma função Lambda registrada no plano de controle do AgentCore. Quando uma avaliação é executada, o AgentCore assume uma função do Gerenciamento de Identidade e Acesso (IAM) na conta do usuário, invoca o Lambda com um payload contendo os spans OpenTelemetry (OTel) do agente e grava a resposta no Amazon CloudWatch Logs como resultado de avaliação.

O payload contém uma versão de esquema, ID do avaliador, nome do avaliador, nível de avaliação e um objeto de entrada com o array de spans OTel da sessão. Para avaliadores no nível de rastro (trace), um campo separado identifica o rastro específico a ser pontuado. Para avaliadores no nível de sessão, o AgentCore omite esse campo e o Lambda pontua a conversa completa.

A resposta do Lambda segue um contrato fixo. Em caso de sucesso, retorna um dicionário com um rótulo (por exemplo, PASS ou FAIL), uma pontuação numérica opcional entre 0,0 e 1,0, e uma string de explicação opcional. Em caso de falha, retorna um dicionário com código e mensagem de erro. O rótulo é obrigatório em toda resposta de sucesso. A pontuação e a explicação alimentam diretamente as métricas do CloudWatch e o painel de Observabilidade do AgentCore.

Cada avaliador opera em um de três níveis definidos no momento do registro: TRACE (por rastro de interação), TOOL_CALL (por chamada de ferramenta) ou SESSION (por sessão completa). Para usar o mesmo Lambda em múltiplos níveis, basta registrá-lo separadamente para cada nível apontando para a mesma função.

Modos de operação: sob demanda e online

O AgentCore Evaluations suporta avaliadores baseados em código em ambos os modos. Um único ID de avaliador serve para desenvolvimento, testes, barreiras de CI/CD e monitoramento contínuo de produção. O contrato do Lambda — incluindo payload, formato de resposta e configuração de IAM — permanece idêntico nos dois modos.

Avaliação sob demanda para desenvolvimento e CI/CD

A avaliação sob demanda se encaixa em três cenários principais:

• Iteração de desenvolvimento: capturar uma sessão, executar o conjunto de avaliadores, inspecionar pontuações e explicações por avaliador, e usar o feedback para guiar a próxima mudança no prompt, definições de ferramentas ou fluxo de memória.
• Testes de regressão: manter uma biblioteca de sessões representativas — incluindo sessões que revelaram falhas anteriormente — e executar o conjunto de avaliadores contra elas. Um avaliador que pontua abaixo do limite sinaliza uma regressão.
• Barreira de implantação em CI/CD: antes de promover uma nova versão do agente para produção, executar o conjunto de avaliadores contra sessões de smoke test e bloquear a implantação se um avaliador baseado em código falhar.

Uma única chamada sob demanda pode referenciar até 10 avaliadores, misturando tipos baseados em código e integrados. Para o agente de exemplo (Market Trends Agent), uma execução pré-implantação combina os avaliadores integrados de Utilidade e Correção com os quatro avaliadores baseados em código, confirmando qualidade de linguagem, integridade de contratos de ferramentas, precisão de preços, ordenação de fluxo de trabalho e segurança de PII em uma única passagem.

Avaliação online para monitoramento contínuo de produção

A avaliação online amostra continuamente o tráfego ao vivo do agente e o pontua contra os avaliadores configurados em uma agenda recorrente. Para configurá-la, é necessário criar uma configuração de avaliação online pelo plano de controle do AgentCore, especificando:

• Avaliadores: até 10 IDs de avaliadores, misturando tipos baseados em código e integrados.
• Fonte de dados: grupo de logs do CloudWatch e nome do serviço OTel para os spans do agente.
• Amostragem: percentual de sessões a avaliar (entre 0,01% e 100%).

A avaliação online é vinculada a um agente apontando diretamente para ele no AgentCore Runtime ou referenciando o grupo de logs do CloudWatch usado pelo agente. O AgentCore então agrupa os spans que representam uma conversa completa e executa a avaliação sobre elas. É possível ajustar o timeout de sessão para que o AgentCore saiba quando tratar uma sessão como concluída — esse timeout deve corresponder à duração típica das sessões do agente para evitar pontuar sessões ainda em andamento.

Cada pontuação de avaliador também aparece como uma métrica do CloudWatch no namespace Bedrock-AgentCore/Evaluations, identificada por nome do avaliador e ID de configuração. Isso permite construir dashboards que plotam validade de esquema, conformidade de fluxo de trabalho e limpeza de PII ao lado de Utilidade e Correção, oferecendo uma visão unificada de qualidade de linguagem e estrutural. Além disso, é possível configurar Alarmes do CloudWatch nessas métricas para alertar a equipe sempre que uma dimensão de qualidade cair abaixo de um limite importante.

Caso de uso: Market Trends Agent

A AWS usa como exemplo o Market Trends Agent, um assistente de inteligência de investimentos construído com LangGraph e implantado no Amazon Bedrock AgentCore Runtime. O código completo está disponível em 02-use-cases/market-trends-agent no repositório de exemplos do AgentCore.

O agente atende corretores financeiros com dados de ações, análise de notícias de múltiplas fontes e perfis de corretores armazenados no AgentCore Memory, adaptando análises à estratégia, interesses e tolerância a risco de cada corretor. A instrumentação OTel do LangGraph publica spans no Amazon CloudWatch através do AgentCore Observability, tornando o agente um ambiente de testes ideal para avaliadores baseados em código e LLM-as-a-Judge.

O exemplo inclui quatro avaliadores cobrindo validação de esquema, precisão numérica, conformidade de fluxo de trabalho e detecção de PII:

• ToolResponseSchemaValidator (nível de trace): filtra spans para o rastro alvo, identifica spans de chamada de ferramenta e verifica a resposta de cada ferramenta contra um padrão esperado — ticker e preço para dados de ações, comprimento e formatação para resumos de notícias.
• StockPriceDriftChecker (nível de trace): verifica preços citados nas respostas do agente contra uma fonte de verdade externa dentro de uma tolerância configurável (padrão de 2%). Extrai pares ticker-preço do texto da resposta, busca preços de referência em um endpoint de dados de mercado e calcula o desvio percentual por par.
• WorkflowContractGSR (nível de sessão): aplica um contrato de fluxo de trabalho de três etapas em toda a sessão: identificar o corretor, operar no perfil do corretor e depois chamar ferramentas de dados de mercado e notícias. O avaliador reconstrói a lista ordenada de chamadas de ferramentas a partir dos spans da sessão e verifica se cada etapa ocorreu na ordem correta.
• BrokerPIILeakChecker (nível de sessão): verifica cada resposta do agente em uma sessão em busca de PII usando a API Amazon Comprehend DetectPiiEntities. O Lambda classifica entidades detectadas em tipos de alto risco (CPF/SSN, cartão de pagamento, conta bancária, documento de identidade, credencial) e detalhes de contato de menor risco (nome, e-mail, telefone, endereço), aplicando limiares diferentes a cada categoria. PII de alto risco retorna FAIL; uso excessivo de PII de menor risco retorna pontuação parcial com contagens. Uma variante baseada em regex está incluída para ambientes que não podem depender do Comprehend.

Pré-requisitos e passos de implementação

O passo a passo leva cerca de 45 minutos e custa menos de US$ 5 em cobranças da AWS nas taxas de amostragem padrão. Para acompanhar, são necessários:

• Uma conta AWS com uma função IAM com acesso ao Amazon Bedrock AgentCore Runtime, Memory e Evaluations, AWS Lambda e Amazon CloudWatch.
• A Interface de Linha de Comando da AWS (AWS CLI) instalada e configurada com permissões para implantar recursos do AgentCore, funções Lambda, logs do CloudWatch e, opcionalmente, Amazon Comprehend.
• AgentCore Observability e CloudWatch Transaction Search habilitados, para que os spans OTel cheguem ao grupo de logs do runtime e ao grupo compartilhado aws/spans. O Transaction Search é uma adesão única no nível da conta — o AgentCore Evaluations não consegue amostrar spans sem ele.
• O repositório agentcore-samples clonado.

O código completo, incluindo o agente, os quatro Lambdas de avaliação e os scripts de implantação, está disponível no diretório do market trend agent. Os passos de implementação cobrem: implantar o Market Trends Agent, implantar os avaliadores, gerar tráfego de teste com quatro cenários integrados (fluxo de corretor feliz, corretor recorrente, isca de PII com CPF/SSN fabricado e conversa anônima), executar avaliação sob demanda e visualizar os resultados da avaliação online.

Se a configuração de avaliação não estiver produzindo resultados ou se houver erros ou pontuações vazias, a Habilidade de Diagnóstico de Avaliação do AgentCore pode ser usada para resolver o problema.

Boas práticas para avaliadores baseados em código

O ponto de partida é identificar as dimensões de qualidade determinísticas onde não há espaço para ambiguidade: restrições exatas de dados como IDs ou valores que devem corresponder a um formato específico, restrições estruturais como sequências obrigatórias de chamadas de ferramentas, e requisitos de conformidade incluindo políticas de PII ou regras regulatórias que precisam de aplicação comprovável. Os avaliadores LLM-as-a-Judge integrados ou personalizados continuam sendo a escolha certa para dimensões subjetivas como utilidade, tom, coerência e qualidade conversacional geral.

A tabela abaixo resume os níveis de avaliação disponíveis:

• TRACE: uma invocação Lambda por rastro, em paralelo — ideal para validação de esquema por resposta, verificações de precisão numérica e varredura de PII por resposta.
• TOOL_CALL: uma invocação Lambda por span correspondente — ideal para validar parâmetros de ferramentas e verificar frescor de recuperação.
• SESSION: uma invocação Lambda por sessão — ideal para verificações de ordenação de fluxo de trabalho, varreduras de PII em toda a sessão e avaliação de sucesso de objetivo.

A recomendação é validar o avaliador contra sessões reais conhecidas no modo sob demanda antes de promovê-lo para avaliação online. Isso confirma que ele detecta os problemas esperados com explicações claras e que integrações com sistemas externos — como detectores de PII ou motores de política — funcionam corretamente em termos de permissões e timeouts. Após essa validação, o avaliador pode ser incorporado ao pipeline de CI/CD como barreira de implantação e depois promovido ao monitoramento contínuo de produção.

Conclusão

Os avaliadores baseados em código estendem a cobertura do AgentCore para as dimensões de qualidade que exigem lógica determinística. No modo sob demanda, atuam como verificações de desenvolvimento e barreiras de implantação em CI/CD, retornando pontuações síncronas e explicações no nível de span. No modo online, o mesmo avaliador registrado pontua sessões de produção ao vivo ao lado dos avaliadores LLM-as-a-Judge integrados e emite resultados como métricas do CloudWatch.

Combinados com os avaliadores integrados, os avaliadores baseados em código movem a confiabilidade do agente do paradigma “parece correto” para o paradigma “verificado por contrato”. Como a lógica vive no Lambda da própria equipe, os verificadores podem evoluir conforme as regras de negócio mudam. Um único registro de avaliador serve para desenvolvimento local, barreiras de CI/CD e monitoramento contínuo de produção, oferecendo um sinal de qualidade consistente do protótipo até a escala.

Para começar, consulte a documentação do Amazon Bedrock AgentCore Evaluations, identifique as propriedades estruturais e de conformidade do seu agente que exigem verificações determinísticas, e implante os avaliadores de exemplo do repositório amazon-bedrock-agentcore-samples.

Fonte

Build custom code-based evaluators in Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/build-custom-code-based-evaluators-in-amazon-bedrock-agentcore/)

O problema que essa integração resolve

Quem trabalha com times de engenharia ou produto conhece bem o cenário: a documentação fica no Atlassian Confluence Cloud, os dados ficam em outros sistemas, e a equipe passa boa parte do dia alternando entre ferramentas para reunir contexto suficiente para tomar uma decisão. Esse vai e vem consome tempo e cria lacunas entre o conhecimento disponível e as ações que precisam ser tomadas.

Para resolver isso, a AWS detalhou como conectar o Confluence Cloud ao Amazon Quick, seu assistente de IA voltado para produtividade empresarial. Com essa integração, equipes conseguem consultar páginas do Confluence, recuperar documentação e até atualizar conteúdo — tudo por meio de consultas em linguagem natural, diretamente na interface do Quick, sem precisar abrir outra aba.

Como o Amazon Quick organiza as integrações

Antes de entrar no passo a passo, vale entender como o Quick categoriza suas integrações. Existem três tipos principais:

• Actions: conectam o Quick a sistemas externos no momento da consulta, permitindo leitura, escrita e automação de tarefas em tempo real.
• Knowledge bases (bases de conhecimento): indexam conteúdo não estruturado — como documentos e wikis — antes que o usuário faça a consulta, criando um índice pesquisável por linguagem natural.
• Topics e Datasets: permitem consultas em linguagem natural sobre fontes de dados estruturados, como o Amazon Redshift.

Este guia da AWS foca nas duas primeiras categorias: Knowledge bases e Actions. O Confluence Cloud suporta ambas as abordagens, e a combinação das duas é o que torna a integração tão poderosa.

Pré-requisitos para começar

Para seguir o tutorial, é necessário ter:

• Uma conta no Atlassian Confluence Cloud com permissões de administrador para criar aplicações OAuth 2.0 e gerenciar escopos de Controle de Acesso à Interface de Programação de Aplicações (API);
• Uma assinatura do Amazon Quick — plano Enterprise para criar integrações, ou Professional para usar integrações já existentes;
• Uma conta AWS com permissões adequadas de Gerenciamento de Identidade e Acesso (IAM) para acessar o Quick e criar integrações.

Do ponto de vista de segurança, a integração segue o modelo de responsabilidade compartilhada da AWS: a AWS cuida da segurança da infraestrutura, enquanto o cliente é responsável por configurar as permissões OAuth, gerenciar os escopos de API e garantir alinhamento com as políticas de governança de dados da organização. O Amazon Quick mantém a segurança dos dados com criptografia em repouso e em trânsito. Mais detalhes em segurança da AWS no Quick.

Criando a Knowledge Base do Confluence Cloud

Uma knowledge base no Quick é uma coleção indexada de documentos de fontes externas, otimizada para recuperação com Inteligência Artificial (IA) generativa e resposta a perguntas. No console do Quick, basta acessar a seção de Knowledge e selecionar a opção de integração com o Atlassian Confluence Cloud.

Para conectar a instância do Confluence, é preciso informar a URL base da conta — no formato suainstancia.atlassian.net — e aceitar o prompt de autorização OAuth. O Quick cuida de toda a autenticação automaticamente, sem necessidade de envolver a equipe de TI ou gerar chaves de API.

Controle de acesso por documento (ACLs)

Um recurso avançado disponível na integração são os Controles de Acesso em Nível de Documento (ACLs — Document-level Access Controls). Quando habilitados, o Quick verifica em tempo real as permissões de cada usuário no Confluence, garantindo que cada pessoa veja apenas o conteúdo ao qual já tem acesso. Para isso, são necessárias credenciais de administrador do Atlassian: chave de API, ID da organização e ID do diretório. Mais detalhes na documentação de controles de acesso em nível de documento.

Quando os ACLs estão habilitados, o Quick rastreia as seguintes permissões do Confluence:

• Spaces (espaços): as permissões do espaço se aplicam a todos os documentos por padrão;
• Pages (páginas): podem ser restritas a usuários e grupos específicos; páginas aninhadas herdam as restrições da página pai;
• Blogs: posts de blog podem ser restritos a usuários e grupos específicos do espaço;
• Attachments (anexos): arquivos anexados herdam os controles de acesso do documento pai.

Se os ACLs não forem habilitados, o controle de acesso ocorre no nível da knowledge base: qualquer pessoa com acesso à base consegue obter respostas de todo o conteúdo indexado.

Configurando permissões e sincronização

Após criar a knowledge base, ela aparece na seção de bases existentes com um indicador de status de sincronização. Quando a sincronização é concluída, o status muda para “Available” (disponível). Na página de detalhes da knowledge base, é possível visualizar o resumo, os agendamentos de sincronização, os relatórios de sincronização e as permissões. O relatório de sincronização permite baixar um arquivo CSV com detalhes sobre itens sincronizados, ignorados ou com falha.

Criando Actions para o Confluence

Enquanto as knowledge bases lidam com a amplitude — indexando e tornando o conteúdo pesquisável — as Actions entregam precisão. Elas conectam o Quick diretamente às APIs do Confluence em tempo real, permitindo criar páginas, atualizar conteúdo, recuperar registros específicos e acionar fluxos de trabalho.

O Quick suporta a integração de Actions com o Confluence Cloud via autenticação de usuário (3LO — Three-Legged OAuth) e autenticação de serviço por chave de API. O tutorial da AWS foca na autenticação de usuário (3LO).

Criando a aplicação OAuth 2.0 no Atlassian

O primeiro passo é criar uma aplicação OAuth 2.0 no console de desenvolvedores da Atlassian. Acesse a página de desenvolvedores da Atlassian, vá ao Developer Console e crie uma nova integração OAuth 2.0 (3LO). Após criar a aplicação, configure a URL de callback no seguinte formato:

https://{region}.quicksight.aws.amazon.com/sn/oauthcallback

Substitua {region} pela região AWS onde o Quick está implantado.

Configurando os escopos de API necessários

Na página de permissões da aplicação, é preciso configurar os seguintes escopos:

• User Identity API:
  • read:me — visualizar o perfil do usuário ativo;
  • read:account — visualizar perfis de usuário.
• Confluence API (escopos clássicos e granulares):
  • search:confluence — pesquisar conteúdo no Confluence (escopo clássico);
  • read:page:confluence — ler conteúdo de páginas (escopo granular);
  • write:page:confluence — criar e modificar páginas (escopo granular);
  • read:space:confluence — acessar informações de espaços (escopo granular).

Para mais detalhes sobre escopos, consulte a documentação da Atlassian sobre implementação do OAuth 2.0 (3LO) e como determinar os escopos necessários para cada operação.

Configurando a integração no Quick

Com a aplicação OAuth criada, o próximo passo é configurar a Action no Quick. Na página de conectores, selecione o card do Atlassian Confluence Cloud e escolha a opção de OAuth app personalizado. Os campos necessários são: URL base, Client ID, Client Secret, Token URL, URL de autenticação e URL de redirecionamento. Para referência sobre cada campo, consulte a documentação da integração Atlassian Confluence Cloud.

A URL base segue o formato https://api.atlassian.com/ex/confluence/seuInstanceId. O Client ID e o Client Secret são obtidos na página de configurações da aplicação OAuth criada anteriormente. Após publicar a integração, ela aparecerá com status “Connected” (conectado), e o usuário precisa fazer login para autorizar o acesso do Quick à conta do Confluence.

Organizando tudo com Quick Spaces

O Quick oferece um recurso chamado Spaces (espaços) que permite agrupar knowledge bases, Actions, arquivos e dashboards em uma única coleção organizada. Para a integração com o Confluence, isso significa ter um hub centralizado onde todos os recursos relacionados ficam juntos, facilitando tanto o uso individual quanto a colaboração em equipe.

Um Space com o Confluence configurado desbloqueia valor em várias frentes: colaboração em equipe com uma visão consistente e governada do conteúdo, criação de agentes customizados que usam a documentação do Confluence como base de conhecimento, automação de fluxos de trabalho com Quick Flows, e análises aprofundadas com Quick Research.

Consultando o Confluence em linguagem natural

Com o Space configurado, basta abrir o chat do Quick e fazer perguntas sobre o conteúdo do Confluence. O Quick retorna respostas detalhadas com referências às fontes originais — é possível verificar exatamente de qual página do Confluence a informação foi extraída.

Executando Actions no Confluence

As Actions permitem criar, atualizar e gerenciar páginas e espaços diretamente pelo Quick. Um caso de uso prático é consolidar respostas geradas a partir de múltiplas fontes e publicar o resultado diretamente em uma página do Confluence. Antes de executar a ação, o Quick exibe um card de revisão com botões de “Allow” (permitir) e “Deny” (negar), além de um formulário para inspecionar os detalhes da página — título, ID do espaço e conteúdo — antes de aprovar. O Quick preserva automaticamente a formatação da resposta ao criar a página, incluindo cabeçalhos, listas e conteúdo estruturado.

Solução de problemas e referências

Para resolver problemas com a integração, a AWS disponibiliza a documentação de resolução de problemas da integração Atlassian Confluence e as perguntas frequentes do Quick.

Para quem quiser colocar a mão na massa, a AWS sugere os seguintes próximos passos:

• Iniciar um teste gratuito para experimentar a recuperação de conhecimento com IA em conteúdo corporativo;
• Conectar a primeira integração com o Confluence Cloud para extrair valor imediato da documentação existente;
• Criar um agente de chat personalizado adaptado aos domínios de conhecimento e fluxos de trabalho do time;
• Construir um Space para agregar recursos críticos e facilitar a colaboração entre times.

Para orientações detalhadas de implementação e boas práticas, consulte o Guia do Usuário do Quick.

Fonte

Integrate Atlassian Confluence Cloud with Amazon Quick (https://aws.amazon.com/blogs/machine-learning/integrate-atlassian-confluence-cloud-with-amazon-quick/)

O que mudou no AWS Partner Central

A AWS anunciou uma atualização relevante para os parceiros que utilizam o AWS Partner Central: agora é possível criar oportunidades de negócio por meio de conversa em linguagem natural, sem precisar preencher formulários longos e com múltiplas etapas. A novidade chega como uma evolução dos agentes do AWS Partner Central, lançados originalmente em 16 de março de 2026.

Como funcionam os agentes do AWS Partner Central

Os agentes são capacidades baseadas em Inteligência Artificial (IA), construídas sobre o Amazon Bedrock AgentCore. Eles foram desenvolvidos para ajudar os parceiros da AWS a extrair insights do pipeline de vendas, avançar negociações com recomendações de próximos passos e identificar oportunidades de financiamento.

Com a atualização anunciada, o processo de criação de oportunidades ficou significativamente mais simples. Em vez de preencher um formulário extenso, o parceiro pode:

• Descrever um negócio em linguagem natural, como se estivesse explicando para um colega;
• Fazer upload de anotações de reuniões, propostas ou transcrições de chamadas nos formatos PDF, DOCX, Excel ou TXT;
• Clonar uma oportunidade já existente como ponto de partida.

A partir dessas entradas, o agente extrai as informações relevantes, enriquece os dados do cliente e ainda sugere melhorias — como adicionar contexto que esteja faltando, corrigir valores de campos ou fortalecer a descrição do problema de negócio. O resultado são oportunidades de maior qualidade, com melhor higiene de pipeline e ciclos de venda mais curtos.

Como acessar o recurso

Os parceiros podem utilizar os agentes diretamente pelo Console da AWS, por meio do chat do Amazon Q. Também é possível integrar o recurso de forma programática, através do Protocolo de Contexto de Modelo (MCP — Model Context Protocol), permitindo que as equipes de vendas criem oportunidades diretamente a partir das ferramentas que já utilizam no dia a dia.

Os agentes do AWS Partner Central estão disponíveis em todas as regiões comerciais da AWS.

Por onde começar

Para quem quer explorar o recurso, a AWS indica acessar o AWS Partner Central pelo Console da AWS e navegar até a seção de oportunidades. Antes de começar, vale revisar o guia dos agentes. Para quem deseja integrar os agentes às ferramentas existentes, o ponto de partida é o guia do servidor MCP dos agentes do Partner Central. Para uma visão mais aprofundada das capacidades agênticas no AWS Partner Central, a AWS também disponibilizou um post no blog oficial.

Fonte

AWS Partner Central agents now accelerates opportunity creation (https://aws.amazon.com/about-aws/whats-new/2026/05/aws-partner-central-agents-oppo)