Author: Make.com Service User

O problema que o AgentCore Harness resolve

Existe uma definição de agente de Linguagem de Modelo Grande (LLM, do inglês Large Language Model) que ficou famosa na comunidade: um agente LLM executa ferramentas em loop para atingir um objetivo. Simples assim. E é exatamente isso que Kiro, Amazon Q Developer, Codex e Claude Code fazem por baixo dos panos — todos rodam a mesma estrutura de loop.

O problema nunca foi o loop em si. Foi tudo ao redor dele. Escolher um framework, conectar ferramentas, provisionar ambientes isolados, configurar armazenamento, segredos e rede, decidir onde a memória vive, adicionar observabilidade, empacotar dependências no contêiner certo. Um desenvolvedor consegue subir um agente no laptop em uma tarde. Mas levar isso para produção é onde o trabalho explode — especialmente quando o agente precisa atender mais de um usuário ao mesmo tempo: concorrência, isolamento, identidade, estado e escalonamento entram em cena de uma vez.

Pior ainda: esse overhead se repetia a cada novo caso de uso. Trocar de modelo, adicionar uma ferramenta, apontar o agente para um novo domínio — tudo exigia refazer o mesmo encanamento. O gargalo não era inteligência. Era orquestração e infraestrutura.

O AgentCore Harness foi criado para resolver exatamente isso. Os primitivos do AgentCore (Runtime, Memory, Gateway, Browser, Identity, Observability) já existiam. O harness é a camada que conecta tudo isso automaticamente, transformando o que antes era código em configuração.

O que é o AgentCore Harness na prática

O harness é tudo que um agente precisa para rodar em produção, exposto por duas chamadas de API: CreateHarness para definir o agente e InvokeHarness para executá-lo. Você aponta para o modelo, as ferramentas, as habilidades e as instruções desejadas. O AgentCore cuida do ambiente isolado, da memória, do armazenamento, da identidade e da observabilidade.

O agente roda em seu próprio ambiente isolado com sistema de arquivos e shell, podendo ler arquivos, executar comandos e escrever código com segurança. Ele lembra usuários e conversas entre sessões, carrega habilidades sob demanda, navega na web, chama ferramentas via Gateway ou MCP (Protocolo de Contexto de Modelo, do inglês Model Context Protocol), e troca de provedor de modelo no meio de uma sessão sem perder contexto. Cada etapa é transmitida em tempo real e rastreada automaticamente no CloudWatch.

Capacidades principais do Harness

Qualquer modelo, com troca a qualquer momento

Tarefas diferentes pedem modelos diferentes. A AWS atendeu a pedidos de clientes que queriam planejar com um modelo, executar com outro, ou migrar de provedor para testes de custo-benefício — tudo sem perder a conversa. O modelo padrão é definido no CreateHarness e pode ser sobrescrito em qualquer chamada individual de InvokeHarness.

Os provedores suportados são: bedrock para qualquer modelo no Amazon Bedrock (Anthropic Claude, Amazon Nova, Meta Llama, DeepSeek, Qwen, Kimi, MiniMax, Cohere, Mistral e, mais recentemente, OpenAI GPT-5.5 e GPT-5.4 no Bedrock); openAi para acesso direto à API da OpenAI; gemini para o Google Gemini; e liteLlm para qualquer provedor terceiro suportado pelo LiteLLM, incluindo Anthropic direto, Cohere, Mistral, Vertex e Azure OpenAI.

Chaves de API de provedores externos ficam armazenadas com segurança no cofre de tokens do AgentCore Identity. O agente nunca acessa credenciais brutas.

Ferramentas como configuração

Ferramentas são como o agente afeta o mundo além do próprio raciocínio. O harness permite declarar o que o agente pode usar e cuida da conexão, autenticação e execução automaticamente. Os tipos disponíveis são:

• agentcore_gateway: referencia um AgentCore Gateway por ARN (Nome de Recurso da Amazon, do inglês Amazon Resource Name). Cada alvo exposto pelo gateway (OpenAPI, Smithy, Lambda, MCP) vira uma ferramenta, com autenticação IAM/JWT e controle por ferramenta.
• remote_mcp: conexão direta a qualquer servidor MCP por URL, útil quando o servidor já está seguro e não precisa da camada de governança do Gateway.
• agentcore_browser: um sandbox completo de navegador em uma linha de configuração — clique, digitação, navegação e captura de tela.
• agentcore_code_interpreter: execução isolada de Python e Node, no mesmo padrão de uma linha.
• inline_function: um esquema de ferramenta que o harness emite como evento no stream e aguarda resposta, útil para aprovações humanas no loop ou ferramentas que precisam rodar do lado do cliente.

Cada sessão também recebe automaticamente shell integrado e operações de arquivo, sem precisar listá-los explicitamente.

"tools": [
  { "type": "agentcore_browser" },
  { "type": "agentcore_code_interpreter" },
  {
    "type": "remote_mcp",
    "name": "X_tool",
    "config": {
      "remoteMcp": {
        "url": "https://mcp.X_tool/mcp"
      }
    }
  },
  {
    "type": "agentcore_gateway",
    "name": "Y_tool",
    "config": {
      "agentCoreGateway": {
        "arn": "arn:aws:bedrock-agentcore:..."
      }
    }
  }
]

Memória integrada por padrão

Clientes querem que o agente reconheça um usuário que retorna, retome a conversa de onde parou e lembre preferências sem reproduzir o histórico inteiro. Na versão de prévia, era preciso provisionar um recurso de memória separado e passar o ARN. Na versão geral, omitir a configuração de memória no CreateHarness já provisiona uma memória gerenciada automaticamente, com padrões sensatos: estratégias SEMANTIC + SUMMARIZATION, expiração de eventos em 30 dias, criptografia gerenciada pela AWS e isolamento multi-tenant por padrão.

As três opções de configuração de memória são:

// Memória gerenciada automática
"memory": {
  "managedMemoryConfiguration": {
    "strategies": ["SEMANTIC", "SUMMARIZATION"],
    "eventExpiryDuration": 30
  }
}

// Trazer memória existente (BYO)
"memory": {
  "agentCoreMemoryConfiguration": {
    "arn": "arn:aws:bedrock-agentcore:..."
  }
}

// Agente sem estado
"memory": {
  "disabled": {}
}

A memória gerenciada é automática, mas não é opaca: é um recurso AWS real e endereçável que pode ser consultado, anexado a outro agente, auditado ou entregue a um pipeline de análise.

Habilidades: conhecimento especializado sob demanda

Habilidades são pacotes de arquivos, scripts e instruções que ensinam o agente a lidar com tarefas específicas antes de tentar executá-las — como formatar um relatório Excel, abrir um ticket no JIRA do jeito que o time faz, ou seguir procedimentos recomendados da AWS para acessar dados. O harness carrega os metadados da habilidade e puxa o conteúdo completo para o contexto apenas quando a tarefa realmente exige.

O tipo HarnessSkill é uma union com quatro fontes:

• awsSkills: ativa o pacote de habilidades curado pela AWS sem nenhuma configuração adicional.
• git: clona um repositório público ou privado via HTTPS, fixado em um commit ou branch.
• s3: puxa um pacote de habilidades do seu próprio bucket do Amazon S3.
• path: referencia um caminho já existente no contêiner que você trouxe.

"skills": [
  { "awsSkills": {*} },
  {
    "git": {
      "uri": "https://github.com/anthropics/skills",
      "path": "document-skills/xlsx"
    }
  },
  {
    "s3": {
      "uri": "s3://my-bucket/skills/team-sops/"
    }
  }
]

O grande desbloqueio para quem constrói na AWS: o repositório de habilidades AWS traz habilidades curadas cobrindo toda a superfície AWS — desde habilidades centrais (uso do SDK, Infraestrutura como Código (IaC), Gerenciamento de Identidade e Acesso AWS (IAM), Amazon CloudWatch e Amazon Bedrock) até fluxos de trabalho específicos para analytics, bancos de dados, Amazon EC2, rede, segurança, serverless e armazenamento. O toggle awsSkills ativa tudo isso sem URL, sem busca de rede — as habilidades já estão embutidas no runtime do harness.

aws bedrock-agentcore-control create-harness \
  --harness-name myAgent \
  --skills '[{"awsSkills": {}}]'

# OU com escopo para pacotes específicos
aws bedrock-agentcore-control create-harness \
  --harness-name myAgent \
  --skills '[{"awsSkills": {"paths": ["core-skills/*", "specialized-skills/operations-skills/*"]}}]'

Ambiente e sistema de arquivos

A maioria dos agentes roda bem no ambiente padrão do harness, que inclui Python e bash. Quando é preciso mais — uma dependência privada, uma versão específica de runtime, uma ferramenta de linha de comando, ou persistência entre sessões — dois controles permitem moldar o ambiente:

Imagem de contêiner: Empacote código-fonte, dependências e ferramentas em um contêiner customizado, envie para o Amazon ECR (Registro de Contêiner Elástico, do inglês Elastic Container Registry) e referencie no CreateHarness. Pode ser combinado com InvokeAgentRuntimeCommand, uma API que executa comandos shell diretamente dentro da microVM da sessão para configurações que variam por invocação.

Sistema de arquivos: O harness oferece três opções com diferentes características de alcance e persistência:

• Armazenamento de sessão gerenciado: persiste entre ciclos de parada/retomada da mesma sessão.
• Ponto de acesso Amazon EFS (Sistema de Arquivos Elástico, do inglês Elastic File System): compartilhável entre múltiplos harnesses e sessões, requer VPC (Nuvem Privada Virtual, do inglês Virtual Private Cloud).
• Ponto de acesso Amazon S3 Files: durabilidade total do S3, versionamento e histórico, acessível por operações de arquivo padrão com sincronização automática com o bucket.

Observabilidade unificada

Quando algo dá errado, clientes querem saber em um único lugar o que o agente executou, o que chamou, onde ficou lento e onde falhou. Uma invocação típica do harness atravessa Runtime + Memory + Gateway + ferramentas integradas, e montar esse quadro costumava exigir abrir cinco abas diferentes.

Na versão geral, cada página de harness no console do AgentCore exibe um widget único de observabilidade com um resumo agregado de todos os primitivos tocados. O CloudWatch GenAI Observability ganhou uma aba dedicada para Harnesses, permitindo navegar de um harness para uma sessão, e de uma sessão para um trace individual — com logs de cada primitivo (memória, gateway, browser, interpretador de código) exibidos inline no span correto.

Avaliação e otimização contínua

Depois que o agente está em produção, a pergunta muda de “funciona?” para “está melhorando?”. Dois recursos fecham esse ciclo:

AgentCore Evaluations pontua traces do harness com avaliadores LLM-como-juiz integrados (utilidade, fidelidade, segurança) ou com avaliadores customizados. Podem rodar online (pontuando cada sessão em tempo real), sob demanda para um trace específico, em lote sobre traces históricos, contra um dataset fixo de testes, ou como simulação com usuários sintéticos.

AgentCore optimization lê essas pontuações e gera recomendações de prompt e descrição de ferramentas, depois valida essas mudanças roteando tráfego real entre duas variantes via AgentCore Gateway, com pontuação por sessão e relatório de significância estatística. Variantes podem ser diferentes versões de um bundle de configuração no mesmo runtime, ou versões apontando para endpoints diferentes — permitindo testes A/B de prompts sem reimplantar código.

Versionamento e rollback instantâneo

Cada UpdateHarness cria uma versão imutável capturando a configuração completa (modelo, prompt de sistema, ferramentas, configuração de memória, habilidades, ambiente, limites de execução). Rollback é simplesmente apontar o endpoint para uma versão anterior:

# Criar endpoint PROD fixado na versão 2
aws bedrock-agentcore-control create-harness-endpoint \
  --harness-id my-harness-xxx --endpoint-name PROD --harness-version 2

# Promover versão 5 para PROD (ou fazer rollback para versão 4)
aws bedrock-agentcore-control update-harness-endpoint \
  --harness-id my-harness-xxx --endpoint-name PROD --harness-version 5

O endpoint DEFAULT avança automaticamente a cada atualização. Endpoints nomeados (PROD, STAGING) ficam fixos até promoção explícita.

Exportar para código quando a configuração não é suficiente

Quando um caso de uso supera o que a configuração oferece — orquestração customizada, coordenação multi-agente, instrumentação profunda — um único comando CLI exporta o harness como código baseado em Strands, que pode ser hospedado no AgentCore Runtime ou em qualquer outro lugar:

agentcore export harness --name myHarness-6dk4df --output ./my-agent

O projeto exportado preserva modelo, prompt, ferramentas, memória, habilidades e ambiente de contêiner. É uma tradução de configuração para código, não uma troca de arquitetura. Strands é o primeiro alvo de exportação; o Claude Agent SDK está chegando em breve.

Integrações adicionais

A AWS também anunciou duas adições notáveis:

• Integração com AWS Step Functions: uma invocação de harness agora é um estado de primeira classe no Step Functions. No Workflow Studio, basta buscar por AgentCore InvokeHarness e arrastar para o fluxo de trabalho.
• Web Search no AgentCore: disponível para agentes harness via AgentCore Gateway. Um tipo de ferramenta agentcore_web_search nativo está chegando em breve, seguindo o padrão de uma linha do browser e do interpretador de código.

Exemplos práticos de uso

A AWS ilustrou três casos de uso concretos que equipes montavam manualmente antes do harness:

Agente de pesquisa e escrita: busca na web, navega em fontes, redige um documento e entrega arquivos xlsx ou pptx reais, com memória persistindo entre sessões. Configuração mínima: CreateHarness com agentcore_browser como ferramenta, um alvo de Gateway expondo Web Search, e uma habilidade git apontando para o bundle de document-skills. Memória ativa por padrão.

Agente de dados e analytics AWS para a equipe: puxa dados de Amazon Athena, AWS Glue, Amazon S3, Amazon Redshift e Amazon CloudWatch, roda análises e entrega resumos ou gráficos, seguindo procedimentos recomendados da AWS para cada serviço. Configuração mínima: skills: [{"awsSkills": {}}], um executionRoleArn com escopo adequado, e opcionalmente agentcore_code_interpreter para análise em Python.

Agente de codificação: lê a base de código, planeja uma mudança, escreve, roda os testes e abre um pull request, com troca de modelo no meio da sessão sem perder contexto. Configuração mínima: contêiner customizado com repositório e toolchain enviado ao Amazon ECR, mais um alvo de Gateway conectado ao GitHub (ou GitLab/Bitbucket interno). Operações git determinísticas podem ser executadas diretamente via InvokeAgentRuntimeCommand, sem passar pelo modelo.

Modelo de preços: pague pelo que usar

Não há taxa adicional pelo harness. O pagamento é pelos recursos subjacentes com base no consumo real:

• Compute do Runtime: precificação por consumo ativo — US$ 0,0895 por vCPU-hora, US$ 0,00945 por GB-hora. Cobra apenas quando a CPU está efetivamente em uso.
• Browser e Code Interpreter: mesmo modelo de consumo ativo.
• Gateway: por mil invocações e por mil consultas de busca.
• Memory: por mil eventos de curto prazo, por mil registros de longo prazo por mês, por mil recuperações.
• Observabilidade: preços padrão do Amazon CloudWatch para spans, logs e métricas.
• Inferência de modelo: cobrado pelo Amazon Bedrock ou pelo provedor terceiro nas tarifas padrão deles.

Detalhes completos estão disponíveis na página de preços do AgentCore.

Disponibilidade e como começar

O Amazon Bedrock AgentCore Harness está disponível hoje em todas as regiões AWS onde o AgentCore está disponível. Para começar:

# CLI (caminho mais rápido)
npm install -g @aws/agentcore@preview
agentcore create --name myresearchagent --model-provider bedrock
agentcore deploy
agentcore invoke "Plan a 5-day Tokyo itinerary with daily budgets and reservation links."

# SDK
import boto3, uuid
control = boto3.client("bedrock-agentcore-control", region_name="us-west-2")
data = boto3.client("bedrock-agentcore", region_name="us-west-2")

# 1. Definir
harness = control.create_harness(
  harnessName="MyAgent",
  executionRoleArn="arn:aws:iam::123456789012:role/MyAgentRole"
)

# 2. Invocar
session_id = str(uuid.uuid4()).ljust(33, "0")  # deve ter no mínimo 33 caracteres
response = data.invoke_harness(
  harnessArn=harness["harnessArn"],
  runtimeSessionId=session_id,
  messages=[{"role": "user", "content": [{"text": "Plan a 5-day Tokyo itinerary."}]}]
)
for event in response["stream"]:
  print(event)

Recursos adicionais para aprofundamento: guia de início rápido, exemplos no GitHub, visão geral do AgentCore Harness, modelos e instruções, habilidades, memória, ambiente e sistema de arquivos, observabilidade e controles de custo, versionamento e endpoints, exportar para código, segurança e controles de acesso, Harness vs Runtime, API CreateHarness e API InvokeHarness.

Fonte

Amazon Bedrock AgentCore harness is now generally available: Go from idea to production-grade agent in minutes (https://aws.amazon.com/blogs/machine-learning/amazon-bedrock-agentcore-harness-is-now-generally-available-go-from-idea-to-production-grade-agent-in-minutes/)

O que foi anunciado

A AWS anunciou a disponibilidade geral das instâncias Amazon EC2 G7, aceleradas pelas GPUs NVIDIA RTX PRO 4500 Blackwell Server Edition. Trata-se de uma atualização significativa em relação à geração anterior: as novas instâncias entregam até 4,6x mais desempenho em inferência de IA e até 2,1x mais desempenho gráfico em comparação com as instâncias G6.

Para quais cargas de trabalho as G7 são indicadas

As instâncias G7 foram projetadas para atender a três grandes categorias de uso:

• Inferência de IA: tradução de idiomas, análise de vídeo e imagem, reconhecimento de fala e sistemas de recomendação.
• Workloads gráficos: criação e renderização de gráficos em tempo real com qualidade cinematográfica, além de streaming de jogos.
• Análise de dados: pipelines de processamento de dados em larga escala.

Especificações técnicas

Em termos de hardware, as instâncias G7 contam com:

• Até 8 GPUs NVIDIA RTX PRO 4500 Blackwell Server Edition, com 32 GB de memória por GPU;
• Processadores Intel Xeon 6 customizados;
• Até 700 Gbps de largura de banda de rede via Adaptador de Malha Elástica (EFA — Elastic Fabric Adapter).

Disponibilidade e formas de contratação

As instâncias G7 já estão disponíveis em duas regiões da AWS: Leste dos EUA (Ohio) e Oeste dos EUA (Oregon). É possível contratá-las como:

• Instâncias On-Demand (sob demanda);
• Parte dos Savings Plans (planos de economia);
• Instâncias Spot.

Como começar

Para provisionar instâncias G7, você pode utilizar o Console de Gerenciamento da AWS, a Interface de Linha de Comando da AWS (CLI) ou os SDKs da AWS. Para aprofundar o conhecimento técnico, a AWS também disponibilizou um post no blog oficial e a página dedicada às instâncias G7.

Fonte

Amazon EC2 G7 instances are now generally available (https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-ec2-g7-generally-available)

O desafio de monitorar inferência de IA generativa em escala

Operar endpoints de Grandes Modelos de Linguagem (LLMs) em produção é uma tarefa complexa. Quando a latência P99 de um endpoint dispara, a equipe precisa descobrir em minutos se o problema é pressão na memória da GPU, saturação do cache KV, tráfego desbalanceado entre Zonas de Disponibilidade (AZs) ou uma política de auto scaling que ainda não foi ativada. Engenheiros de plataforma de Aprendizado de Máquina (ML), times de Operações de ML (MLOps) e Engenheiros de Confiabilidade de Site (SREs) precisam manter endpoints saudáveis, responsivos e com custo eficiente — muitas vezes gerenciando dezenas de modelos em centenas de instâncias de GPU.

Para endereçar esse cenário, a AWS anunciou uma expansão significativa nas capacidades de observabilidade do Amazon SageMaker AI: mais de 100 novas métricas detalhadas de inferência, além de um dashboard nativo integrado ao Amazon CloudWatch chamado SageMaker Insights.

Arquiteturas de endpoint suportadas

O SageMaker AI oferece hospedagem gerenciada de inferência em tempo real. Ao implantar um modelo em um endpoint do SageMaker, o serviço cuida do provisionamento e do escalonamento das instâncias. Existem duas arquiteturas principais relevantes para cargas de trabalho de IA generativa com observabilidade detalhada:

• Endpoints de modelo único (SME — Single-Model Endpoint): cada endpoint hospeda um modelo em instâncias dedicadas. São simples de configurar, mas cada modelo exige sua própria frota de GPUs.
• Endpoints com componentes de inferência (IC — Inference Component): múltiplos modelos compartilham o mesmo conjunto de instâncias por meio de componentes de inferência. Cada componente define um modelo, seus requisitos de recursos (CPU, GPU, memória) e sua política de escalonamento. Essa é a arquitetura recomendada para produção, pois suporta hospedagem multi-modelo em infraestrutura GPU compartilhada, escalonamento independente por modelo e alta disponibilidade (HA) com distribuição de cópias entre AZs.

Para mais detalhes sobre inferência no SageMaker, consulte a documentação Implante modelos para inferência em tempo real.

O que são as novas métricas detalhadas

Anteriormente, os endpoints do SageMaker emitiam métricas agregadas como contagens de invocação, latência do modelo e latência de overhead. Úteis para uma visão geral, mas insuficientes para diagnóstico profundo em frotas de GPU com múltiplos modelos.

Agora, o SageMaker AI emite mais de 100 métricas detalhadas de inferência cobrindo: saúde da GPU, latência no nível de token, pressão no cache KV, distribuição de tráfego entre AZs, posicionamento de componentes de inferência e diagnósticos de cold start. Essas métricas utilizam o formato nativo OpenTelemetry e fluem para o CloudWatch, onde ficam disponíveis no dashboard SageMaker Insights — sem necessidade de configurar Grafana ou Prometheus manualmente. Para entender o suporte a OpenTelemetry e PromQL no CloudWatch, veja o post Introduzindo suporte a OpenTelemetry PromQL no Amazon CloudWatch.

O dashboard SageMaker Insights fica localizado no console do CloudWatch em Infrastructure Monitoring → SageMaker Insights e organiza as visualizações em três abas: Performance, Capacity e Reliability.

Pré-requisitos

Para utilizar as métricas detalhadas, são necessários: uma conta AWS com pelo menos um endpoint de inferência em tempo real do SageMaker; permissões de Gerenciamento de Identidade e Acesso (IAM — Identity and Access Management) para sagemaker:CreateEndpointConfig, sagemaker:UpdateEndpoint e cloudwatch:GetMetricData; e o framework de container vLLM ou SGLang (necessário para métricas no nível de token, como Tempo para o Primeiro Token (TTFT — Time to First Token) e Latência Entre Tokens (ITL — Inter-Token Latency)). Instâncias de GPU recebem métricas de utilização por acelerador, além das métricas de CPU e memória disponíveis em todos os tipos de instância. Para o guia completo de configuração, consulte Primeiros passos com observabilidade detalhada.

Ativando métricas detalhadas nos endpoints

Novos endpoints: ativação automática

Para qualquer nova configuração de endpoint criada, as métricas detalhadas já vêm ativadas por padrão. O parâmetro EnableDetailedObservability na configuração do endpoint assume o valor true automaticamente. Nenhum código adicional é necessário:

import boto3
sm = boto3.client("sagemaker")

# Create endpoint config — observability turned on by default
response = sm.create_endpoint_config(
    EndpointConfigName="my-llm-config",
    ProductionVariants=[{
        "VariantName": "primary",
        "InstanceType": "ml.g6.4xlarge",
        "InitialInstanceCount": 2,
        "ManagedInstanceScaling": {
            "Status": "ENABLED",
            "MinInstanceCount": 2,
            "MaxInstanceCount": 8
        }
    }],
    ExecutionRoleArn="arn:aws:iam::123456789012:role/SageMakerExecutionRole"
)

Também é possível definir explicitamente a frequência de publicação usando MetricsPublishFrequencyInSeconds no MetricsConfig. O padrão é 60 segundos, mas para cargas de trabalho que precisam de monitoramento quase em tempo real, esse valor pode ser reduzido.

# Create endpoint
sm.create_endpoint(
    EndpointName="my-llm-endpoint",
    EndpointConfigName="my-llm-config"
)

Dentro de 2 minutos após o endpoint atingir o estado InService, as métricas no formato OpenTelemetry começam a fluir para o CloudWatch.

Endpoints existentes: opt-in explícito

Endpoints já existentes exigem uma ativação explícita. É necessário criar uma nova configuração de endpoint com a flag MetricsConfig e então atualizar o endpoint:

# Step 1: Create new config with detailed observability turned on
sm.create_endpoint_config(
    EndpointConfigName="my-existing-config-v2",
    ProductionVariants=[{
        "VariantName": "primary",
        "ModelName": "my-existing-model",
        "InstanceType": "ml.g6.4xlarge",
        "InitialInstanceCount": 2
    }],
    MetricsConfig={"EnableDetailedObservability": True},
    ExecutionRoleArn="arn:aws:iam::123456789012:role/SageMakerExecutionRole"
)

# Step 2: Update endpoint
sm.update_endpoint(
    EndpointName="my-existing-endpoint",
    EndpointConfigName="my-existing-config-v2"
)

O console do SageMaker também disponibiliza um assistente guiado de três etapas para ativar a observabilidade detalhada: aprender sobre as métricas, ativar o enriquecimento OpenTelemetry (OTel) e selecionar quais endpoints incluir.

Enriquecimento OTel para métricas clássicas do CloudWatch

As métricas nativas OpenTelemetry fluem automaticamente para o CloudWatch após a ativação. Porém, as métricas clássicas já existentes (como Invocations, ModelLatency e OverheadLatency) precisam de enriquecimento OTel para aparecer no dashboard SageMaker Insights e serem consultáveis via PromQL. Essa configuração é feita uma única vez, no nível de conta e região, acessando o console do CloudWatch em Settings e ativando o enriquecimento de métricas OTel e as tags de recursos para telemetria.

Navegando pelo dashboard SageMaker Insights

O dashboard pode ser acessado tanto pelo console do SageMaker quanto pelo console do CloudWatch. Dentro do SageMaker, há três pontos de entrada com filtros pré-aplicados:

• Página de listagem de endpoints → “Open SageMaker Insights”: visão geral de toda a frota.
• Página de detalhes do endpoint → “View in SageMaker Insights”: filtrado para aquele endpoint específico.
• Aba de IC → link “Metrics” por IC: filtrado para o endpoint e o componente de inferência específico.

Aba Performance: saúde da frota e depuração de latência

A aba Performance é onde a maior parte das equipes passa o tempo. Ela responde perguntas como “Está tudo funcionando bem?” e “Se não, qual componente é o problema?”

A visualização em hexágonos coloridos mostra cada recurso da frota: verde indica estado OK, branco indica sem alarmes, e vermelho indica alarme ativo. Ao passar o cursor sobre um hexágono, são exibidos tipo de instância, TTFT, Tokens por Segundo (TPS) de saída, requisições concorrentes, utilização do cache KV e status de alarme no CloudWatch.

O painel Token streaming plota o TTFT e o ITL ao longo do tempo com alternância entre P50 e P99. O TTFT mede quanto tempo o usuário espera antes de ver o primeiro caractere da resposta; o ITL mede o tempo entre tokens consecutivos, impactando diretamente a fluidez do streaming.

Quando um pico de TTFT é identificado, o painel Latency breakdown ajuda a atribuir a causa: ele separa a latência total em Latência do Modelo (tempo de processamento pelo modelo) e Latência de Overhead (tempo de roteamento e agendamento pela plataforma). Se ambas estiverem normais mas o TTFT ainda estiver elevado, o motor de inferência pode estar enfileirando requisições internamente — por exemplo, aguardando slots no cache KV. O painel Engine and request pressure confirma esse diagnóstico.

O painel Traffic distribution mostra o fluxo de requisições por instância ou por componente de inferência com filtro por AZ. Se uma AZ apresenta zero tráfego enquanto as outras estão sobrecarregadas, isso indica um problema de roteamento ou posicionamento.

O painel Token throughput mede tokens processados por segundo, divididos por entrada/saída, percentis ou por instância. Se uma instância ml.g6.4xlarge entrega 150 tokens por segundo quando o benchmark do modelo indica 500, isso sinaliza restrição de recurso, problema de configuração ou pressão no cache KV.

Aba Capacity: planejamento e gestão de recursos

A aba Capacity responde perguntas como “Tenho recursos suficientes?”, “Onde há folga?” e “Consigo adicionar outro modelo?” A mesma visualização em hexágonos reaparece aqui, agora exibindo percentuais de utilização de GPU, memória de GPU, CPU, memória de CPU e disco no hover.

O painel Fleet utilization over time mostra tendências de consumo de recursos. Memória de GPU crescendo continuamente ao longo de dias indica que os limites de capacidade estão sendo atingidos; uma queda repentina indica que um modelo travou ou foi descarregado. Picos de disco recorrentes correlacionam com downloads de modelo durante cold starts.

Aba Reliability: alta disponibilidade e resiliência

A aba Reliability responde perguntas como “Se uma AZ cair, minha frota de inferência sobrevive?”, “Os eventos de scaling estão funcionando?” e “Por que os cold starts estão lentos?”

O gráfico de barras de Availability Zone distribution mostra a contagem de instâncias e cópias de IC por AZ. Distribuição uniforme entre 3 ou mais AZs representa baixo risco; concentração em 1-2 AZs representa risco médio; ausência de instâncias em qualquer AZ representa alto risco — uma falha de AZ pode tirar o endpoint do ar.

O painel Cold start anatomy exibe cada evento de provisionamento de IC como uma barra horizontal empilhada com quatro fases: download do modelo (azul), carga na GPU (roxo), inicialização do container (laranja) e overhead da plataforma (cinza). Esse painel indica qual fase otimizar para reduzir tempos de resposta ao escalonamento.

O painel ICE diagnostics rastreia erros de capacidade insuficiente (ICE — Insufficient Capacity Errors), que ocorrem quando o SageMaker não consegue provisionar as instâncias solicitadas. A tabela mostra quando a falha ocorreu, qual endpoint foi afetado, qual tipo de instância estava indisponível e qual AZ não tinha capacidade. Se todos os eventos ICE forem para um único tipo de instância em todas as AZs, isso indica esgotamento regional completo para aquele tipo — sinal para migrar para outros tipos de instância como fallback.

Conectando sua ferramenta de observabilidade existente

Para times que já utilizam Grafana ou outras ferramentas compatíveis com PromQL, é possível consultar as métricas do SageMaker Insights diretamente, sem precisar acessar o console do CloudWatch.

O processo envolve quatro etapas:

• Passo 1: Obter a URL do endpoint PromQL no console do SageMaker (Endpoints → selecione o endpoint → Connect to your observability tool).
• Passo 2: Configurar a fonte de dados no Grafana (Amazon Managed Grafana 2.4+ ou Grafana auto-hospedado com plugin Amazon Managed Service for Prometheus v3.0.0+), usando a URL obtida e autenticação SigV4 com uma role IAM que tenha permissões cloudwatch:GetMetricData e cloudwatch:ListMetrics.
• Passo 3: Importar o template de dashboard pré-construído disponível na mesma página “Connect to your observability tool” do console do SageMaker.
• Passo 4: Escrever queries PromQL customizadas conforme necessário. Exemplos:

# KV cache
vllm:kv_cache_usage_perc{"aws.sagemaker.endpoint.name"="ep-prsn-ic","aws.sagemaker.inference_component.name"="ic-qwen3-4b"}

# Active requests
vllm:num_requests_running{"aws.sagemaker.endpoint.name"="ep-prsn-ic","aws.sagemaker.inference_component.name"="ic-qwen3-4b"}

# TTFT P99
histogram_quantile(0.99, rate(vllm:time_to_first_token_seconds{"aws.sagemaker.endpoint.name"="ep-prsn-ic","aws.sagemaker.inference_component.name"="ic-qwen3-4b"}[5m]))

Para mais detalhes, consulte a documentação Conecte seu workspace Grafana pelo endpoint PromQL.

Preços

O SageMaker não cobra separadamente pela emissão das métricas detalhadas de observabilidade. As métricas são publicadas no Amazon CloudWatch no formato OpenTelemetry, e a precificação padrão de ingestão OpenTelemetry do CloudWatch se aplica: US$ 0,50 por GB ingerido. Se o enriquecimento de métricas vended OTel for ativado (necessário para visualizar métricas clássicas como Invocations e ModelLatency no dashboard Insights), as métricas enriquecidas também são cobradas a US$ 0,50 por GB. Para exemplos detalhados de precificação e uma calculadora de custos, consulte a seção OpenTelemetry Metrics na página de preços do Amazon CloudWatch.

Limpeza dos recursos

Para evitar cobranças contínuas após testes, exclua os recursos na seguinte ordem:

# Delete inference components first (if IC endpoint)
aws sagemaker delete-inference-component --inference-component-name my-ic

# Delete endpoints
aws sagemaker delete-endpoint --endpoint-name my-endpoint

# Wait for deletion, then delete configs
aws sagemaker delete-endpoint-config --endpoint-config-name my-config

Instâncias de GPU são cobradas por segundo enquanto os endpoints estão no estado InService. Exclua-os imediatamente após os testes.

Próximos passos

Com as novas métricas detalhadas e o dashboard SageMaker Insights, times de MLOps e engenharia de plataforma ganham visibilidade profunda sobre frotas de inferência de IA generativa — desde saúde da GPU até diagnósticos de cold start e distribuição de tráfego entre AZs. Para começar:

• Ative a observabilidade detalhada nos seus endpoints e verifique se os dados estão fluindo para o CloudWatch.
• Navegue pelo dashboard SageMaker Insights e explore as abas Performance, Capacity e Reliability.
• Conecte seu workspace Grafana pelo endpoint PromQL e importe o template de dashboard pré-construído.

Fonte

Monitor and debug generative AI inference with SageMaker detailed metrics and Insights dashboard on CloudWatch (https://aws.amazon.com/blogs/machine-learning/monitor-and-debug-generative-ai-inference-with-sagemaker-detailed-metrics-and-insights-dashboard-on-cloudwatch/)

O que é o Amazon Q e o que mudou

A AWS anunciou uma série de atualizações relevantes para o Amazon Q, o assistente de IA corporativo da empresa que se conecta aos aplicativos e fontes de dados mais usados pelas equipes, aprende como cada pessoa trabalha e age em seu nome. O foco das novidades é claro: devolver horas do dia para que profissionais possam se concentrar no que realmente importa, em vez de gastar energia com tarefas operacionais e repetitivas.

As três grandes adições desta atualização são: agentes autônomos que operam continuamente em segundo plano, um feed de atividades aprimorado para triagem inteligente do trabalho e a capacidade de consultar múltiplas fontes de dados com uma única pergunta em linguagem natural.

Agentes autônomos: produtividade mesmo quando você está em reuniões

Um dos anúncios mais relevantes é a possibilidade de criar agentes autônomos dentro do Amazon Q. Esses agentes executam tarefas de forma contínua, mesmo enquanto o usuário está em reuniões consecutivas ou indisponível.

A criação de um agente não exige nenhum conhecimento de programação. Basta descrever em linguagem natural o que você precisa, ou escolher entre uma biblioteca de agentes pré-configurados. O usuário define o nível de autonomia de cada agente: desde instruções detalhadas passo a passo até objetivos amplos, onde o próprio agente determina o caminho para atingir o resultado.

Cada agente opera dentro dos limites definidos pelo usuário. Alguns exemplos práticos mencionados pela AWS:

• Gestão de negociações: negócios parados são sinalizados, respostas de acompanhamento são redigidas e notas no CRM (Gerenciamento de Relacionamento com o Cliente) são atualizadas automaticamente.
• Monitoramento regulatório: quando uma mudança normativa ocorre durante a madrugada, um resumo de impacto já está na caixa de entrada pela manhã.
• Processamento de pedidos de compra: o agente cuida das ordens de compra de forma contínua, liberando a equipe para focar em negociações estratégicas.

O usuário pode acompanhar o progresso, fornecer informações adicionais e revisar os resultados diretamente no Amazon Q, sem perder o contexto. E quanto mais o agente é corrigido e orientado, mais eficiente ele se torna ao longo do tempo.

Feed de atividades: chega de triagem manual no começo do dia

Quem nunca chegou ao trabalho e passou a primeira hora tentando entender o que era urgente entre dezenas de e-mails não lidos, threads no Slack, conflitos de agenda e tarefas espalhadas por várias ferramentas? Esse problema é exatamente o que o feed de atividades do Amazon Q se propõe a resolver.

O feed consolida e-mail, mensagens, calendário e tarefas em uma única visão priorizada. Com o tempo, ele aprende quais mensagens o usuário costuma responder rapidamente, quais threads são ignoradas e quais tópicos são mais relevantes para a rotina de trabalho.

Nesta atualização, o feed ficou ainda mais inteligente. Seis mensagens de escalonamento, por exemplo, são agrupadas em um único cartão de resumo com respostas já redigidas para revisão. Pontos de pauta para reuniões aparecem antes mesmo de o usuário abrir o convite. Mensagens de lideranças são sinalizadas com prioridade. E tudo isso pode ser tratado diretamente no feed — responder, encaminhar, aprovar ou delegar — sem precisar alternar entre aplicativos.

16 novas integrações e um catálogo de capacidades prontas para uso

Tudo isso só funciona bem porque o Amazon Q se conecta a uma ampla variedade de ferramentas corporativas. A AWS anunciou o lançamento de 16 novas integrações com aplicativos e fontes de dados populares, incluindo conectores para Adobe, Cisco Webex Meetings and Video Messaging, Dun & Bradstreet, Figma, Google Chat, HG Insights, Microsoft OneNote, Moody’s, Shopify, Smartsheet, Snowflake, Visier, WhatsApp, Zapier e ZoomInfo.

A proposta é eliminar o chamado “jardim murado” — aquele modelo em que você fica preso ao ecossistema de um único fornecedor. Com o Amazon Q, é possível usar todas essas ferramentas de forma integrada, em um único lugar.

Além das integrações, a plataforma oferece um catálogo de capacidades com mais de 30 habilidades prontas para uso nas áreas de vendas, finanças e marketing. Entre elas: prospecção de leads, cobrança de faturas em atraso, criação de propostas comerciais, inteligência de mercado, previsão de folha de pagamento e configuração de fluxos de ausência temporária — tudo sem necessidade de código.

De uma pergunta a um painel interativo: consultas entre múltiplas fontes de dados

Outro avanço importante é a capacidade do Amazon Q de cruzar informações de diferentes sistemas com uma única pergunta em linguagem natural. Um exemplo citado pela AWS ilustra bem o problema que isso resolve:

Imagine que você precisa saber quais negociações empresariais na Europa têm índices de engajamento em queda. O histórico de negociações está no Salesforce, os dados de engajamento estão no Databricks e as metas regionais estão em uma planilha de planejamento. Antes, obter essa visão consolidada significava abrir um chamado, esperar por um analista ou juntar tudo manualmente.

Com o Amazon Q, basta fazer a pergunta. A plataforma conecta as três fontes em tempo real, respeitando os controles de acesso já existentes, e retorna a resposta com um painel interativo ou uma análise sintetizada que a equipe pode explorar imediatamente. O sistema ainda mostra o raciocínio utilizado para chegar ao resultado, permitindo que o usuário valide a resposta.

Também foi anunciado que aplicações criadas dentro do Amazon Q podem ser publicadas e compartilhadas com qualquer audiência — indo de uma ideia a uma aplicação web funcional em uma única conversa, sem código e sem necessidade de abrir um chamado para a área de TI. Esse recurso está disponível agora para usuários do plano Plus e em acesso antecipado para os planos Professional e Enterprise.

Segurança e conformidade sobre a infraestrutura AWS

Um ponto destacado pela AWS é que o Amazon Q roda sobre a mesma infraestrutura utilizada por organizações altamente sensíveis à segurança, como instituições financeiras e agências de inteligência. Isso significa que o serviço herda os mesmos mecanismos de proteção já aprovados pelas equipes de segurança corporativa:

• Gerenciamento de Identidade e Acesso (IAM — Identity and Access Management) da AWS
• Nuvem Privada Virtual (Amazon VPC — Virtual Private Cloud)
• Criptografia e certificações de conformidade padrão da AWS

Cada usuário vê apenas os dados que está autorizado a acessar, de forma automática. As equipes de segurança têm acesso a trilhas de auditoria completas, permissões por ação e controles administrativos — sem criar atrito para os usuários finais.

Como começar a usar

O Amazon Q está disponível para uso gratuito. É possível se cadastrar e começar em minutos diretamente na página do Amazon Q – Assistente de IA. A plataforma se conecta aos seus aplicativos, aprende suas prioridades e começa a agir em seu nome — agendando, fazendo follow-ups, redigindo, construindo e evoluindo a cada dia de uso.

Fonte

Get back hours every day with autonomous agents in Amazon Quick (https://aws.amazon.com/blogs/machine-learning/get-back-hours-every-day-with-autonomous-agents-in-amazon-quick/)

O problema real dos agentes de IA em produção

Os modelos que alimentam os agentes de Inteligência Artificial (IA) atuais são notavelmente capazes: conseguem raciocinar sobre problemas complexos, planejar fluxos de trabalho em múltiplas etapas e gerar respostas sofisticadas. Mas a maioria dos agentes opera bem abaixo desse potencial — e o gargalo não é inteligência. É acesso ao contexto certo e a mecanismos de feedback.

Pense nos exemplos práticos: um agente de atendimento ao cliente não consegue responder sobre a política de reembolso da empresa se não tiver acesso ao documento no SharePoint onde essa política está registrada. Um agente de pesquisa entrega uma visão incompleta de mercado se não puder acessar informações além dos dados com que foi treinado. Um agente de consultoria financeira retorna recomendações de segunda linha quando os dados de mercado em tempo real que ele precisa estão por trás de uma barreira de pagamento que ele não consegue atravessar. E, em todos esses cenários, as equipes raramente têm uma forma sistemática de saber se seus agentes estão melhorando ou piorando depois do deploy.

Foi para fechar essas lacunas que a AWS anunciou um conjunto de novas capacidades no Amazon Bedrock AgentCore, a plataforma para construir, conectar e otimizar agentes.

Agentes que sabem mais e alcançam mais

O AgentCore passa a oferecer acesso nativo a três camadas de conhecimento, cada uma ampliando o que os agentes conseguem acessar e realizar.

Camada de conhecimento organizacional: Bedrock Managed Knowledge Base

As informações mais valiosas de uma empresa estão espalhadas por SharePoint, Google Drive, Confluence, S3 e wikis internos. Tornar esse conteúdo acessível a agentes exigia, até então, construir pipelines de ingestão customizados, ajustar a recuperação de dados e manter a atualização ao longo do tempo — meses de engenharia antes que o agente conseguisse responder uma pergunta básica sobre o próprio negócio.

O Bedrock Managed Knowledge Base, agora disponível no AgentCore, substitui todo esse trabalho. A equipe conecta as fontes de dados não estruturados e o AgentCore cuida do restante: gerencia o armazenamento vetorial, os modelos de embeddings e re-ranking usados na recuperação, além das preocupações de escalabilidade como limites de taxa.

No centro dessa solução está um recuperador agêntico que vai muito além do Geração Aumentada por Recuperação (RAG) tradicional. Em vez de apenas associar uma consulta aos trechos mais próximos, ele planeja consultas entre múltiplas bases de conhecimento, conecta conceitos relacionados entre documentos, avalia resultados intermediários e faz re-ranking antes de responder. Para consultas complexas com múltiplas partes, essa abordagem entrega cobertura notavelmente mais ampla e completa do que a recuperação básica.

Camada de conhecimento global: Web Search no AgentCore

O conhecimento interno tem lacunas. Regulamentações mudam, mercados se movem, concorrentes lançam produtos constantemente. Para fazer o melhor trabalho possível, os agentes precisam entender o que acontece no mundo fora da organização — para pesquisa, verificação de fatos, atendimento ao cliente e inteligência de mercado.

A AWS está introduzindo o Web Search, uma nova ferramenta para desenvolvedores que constroem agentes de IA. Ela fornece informações da web mantendo os dados dentro do ambiente seguro da AWS do cliente. Construída sobre a mesma infraestrutura de busca da Amazon que alimenta o Alexa+, o Amazon Quick Suite e o Kiro, a ferramenta é otimizada para recuperação agêntica, retornando trechos de alto valor que entregam alta inteligência por token.

A abordagem combina informações públicas da web com o grafo de conhecimento proprietário da Amazon, que adiciona dados estruturados sobre entidades, fatos verificados e informações em tempo real como cotações de ações e resultados esportivos. Tudo isso permanece dentro do perímetro de segurança e conformidade da AWS, sem a necessidade de integrar um fornecedor externo adicional.

Camada de conhecimento pago: pagamentos no AgentCore e monetização de tráfego de IA no AWS WAF

As melhores informações nem sempre são gratuitas: feeds de mercado financeiro, pesquisas licenciadas, conjuntos de dados proprietários e APIs premium. Se o agente não consegue acessar recursos pagos, ele retorna uma resposta subótima — e o usuário nunca sabe o que foi perdido.

Acessar conteúdo pago exige duas partes: os agentes precisam de uma forma de pagar, e os provedores precisam de uma forma de receber. Os pagamentos do AgentCore, anunciados em preview no mês anterior, resolvem o lado do agente, permitindo que ele descubra serviços e conteúdos pagos, acesse-os e pague dentro do próprio loop de execução. Já a monetização de tráfego de IA no WAF, agora disponível para todos, resolve o lado do provedor, dando aos donos de conteúdo a capacidade de controlar o acesso de agentes: bloquear, permitir ou cobrar.

Como ambas as capacidades rodam na mesma plataforma, provedores que usam o Firewall de Aplicações Web (WAF) reconhecem automaticamente os agentes verificados no AgentCore. O resultado é um canal confiável: menos fricção para agentes verificados e compensação garantida para os provedores.

Agentes que aprendem com cada interação

Dar aos agentes melhor acesso ao conhecimento é apenas parte da equação. É preciso também saber se o agente está realmente atingindo seu objetivo — e identificar quando não está.

Isso é mais difícil do que parece. As falhas mais perigosas não são as que geram erros. São as que parecem normais nos dashboards: um agente que confirma uma modificação de pedido que nunca executou; outro que fabrica disponibilidade de produto quando uma API atinge timeout; um terceiro que pula uma etapa de aprovação enquanto os painéis mostram 99% de sucesso. Essas falhas não produzem sinais de erro — elas surgem através de reclamações de clientes semanas depois, frequentemente após milhares de sessões afetadas.

A AWS está anunciando novas capacidades de otimização no AgentCore que transformam rastros de produção em melhoria contínua.

Entender o que os agentes estão fazendo

Disponível em preview, o AgentCore passa a oferecer insights ricos sobre falhas, intenções e trajetórias em centenas de sessões, revelando padrões que nenhum dashboard ou revisão manual de rastros um a um conseguiria identificar.

• Insights de falha: descobrem padrões recorrentes de falha, incluindo as falhas comportamentais silenciosas que não produzem sinal de erro, explicam a causa raiz de cada uma em detalhes e as classificam por abrangência — para que a equipe saiba quais problemas estão afetando mais usuários e corrija primeiro os mais críticos.
• Insights de intenção: agrupam requisições pelo que os usuários estavam realmente tentando fazer, revelando o perfil real de uso do agente.
• Insights de trajetória: agrupam os caminhos que os agentes percorrem em uma tarefa, permitindo identificar padrões comuns e casos atípicos.

É possível ativar monitoramento contínuo com relatórios diários ou semanais, ou executar uma investigação pontual após um deploy ou um pico de reclamações — com resultados em minutos.

Corrigir com confiança

Uma vez identificado o que precisa mudar, recomendações e testes A/B — agora disponíveis para todos — ajudam a agir. As recomendações analisam rastros e saídas de avaliação para sugerir melhorias específicas nos prompts de sistema e nas descrições de ferramentas, com base no comportamento real do agente. A avaliação em lote testa essas recomendações contra o conjunto de dados de teste definido e reporta pontuações agregadas, detectando regressões antes que as mudanças cheguem à produção. O teste A/B executa uma comparação controlada entre versões do agente dividindo o tráfego real de produção, fornecendo evidências concretas de que uma mudança funciona sob condições reais antes do commit definitivo.

Tudo isso funciona independentemente de onde os agentes rodam: no runtime do AgentCore, no AWS Lambda, no Amazon Elastic Kubernetes Service (EKS) ou em ambientes fora da AWS.

Controles mais fortes à medida que os agentes ficam mais capazes

Agentes mais capazes significam mais superfície de exposição. E agentes introduzem um desafio de segurança que softwares tradicionais nunca tiveram: eles são probabilísticos. Agentes tomam decisões, e decisões podem ser influenciadas pelo contexto. O novo ponto de exposição não é a rede — é o contexto do agente, onde injeção de prompt e envenenamento de memória não exigem uma invasão, mas simplesmente convencer o agente a tomar uma decisão ruim.

A forma de proteger algo probabilístico é com algo determinístico: não como o cérebro, mas como guardrails ao redor dele. As capacidades de política no AgentCore já oferecem controles determinísticos em tempo real que definem o que um agente pode ou não fazer com ferramentas e dados no gateway. Agora, a AWS estende isso com a integração ao Bedrock Guardrails — disponível para todos —, que avalia cada ação do agente em busca de tentativas de injeção de prompt, conteúdo prejudicial e exposição de dados sensíveis. Essas verificações rodam na camada de gateway, fora do código do agente, onde o agente não consegue vê-las em seu contexto, não consegue raciocinar ao redor delas e não consegue se convencer de que não se aplicam.

Em breve, o AgentCore permitirá também alimentar sinais de detecção de provedores de segurança líderes — incluindo Check Point, Zscaler, Rubrik, Netskope e SentinelOne — nas mesmas políticas. O princípio se mantém independentemente da origem do sinal: a detecção pode ser probabilística, mas a aplicação da política é sempre determinística.

Do conceito a um agente funcional em minutos: AgentCore Harness disponível para todos

Um agente é mais do que um modelo. Se o modelo é o cérebro, o harness é o corpo: tudo o que o cérebro precisa para realizar trabalho. Ele executa o loop de orquestração, executa ferramentas, gerencia a janela de contexto, persiste estado entre turnos, se recupera de falhas e isola cada sessão.

O AgentCore harness, agora disponível para todos, entrega essa camada como uma capacidade gerenciada. Em vez de codificar o loop, a equipe define o agente em configuração: o modelo que usa, as ferramentas que chama, as habilidades que tem acesso, as instruções que segue. O AgentCore monta e executa esse loop automaticamente. A partir dessa definição única, é possível ter um agente funcional em minutos, rodando em seu próprio ambiente isolado, com sistema de arquivos, shell, memória entre sessões, habilidades e navegação na web.

Um diferencial importante é o desacoplamento entre harness e modelo: é possível escolher qualquer modelo e trocar entre eles durante a sessão sem tocar na lógica do agente. À medida que a fronteira avança e o melhor modelo para uma tarefa muda, a base do agente permanece estável. Quando for necessária orquestração customizada, é possível exportar o harness para código e continuar na mesma plataforma sem reconstruir nada.

O que está disponível agora

As seguintes capacidades estão disponíveis para todos no AgentCore: harness gerenciado, Bedrock Managed Knowledge Base, Web Search, integração com Guardrails, recomendações e testes A/B. Insights e pagamentos estão disponíveis em preview.

Para começar, acesse o console do AgentCore, use o AgentCore CLI ou consulte a documentação oficial para saber mais.

Fonte

New in Amazon Bedrock AgentCore: Build agents with broader knowledge and continuous learning (https://aws.amazon.com/blogs/machine-learning/new-in-amazon-bedrock-agentcore-build-agents-with-broader-knowledge-and-continuous-learning/)

O Problema Central: Agentes de IA Precisam de Contexto

Um agente de IA é tão inteligente quanto o contexto sobre o qual ele consegue raciocinar. E hoje, esse contexto está espalhado por data lakes, data warehouses, lakehouses, bancos de dados, streams — e ainda existe uma boa parte do conhecimento institucional que nunca foi sequer documentado.

Para confiar nas decisões de um agente de IA, é preciso primeiro garantir que ele tenha acesso ao contexto correto. Foi com essa premissa que, no AWS Summit New York City, a AWS anunciou uma série de inovações voltadas à chamada inteligência contextual — a capacidade de fornecer, de forma segura e governada, o contexto que os agentes precisam para entregar decisões confiáveis.

AWS Context: O Novo Serviço de Grafo de Conhecimento Organizacional

O principal anúncio foi o AWS Context (em breve disponível), um novo serviço que mapeia automaticamente os relacionamentos entre os dados existentes de uma organização em um grafo de conhecimento e disponibiliza uma busca agêntica para que os agentes de IA possam acessar, em tempo de execução, relacionamentos de dados governados, regras de negócio e conhecimento de domínio.

Na prática, administradores e curadores de dados gerenciam o grafo por meio de um console intuitivo: eles revisam relacionamentos inferidos pelo sistema, promovem esses relacionamentos para produção e associam conhecimento específico de domínio — como definições de negócio e regras de uso.

A Base Tecnológica: Amazon Quick

O AWS Context expande a mesma tecnologia de grafo de conhecimento que já sustenta o Amazon Quick, onde centenas de milhares de usuários interagem diariamente com um grafo de conhecimento em produção que cataloga conjuntos de dados, dashboards e metadados, aprendendo com padrões de uso para tornar cada interação mais inteligente. Esse grafo já processa milhões de requisições por dia.

Com o AWS Context, a AWS transforma o que antes era um grafo de conhecimento pessoal em um grafo organizacional — uma camada de contexto compartilhada e governada, da qual agentes e aplicações de toda a organização podem se beneficiar. Usuários existentes do Amazon Quick já ganham com isso imediatamente: quando o AWS Context é habilitado, os agentes do Quick passam a ter acesso ao grafo de conhecimento corporativo mais amplo, incluindo relacionamentos entre sistemas, regras de negócio e contexto curado que vão além do que qualquer grafo pessoal individual consegue oferecer.

Integrações e Abertura de Padrões

O serviço se integra ao AWS Glue Data Catalog, ao Amazon SageMaker Unified Studio e ao AWS Lake Formation, permitindo que equipes governem o grafo com regras de negócio e permissões, além de adicionar novo contexto automaticamente com assistência de IA ou por curadoria manual.

Elementos-chave da camada de contexto são publicados no Amazon S3 no formato Apache Iceberg, garantindo que os clientes possam usar as ferramentas compatíveis com Iceberg de sua preferência para consumir metadados e construir sobre o AWS Context com base em padrões abertos. Não há infraestrutura para provisionar nem pipeline de recuperação para construir — basta alguns cliques no Console de Gerenciamento da AWS para começar.

Capacidades de Destaque do AWS Context

Contexto que Aprende com o Uso dos Agentes

O AWS Context fica mais inteligente conforme os agentes o utilizam. À medida que os agentes consultam o grafo, o serviço observa quais fontes produzem resultados corretos, quais caminhos de junção os agentes seguem e quais regras curadas são aplicadas. Ele classifica as fontes com base no uso real e compartilha o que aprende por toda a organização — ou seja, quando um agente descobre um caminho de junção correto ou resolve uma ambiguidade de esquema, outros agentes se beneficiam disso automaticamente, sem que um humano precise recurar o grafo.

Aberto e Portável por Design

O AWS Context publica todos os metadados principais de fontes estruturadas e não estruturadas no formato Apache Iceberg no Amazon S3 Tables, permitindo consultas com Amazon Athena, Amazon Redshift, Apache Spark ou qualquer engine compatível com Iceberg. Também é possível construir sistemas downstream sobre esses dados, auditá-los ou migrá-los.

O serviço também foi projetado para se conectar a catálogos de terceiros, trazendo contexto de sistemas fora da AWS para o mesmo grafo. Os agentes consultam o grafo por meio de APIs de busca agêntica e ferramentas MCP — independentemente de serem construídos no Amazon Bedrock AgentCore, implantados no Amazon EKS ou executados em frameworks compatíveis com MCP.

Identidade e Governança por Padrão

Qualquer agente em produção levanta uma questão de governança: a quais dados ele tem acesso, e é possível mostrar exatamente o que ele acessou e sob qual autoridade? O AWS Context responde a ambas as perguntas tornando cada consulta ciente da identidade do chamador.

Cada chamada é projetada para herdar as permissões de IAM (Gerenciamento de Identidade e Acesso) e Lake Formation do usuário que a originou, de modo que um agente só pode ver e percorrer os relacionamentos que sua identidade está autorizada a acessar. Como o acesso passa pela identidade, cada interação é auditável — equipes de segurança e conformidade podem verificar o que um agente acessou e sob qual autoridade, usando os mesmos controles já existentes.

AWS Glue Data Catalog: Contexto de Negócio e Busca Semântica

Além do AWS Context, a AWS também anunciou a prévia de contexto de negócio e busca semântica para o AWS Glue Data Catalog, fornecendo ferramentas que facilitam a descoberta e compreensão de dados tanto para humanos quanto para agentes de IA.

Agora, os clientes podem enriquecer suas tabelas, views e colunas do Glue — incluindo aquelas baseadas em S3 Tables — com descrições de negócio, termos de glossário, metadados personalizados e associá-los a skill assets que fornecem contexto adicional armazenado fora do catálogo. Com o contexto de negócio indexado junto aos metadados técnicos no Glue Data Catalog, os clientes podem usar a nova API de Busca do Glue para encontrar dados por significado de negócio mais rapidamente, e os agentes de IA podem fundamentar seu raciocínio em definições confiáveis em vez de inferir contexto.

Skill Assets: Instruções Reutilizáveis para Agentes

A prévia também traz os chamados skill assets no Glue Data Catalog. Produtores de dados podem criar skill assets — um novo tipo de ativo que referencia URIs para arquivos (como skills de IA, arquivos markdown de guia e runbooks de equipe) hospedados em qualquer local, incluindo S3, repositórios git e wikis.

Associar skill assets a ativos de dados fornece aos agentes contexto e instruções adicionais que eles podem recuperar progressivamente para trabalhar com dados específicos, sem precisar re-ensinar cada agente individualmente em cada prompt. Por exemplo, as localizações de URI podem apontar para repositórios da equipe com documentação específica de domínio ou processos que incluem detalhes de uso de dados — como granularidade e escopo, padrões de consulta comuns e melhores práticas, e regras de uso.

Hoje, o AWS Agent Toolkit contém skills padrão para ajudar agentes de IA a trabalhar com o Glue Data Catalog, bem como outras capacidades como Amazon Athena e S3 Tables. Para começar, desenvolvedores podem conectar qualquer agente compatível com MCP usando o AWS MCP remoto e totalmente gerenciado, ou instalando o plugin aws-data-analytics para Claude Code, Cursor e Amazon Kiro. Agentes construídos com o AgentCore harness podem acessar todas as skills da AWS no AWS Agent Toolkit com apenas uma linha de código.

Amazon S3 Annotations: Contexto Rico Direto nos Objetos

Para facilitar que os clientes adicionem contexto personalizado ao seu data lake, a AWS anunciou a disponibilidade geral do Amazon S3 Annotations — uma nova forma de anexar contexto de negócio rico e consultável diretamente a objetos S3, armazenando esse contexto em uma tabela Iceberg do S3.

Embora tags de objeto e metadados definidos pelo usuário continuem sendo as ferramentas certas para tarefas operacionais como controle de acesso e pequenas informações definidas no momento do upload, os clientes que constroem agentes sobre seus dados precisam anexar muito mais metadados. Eles querem criar e evoluir contexto rico que um agente possa ler e sobre o qual possa agir, em escala. O S3 Annotations oferece essa capacidade em um formato de dados aberto.

Cada objeto armazenado no S3 pode ter até 1 GB de contexto. As anotações são mutáveis, portanto o contexto pode evoluir conforme os dados mudam. As anotações vivem junto ao objeto S3 no armazenamento S3 — o que significa que se movem com o objeto associado em operações de cópia e replicação, e são removidas quando o objeto é excluído. Não há banco de dados de metadados separado para construir, sincronizar ou manter atualizado.

As anotações se tornam consultáveis por meio do S3 Metadata. Quando as tabelas de anotações são habilitadas em um bucket, cada anotação flui automaticamente para uma tabela Iceberg totalmente gerenciada. É possível consultar todos os objetos com Amazon Athena, Amazon Redshift ou qualquer engine compatível com Iceberg, e os agentes podem descobrir anotações em linguagem natural por meio do servidor MCP do S3 Tables.

Com o Amazon S3 Annotations, os clientes anexam contexto de negócio rico diretamente a objetos S3 e o consultam em escala, para que os agentes encontrem o que precisam sem precisar construir sistemas de metadados separados.

Contexto é a Base dos Agentes de IA

A visão que a AWS apresentou no Summit de Nova York é clara: o contexto é o data lake para os agentes de IA. Com essas inovações — AWS Context, as melhorias no Glue Data Catalog e o S3 Annotations em disponibilidade geral — a empresa busca construir a fundação de conhecimento e inteligência para que agentes de IA interajam com dados em organizações e empresas de qualquer escala, de forma governada, portável e confiável.

Fonte

Context intelligence for your data and AI agents at scale (https://aws.amazon.com/blogs/machine-learning/context-intelligence-for-your-data-and-ai-agents-at-scale/)