Author: Make.com Service User

Feedback imediato antes de provisionar qualquer recurso

A AWS CloudFormation acaba de receber uma melhoria significativa no fluxo de desenvolvimento: a validação pré-implantação agora roda automaticamente nas operações de Create Stack e Update Stack, sem nenhuma configuração adicional necessária.

Na prática, isso significa que erros comuns de implantação são detectados em segundos — antes que qualquer recurso comece a ser criado. Antes dessa mudança, quando algo dava errado, o time precisava aguardar o ciclo completo de provisionamento e rollback para descobrir uma falha que poderia ter sido evitada muito mais cedo.

O que mudou em relação ao comportamento anterior

Anteriormente, a validação pré-implantação estava disponível apenas durante a criação de change sets, cobrindo erros de sintaxe em propriedades, conflitos de nomes de recursos e restrições de bucket S3 vazio. Com esse lançamento, as mesmas verificações passam a rodar automaticamente nas operações de Create Stack e Update Stack — acelerando o ciclo de desenvolvimento em qualquer fluxo de trabalho, seja iteração manual, pipelines de Integração Contínua/Entrega Contínua (CI/CD) ou agentes de IA provisionando infraestrutura.

Três novas verificações de aviso no change set

Além da expansão da validação automática, a AWS também introduziu três novas verificações de aviso disponíveis durante a criação de change sets:

• Validação de limites de cotas de serviço: avisa quando a criação de recursos ultrapassaria as cotas da conta.
• Detecção de conflito no AWS Config Recorder: avisa quando o template adiciona regras do Config em uma conta sem gravação habilitada, ou define um Config Recorder em uma conta onde já existe um ativo.
• Verificação de prontidão para exclusão de repositório ECR: avisa quando um repositório do Elastic Container Registry (ECR) marcado para exclusão ainda contém imagens.

Como visualizar os erros de validação

Quando a validação detecta um problema, é possível visualizar os erros de duas formas:

• Via API DescribeEvents, informando o ID da operação.
• No console do CloudFormation, acessando a aba Events da stack e clicando no ID da operação para abrir diretamente a aba Deployment validations.

Cada erro retornado inclui o ID lógico do recurso e o caminho da propriedade, facilitando a identificação exata do ponto a corrigir antes de qualquer provisionamento.

Integração com o CDK

No Kit de Desenvolvimento em Nuvem (CDK), tanto o comando cdk deploy quanto o cdk validate exibem os resultados da validação com rastreamento no nível de construct em um relatório unificado. Isso permite que agentes de IA e ferramentas de automação façam o parse de respostas estruturadas e se autocorrijam imediatamente.

Como desabilitar a validação quando necessário

A validação pré-implantação vem habilitada por padrão em todas as operações de stack. Caso seja necessário desativá-la em uma operação específica, basta usar o novo parâmetro DisableValidation nas chamadas de API CreateStack, UpdateStack e CreateChangeSet, ou a flag --disable-validation na Interface de Linha de Comando (CLI).

O recurso está disponível em todas as regiões AWS onde o CloudFormation é suportado, com exceção da China. Consulte a tabela de regiões da AWS para verificar a disponibilidade. Para mais detalhes técnicos, acesse o guia do usuário sobre validação de implantações de stack.

Fonte

AWS CloudFormation and CDK accelerate development feedback loops with pre-deployment validation on all stack operations (https://aws.amazon.com/about-aws/whats-new/2026/06/aws-cloudformation/)

Quando conversar não é suficiente

Agentes de IA já dominam a arte de conversar. Mas e quando a tarefa exige mais do que texto? Renderizar um gráfico diretamente no chat, manter um painel de tarefas sincronizado em tempo real ou pausar a execução para aguardar aprovação do usuário — essas interações pedem um padrão de comunicação mais robusto entre o backend do agente e o frontend.

É aí que entra o AG-UI (Agent-User Interaction Protocol), um protocolo aberto que define exatamente esse padrão. Ele funciona com múltiplos frameworks de agentes — Strands Agents, LangGraph, CrewAI — e com as principais bibliotecas de frontend como React, Angular e Vue. A grande vantagem: o código do agente e o código da interface ficam completamente desacoplados, permitindo escolher o melhor de cada mundo sem amarrações.

A AWS publicou um guia detalhado mostrando como o AG-UI se integra ao Fullstack AgentCore Solution Template (FAST) e como o CopilotKit expande essas capacidades com interfaces generativas, estado compartilhado e fluxos human-in-the-loop — tudo rodando no Amazon Bedrock AgentCore.

Como a solução está estruturada

O Amazon Bedrock AgentCore Runtime é um ambiente serverless, seguro e dedicado para hospedar agentes de IA e ferramentas. Ele suporta três protocolos principais: o MCP (Model Context Protocol) conecta agentes a ferramentas, o A2A (Agent2Agent) conecta agentes entre si, e o AG-UI conecta agentes aos usuários.

Quando um container de agente é implantado com a flag do protocolo AG-UI, o AgentCore funciona como um proxy transparente: cuida da autenticação (SigV4 ou OAuth 2.0 via Amazon Cognito), do isolamento de sessão, da escalabilidade e da observabilidade. O container precisa expor POST /invocations para requisições AG-UI e GET /ping para verificações de saúde na porta 8080. Para mais detalhes sobre esse processo, a AWS disponibiliza a documentação de como implantar servidores AG-UI no AgentCore Runtime.

O FAST é um projeto inicial pronto para implantação que conecta AgentCore Runtime, Gateway, Identity, Memory e Code Interpreter com um frontend React e autenticação via Amazon Cognito — tudo definido com AWS CDK. A versão v0.4.1 adicionou dois padrões AG-UI (agui-strands-agent e agui-langgraph-agent) que compartilham um único parser de frontend. Para um guia completo da arquitetura e implantação do FAST, vale conferir o post Accelerate agentic application development with a full-stack starter template for Amazon Bedrock AgentCore.

A solução apresentada tem duas camadas independentes. A primeira é o AG-UI integrado ao FAST, com dois padrões de agente e um parser único de frontend que os trata de forma transparente — o frontend não precisa saber qual framework está rodando no backend. A segunda é a amostra CopilotKit + FAST, que substitui a interface de chat nativa pelo CopilotKit, adicionando interface generativa com componentes inline, estado compartilhado bidirecional e interações human-in-the-loop.

AG-UI no FAST: um parser, dois frameworks

Padrão agui-strands-agent

O padrão agui-strands-agent envolve um Strands Agent no StrandsAgent da biblioteca ag-ui-strands. O wrapper traduz automaticamente os eventos de streaming do Strands em Server-Sent Events (SSE) do AG-UI. Cada requisição cria um agente novo com as ferramentas MCP do Gateway. O AgentCore Memory é associado por thread por meio de um provedor de gerenciador de sessão, de forma que o histórico da conversa persiste mesmo durante o escalonamento. A memória é opcional: o provedor retorna None quando MEMORY_ID não está definido:

# patterns/agui-strands-agent/agent.py
from ag_ui_strands import StrandsAgent, StrandsAgentConfig
from bedrock_agentcore.runtime import BedrockAgentCoreApp, RequestContext
from strands import Agent

app = BedrockAgentCoreApp()

# Build the model and Code Interpreter once at module load
MODEL = BedrockModel(model_id="us.anthropic.claude-sonnet-4-5-20250929-v1:0")
CODE_INTERPRETER = StrandsCodeInterpreterTools(REGION).execute_python_securely

@app.entrypoint
async def invocations(payload: dict, context: RequestContext):
    input_data = RunAgentInput.model_validate(payload)
    actor_id = extract_user_id_from_context(context)

    # Fresh agent per request --- picks up the caller's identity and tools
    agent = Agent(
        model=MODEL,
        system_prompt=SYSTEM_PROMPT,
        tools=[create_gateway_mcp_client(actor_id), CODE_INTERPRETER],
        session_manager=get_memory_session_manager(actor_id, session_id),
    )

    agui_agent = StrandsAgent(
        agent=agent,
        name="agui_strands_agent",
        config=StrandsAgentConfig(
            session_manager_provider=make_memory_provider(actor_id),
            replay_history_into_strands=False,
        ),
    )

    async for event in agui_agent.run(input_data):
        yield event.model_dump(mode="json", by_alias=True, exclude_none=True)

O BedrockAgentCoreApp lê os cabeçalhos do AgentCore Runtime (WorkloadAccessToken, Authorization, Session-Id) e popula variáveis de contexto, de forma que a autenticação do Gateway e o Memory funcionam da mesma forma que os padrões HTTP.

Padrão agui-langgraph-agent

Já o padrão agui-langgraph-agent usa o LangGraphAGUIAgent da biblioteca copilotkit. O grafo compilado é construído a cada requisição, garantindo que cada invocação receba as ferramentas MCP com escopo do chamador. O AgentCore Memory também é opcional aqui — o helper retorna None quando MEMORY_ID não está definido, permitindo executar o padrão sem provisionar Memory:

# patterns/agui-langgraph-agent/agent.py
from copilotkit import CopilotKitMiddleware, LangGraphAGUIAgent

async def build_graph(actor_id: str):
    """Build a fresh LangGraph compiled graph with Gateway tools."""
    mcp_client = await create_gateway_mcp_client(actor_id)
    tools = await mcp_client.get_tools()
    tools.append(CODE_INTERPRETER)
    return create_agent(
        model=MODEL,
        tools=tools,
        checkpointer=get_memory_saver(),  # None when MEMORY_ID is unset
        middleware=[CopilotKitMiddleware()],
        system_prompt=SYSTEM_PROMPT,
    )

@app.entrypoint
async def invocations(payload: dict, context: RequestContext):
    input_data = RunAgentInput.model_validate(payload)
    actor_id = extract_user_id_from_context(context)
    graph = await build_graph(actor_id)

    agui_agent = LangGraphAGUIAgent(
        name="agui_langgraph_agent",
        graph=graph,
        config={"configurable": {"actor_id": actor_id}},
    )

    async for event in agui_agent.run(input_data):
        yield event.model_dump(mode="json", by_alias=True, exclude_none=True)

Um único parser para ambos os frameworks

Os dois padrões produzem os mesmos eventos AG-UI — um fluxo de eventos tipados sobre SSE. Por exemplo, uma única chamada de ferramenta gera esta sequência:

data: {"type": "RUN_STARTED", "threadId": "t1", "runId": "r1"}
data: {"type": "TEXT_MESSAGE_START", "messageId": "m1", "role": "assistant"}
data: {"type": "TEXT_MESSAGE_CONTENT", "messageId": "m1", "delta": "Let me check "}
data: {"type": "TEXT_MESSAGE_CONTENT", "messageId": "m1", "delta": "that for you."}
data: {"type": "TEXT_MESSAGE_END", "messageId": "m1"}
data: {"type": "TOOL_CALL_START", "toolCallId": "tc1", "toolCallName": "get_weather"}
data: {"type": "TOOL_CALL_ARGS", "toolCallId": "tc1", "delta": "{\"location\": \"Seattle\"}"}
data: {"type": "TOOL_CALL_END", "toolCallId": "tc1"}
data: {"type": "TOOL_CALL_RESULT", "toolCallId": "tc1", "content": "{\"temp\": 55}"}
data: {"type": "RUN_FINISHED", "threadId": "t1", "runId": "r1"}

O parser de frontend mapeia cada evento para uma ação correspondente:

// frontend/src/lib/agentcore-client/parsers/agui.ts
export const parseAguiChunk: ChunkParser = (line, callback) => {
  if (!line.startsWith("data: ")) return;
  const json = JSON.parse(line.substring(6).trim());
  switch (json.type) {
    case "TEXT_MESSAGE_CONTENT":
      callback({ type: "text", content: json.delta ?? "" });
      break;
    case "TOOL_CALL_START":
      callback({ type: "tool_use_start", toolUseId: json.toolCallId, name: json.toolCallName });
      break;
    case "TOOL_CALL_RESULT":
      callback({ type: "tool_result", toolUseId: json.toolCallId, result: json.content ?? "" });
      break;
    case "RUN_FINISHED":
      callback({ type: "result", stopReason: "end_turn" });
  }
};

Diferente dos padrões HTTP — onde Strands, LangGraph e Claude Agent SDK exigem parsers separados para seus diferentes formatos de streaming — o AG-UI abstrai o framework do backend. Trocar agui-strands-agent por agui-langgraph-agent na configuração não exige nenhuma mudança no frontend.

Para implantar, basta definir o padrão em infra-cdk/config.yaml e executar o CDK:

backend:
  pattern: agui-strands-agent  # or agui-langgraph-agent
  deployment_type: docker

cd infra-cdk
cdk deploy --require-approval never
python3 ../scripts/deploy-frontend.py

CopilotKit + FAST: indo além do chat

O frontend base do FAST oferece uma interface de chat funcional, mas o AG-UI suporta interações muito mais ricas. O CopilotKit é uma biblioteca React construída especificamente para esses padrões avançados. A equipe do CopilotKit desenvolveu uma aplicação de exemplo sobre o FAST que demonstra essas capacidades no AgentCore, com suporte tanto para LangGraph quanto para Strands — a escolha é feita no momento da implantação.

Interface generativa: componentes React renderizados pelo agente

Com o CopilotKit, o agente consegue renderizar componentes React customizados diretamente no chat, não apenas texto. O frontend registra componentes que o agente pode invocar por meio de eventos de chamada de ferramenta do AG-UI:

// Register a pie chart the agent can render
useComponent({
  name: "pieChart",
  description: "Displays data as a pie chart.",
  parameters: PieChartPropsSchema,
  render: PieChart,
});

Quando o agente chama a ferramenta pieChart, o CopilotKit intercepta os eventos TOOL_CALL_START e TOOL_CALL_ARGS e renderiza o componente PieChart diretamente na conversa. O agente primeiro chama uma ferramenta query_data para buscar dados de um arquivo CSV de exemplo e então passa os resultados para o componente de gráfico.

Estado compartilhado: canvas de tarefas sincronizado em tempo real

A amostra inclui um canvas de tarefas com sincronização bidirecional entre o agente e a interface. Ao pedir ao agente “Adicione três tarefas: design da API, escrever testes e implantar em staging”, ele chama manage_todos e o canvas é atualizado em tempo real via eventos STATE_SNAPSHOT do AG-UI. Edições feitas diretamente na interface também são visíveis para o agente na próxima invocação, porque o padrão Strands injeta as tarefas atuais no prompt do sistema:

def state_context_builder(state: dict) -> str:
    todos = state.get("todos", [])
    if todos:
        return f"\nCurrent todos:\n{json.dumps(todos, indent=2)}"
    return ""

Human-in-the-loop: o agente pausa e aguarda sua decisão

A amostra demonstra um agendador de reuniões onde o agente pausa no meio da execução e renderiza um seletor de horário. O usuário escolhe um horário e o agente retoma com essa informação:

useHumanInTheLoop({
  name: "scheduleTime",
  description: "Schedule a meeting with the user.",
  parameters: z.object({
    reasonForScheduling: z.string(),
    meetingDuration: z.number(),
  }),
  render: ({ respond, status, args }) => (
    <MeetingTimePicker status={status} respond={respond} {...args} />
  ),
});

O mecanismo usa o fluxo de chamada de ferramenta do AG-UI: o agente emite TOOL_CALL_START para scheduleTime, o CopilotKit renderiza o seletor no lugar de executar uma ferramenta no backend, e a resposta do usuário volta como um TOOL_CALL_RESULT.

Pré-requisitos e como implantar

Para seguir o guia, você vai precisar de:

• Uma conta AWS com permissões para AWS CloudFormation, Amazon ECR, Amazon Bedrock AgentCore, Amazon Cognito e AWS Amplify.
• AWS CLI v2 instalada e configurada.
• AWS CDK instalado.
• Node.js 18 ou superior e Python 3.11 ou superior.
• Docker em execução, para builds de container.
• Acesso ao modelo habilitado no console do Amazon Bedrock para o modelo utilizado pelo agente.

Para implantar a amostra CopilotKit, clone o repositório de amostras FAST e execute:

git clone https://github.com/aws-samples/sample-FAST-applications.git
cd sample-FAST-applications/samples/copilotkit-generative-ui
cp config.yaml.example config.yaml
# Edit config.yaml --- set stack_name_base and admin_user_email
./deploy-langgraph.sh  # or ./deploy-strands.sh

O script provisiona toda a stack: pool de usuários do Amazon Cognito, repositório do Amazon ECR, AgentCore Runtime, AgentCore Gateway, AgentCore Memory, a Lambda do CopilotKit Runtime com Amazon API Gateway e hospedagem no AWS Amplify. Ao final, basta abrir a URL do Amplify exibida no terminal e fazer login para verificar a implantação.

Limpando os recursos

A solução implanta dois stacks separados. Para evitar cobranças contínuas, remova o que foi implantado.

Para remover a implantação FAST:

cd infra-cdk
npx cdk destroy --all

Para remover a amostra CopilotKit:

cd sample-FAST-applications/samples/copilotkit-generative-ui
npx cdk destroy --all

Se um repositório do Amazon ECR ainda contiver imagens de container, exclua-o manualmente — algumas configurações do CDK mantêm repositórios no lugar após o destroy.

Conclusão

A integração do AG-UI ao FAST permite alternar entre os backends Strands e LangGraph sem tocar no código do frontend. A amostra CopilotKit vai além, adicionando interface generativa, estado compartilhado e interações human-in-the-loop — tudo rodando no AgentCore com autenticação gerenciada, escalabilidade e memória.

Para explorar mais, os recursos disponíveis incluem o repositório FAST (para implantar um padrão AG-UI com agui-strands-agent ou agui-langgraph-agent), a amostra CopilotKit Generative UI (para experimentar interface generativa, estado compartilhado e human-in-the-loop no AgentCore), a documentação AG-UI do AgentCore (contrato completo do protocolo e detalhes de implantação), a especificação do protocolo AG-UI (tipos de eventos e design do protocolo) e a documentação do CopilotKit (guia de integração de frontend para interface generativa). Dúvidas e feedback podem ser registrados como issues no repositório FAST ou no repositório FAST Samples.

Fonte

Build generative UI for AI agents on Amazon Bedrock AgentCore with the AG-UI protocol (https://aws.amazon.com/blogs/machine-learning/build-generative-ui-for-ai-agents-on-amazon-bedrock-agentcore-with-the-ag-ui-protocol/)

O problema de gerenciar acesso a modelos de IA em múltiplas contas

Quem trabalha com AWS em ambientes corporativos sabe que a estrutura multi-conta é quase inevitável. Times diferentes, ambientes separados, projetos isolados — tudo isso resulta em dezenas ou centenas de contas AWS. E quando o assunto é adoção de modelos de Inteligência Artificial (IA) de terceiros no Amazon Bedrock, esse cenário cria um dilema operacional bastante concreto.

O nó da questão está nos modelos distribuídos via AWS Marketplace — como os da Anthropic (Claude), Cohere e Stability AI. Diferente dos modelos próprios da Amazon ou dos vendidos pela Amazon (como Meta Llama, Mistral e DeepSeek), que já estão disponíveis imediatamente com as permissões padrão do Bedrock, os modelos de marketplace exigem uma assinatura ativa em cada conta antes de poderem ser invocados. Isso significa que cada conta precisa ter permissões do AWS Marketplace — o que, em escala, gera dois caminhos igualmente problemáticos: ou você distribui essas permissões amplamente, abrindo brechas de governança, ou alguém precisa ativar os modelos manualmente em cada conta, o que é inviável.

Para resolver exatamente esse problema, a AWS anunciou os entitlements gerenciados para o Amazon Bedrock. A proposta é simples e poderosa: assine o modelo uma única vez a partir de uma conta central e distribua o acesso para toda a organização usando o AWS License Manager — sem precisar conceder permissões do AWS Marketplace nas contas de carga de trabalho.

Entendendo as categorias de modelos no Bedrock

Antes de entrar no funcionamento dos entitlements gerenciados, é importante entender como os modelos são classificados no Amazon Bedrock, porque isso define diretamente quando essa solução é necessária.

Existem três categorias principais:

• Modelos Amazon: como o Amazon Nova. Ficam disponíveis imediatamente com as permissões padrão do Bedrock, sem nenhuma configuração adicional.
• Modelos vendidos pela Amazon: como Meta Llama, Mistral e DeepSeek. Também estão disponíveis imediatamente graças ao acesso simplificado introduzido recentemente pela AWS.
• Modelos do AWS Marketplace: como Anthropic Claude, Cohere, AI21 Labs e Stability AI. Esses exigem uma assinatura ativa em cada conta antes de qualquer invocação — e é aqui que os entitlements gerenciados entram em cena.

Resumindo: se a sua organização usa apenas modelos da Amazon ou vendidos pela Amazon, provavelmente você não precisa dessa solução. Mas se usa modelos de terceiros via Marketplace em múltiplas contas, os entitlements gerenciados foram feitos para o seu cenário.

Quando usar entitlements gerenciados?

A AWS indica que essa funcionalidade foi projetada para organizações que se encaixam em um ou mais dos seguintes perfis:

• Executam cargas de trabalho distribuídas em múltiplas contas AWS;
• Querem evitar conceder permissões do AWS Marketplace nas contas de carga de trabalho;
• Negociaram preços diferenciados (private offers) com provedores de modelos e precisam garantir que todas as contas usem essa tarifa;
• Precisam de visibilidade centralizada sobre quais contas têm acesso a quais modelos.

Por outro lado, você provavelmente não precisa dos entitlements gerenciados se opera em uma única conta AWS, se cada time já gerencia suas próprias assinaturas de Marketplace de forma independente, ou se só utiliza modelos Amazon e de parceiros sem necessidade de assinatura.

Pré-requisitos antes de começar

Antes de implementar os entitlements gerenciados, a AWS lista alguns requisitos que precisam estar em ordem:

• AWS Organizations com todos os recursos habilitados: a funcionalidade exige que o AWS Organizations esteja configurado com todos os recursos ativados.
• Acesso à conta de gerenciamento: você precisará de permissões tanto para o AWS Marketplace quanto para o AWS License Manager a partir da conta de gerenciamento.
• Contas-membro: as contas para as quais você deseja distribuir o acesso aos modelos.
• Funções vinculadas a serviços (SLRs — Service-Linked Roles): são funções do Gerenciamento de Identidade e Acesso da AWS (IAM — AWS Identity and Access Management) vinculadas diretamente a serviços específicos. Para os entitlements gerenciados, é necessário criar SLRs tanto para o AWS License Manager quanto para o AWS Marketplace. Essas funções incluem todas as permissões que os serviços precisam para chamar outros serviços da AWS em seu nome.

Como funciona: o fluxo de quatro etapas

A lógica central é baseada em dois conceitos do AWS License Manager: licenças e concessões (grants). Pense na licença como o direito da sua organização de usar um determinado modelo. As concessões são o mecanismo para compartilhar esse direito com contas específicas. Uma única licença pode ter múltiplas concessões, permitindo distribuir o acesso para muitas contas a partir de uma única assinatura.

O fluxo de implementação dos entitlements gerenciados tem quatro etapas principais:

1. Assinar o modelo

A partir da conta de gerenciamento, você assina o modelo de terceiros desejado pelo AWS Marketplace — seja pelo console do Marketplace ou aceitando uma oferta privada (private offer). É nesse momento que a assinatura é criada.

2. Verificar a criação da licença

Após a assinatura, o AWS License Manager cria automaticamente uma licença. Essa licença representa o direito da organização de usar o modelo e serve como base para a distribuição às outras contas.

3. Criar as concessões (grants)

Usando o AWS License Manager, você cria concessões para compartilhar a licença com contas-membro específicas dentro do AWS Organizations. Você tem controle total sobre quais contas recebem acesso a cada modelo.

4. Ativar e usar

As contas-membro recebem notificação das concessões. Após ativarem a concessão, podem imediatamente começar a invocar o modelo — sem precisar de permissões do AWS Marketplace ou de assinaturas adicionais.

Vale um detalhe importante: uma conta-membro ainda consegue invocar um modelo sem ter ativado uma concessão ou assinado uma oferta privada, mas nesse caso será cobrada pelo preço público padrão.

Cenários práticos de uso

Habilitando um modelo para toda a organização

Imagine que 50 contas de carga de trabalho precisam acessar um novo modelo da Anthropic Claude. Sem os entitlements gerenciados, você teria que conceder permissões de aws-marketplace:Subscribe em cada conta ou ativar os modelos manualmente uma a uma. Com a nova abordagem, basta assinar a oferta privada na conta de gerenciamento, deixar o License Manager criar a licença automaticamente e distribuir concessões para as 50 contas — individualmente, por unidade organizacional (OU — Organizational Unit) ou para toda a organização. O resultado: assinatura central, acesso distribuído, sem permissões de Marketplace nas contas de trabalho.

Rollout faseado de um novo modelo

Quer fazer um piloto com um modelo novo antes de liberar para toda a organização? Assine na conta de gerenciamento, crie concessões apenas para as contas do piloto e, conforme os resultados forem positivos, expanda as concessões gradualmente. O AWS License Manager oferece visibilidade sobre o status das concessões em toda a organização, criando um rastro de auditoria claro sobre quais contas têm acesso e quando ativaram.

Distribuição de ofertas privadas (private offers)

Negociou preços personalizados com um provedor de modelos via AWS Marketplace? Peça ao provedor para estender a oferta privada para a conta de gerenciamento, aceite-a por lá e distribua o acesso via concessões. Assim, o uso de todas as contas-membro flui pelo seu acordo negociado, garantindo tarifas consistentes em toda a organização e simplificando a alocação de custos.

Implantação imediata para toda a organização

Se a organização padronizou em um modelo específico e quer que todas as contas tenham acesso de imediato, basta assinar na conta de gerenciamento e distribuir a concessão para toda a organização em uma única etapa — em vez de selecionar contas individualmente. As contas-membro recebem automaticamente a concessão. Em organizações com todos os recursos habilitados, a organização aceita as concessões automaticamente, mas elas aparecem no estado Desabilitado até que o administrador da conta as ative explicitamente. Isso garante um ponto de controle final antes do uso efetivo. Novas contas adicionadas à organização herdam o acesso automaticamente, sem necessidade de criar novas concessões.

Pontos de atenção antes de implementar

Alocação de custos

Os custos de uso dos modelos são cobrados na conta de gerenciamento que detém a assinatura. Para rastrear o consumo por conta-membro ou por time, a recomendação é usar as AWS Cost Allocation Tags (etiquetas de alocação de custos).

Ofertas privadas

O fluxo com ofertas privadas negociadas via AWS Marketplace segue exatamente o mesmo processo: aceite a oferta na conta de gerenciamento, a licença é criada automaticamente e você distribui o acesso via concessões. Os termos da oferta privada — que podem incluir preços customizados, condições de pagamento e acordos de suporte adicionais — se aplicam ao uso de toda a organização, independentemente de qual conta-membro faz a invocação. A recomendação é revisar cuidadosamente os termos antes de aceitar e distribuir o acesso.

Assinaturas existentes

Se uma conta-membro já tem uma assinatura ativa de um modelo e a conta pagadora distribui uma concessão para o mesmo modelo, o entitlement da primeira assinatura é desabilitado e a conta passa a usar a nova concessão distribuída.

Comportamento regional

Embora os modelos possam ser invocados nas regiões AWS suportadas, o AWS License Manager cria as licenças na região us-east-1. A criação e ativação de concessões também ocorrem pelo endpoint us-east-1 do License Manager, mesmo que as cargas de trabalho estejam em outras regiões.

Limpeza de recursos

Se a assinatura de um modelo não for mais necessária, o processo correto é: primeiro, excluir as concessões das contas-membro no AWS License Manager; depois, cancelar a assinatura do AWS Marketplace na conta de gerenciamento. Um ponto importante: cancelar a assinatura não remove automaticamente as concessões — elas precisam ser excluídas separadamente para revogar os preços privados.

Conclusão

Os entitlements gerenciados para o Amazon Bedrock representam uma evolução significativa na forma como organizações gerenciam o acesso a modelos de terceiros em escala. A solução elimina o dilema entre abrir permissões amplas de Marketplace ou operar com processos manuais inviáveis, centralizando a governança sem abrir mão da flexibilidade de distribuição.

Para quem quiser explorar a funcionalidade, a AWS sugere começar identificando quais modelos de terceiros a organização já utiliza, revisando a abordagem atual de assinaturas entre contas, implementando os entitlements gerenciados para um modelo piloto e expandindo gradualmente. Também é possível combinar essa funcionalidade com o AWS Service Catalog para criar fluxos de autoatendimento de acesso a modelos para os times.

Para aprofundar, a AWS disponibiliza a documentação de entitlements gerenciados no Amazon Bedrock, a referência de acesso a modelos no Amazon Bedrock e um post detalhado sobre o acesso simplificado ao Amazon Bedrock no AWS Security Blog.

Fonte

Simplify multi-account access to Amazon Bedrock models with managed entitlements (https://aws.amazon.com/blogs/machine-learning/simplify-multi-account-access-to-amazon-bedrock-models-with-managed-entitlements/)

Por que resiliência em inferência LLM virou prioridade de produção

Implementar padrões de resiliência para inferência de modelos de linguagem de grande escala (LLM) deixou de ser opcional. Com aplicações de IA generativa saindo dos laboratórios e chegando a ambientes produtivos, as equipes precisam garantir que a inferência permaneça disponível, responsiva e economicamente viável mesmo sob pressão.

Boas práticas clássicas — como estabilidade estática, backoffs e retentativas — ainda se aplicam. Mas a IA generativa traz novos desafios: disponibilidade de modelos específicos, cotas que mudam rapidamente, limites de tokens em múltiplos provedores e consistência com modelos recém-lançados.

O Amazon Bedrock oferece modelos de fundação totalmente gerenciados com recursos nativos de resiliência, como inferência entre regiões. Quando se projeta inferência para produção, quatro dimensões costumam guiar as decisões arquiteturais:

• Disponibilidade: manter a inferência funcionando mesmo durante falhas de modelo, região ou provedor.
• Tempo de resposta: velocidade com que o usuário recebe o output, medida pelo Tempo até o Primeiro Token (TTFT) e Tempo até o Último Token (TTLT).
• Custo: gasto por token e por requisição, e como as decisões de roteamento afetam esse valor.
• Throughput: quantas requisições simultâneas e tokens por segundo o sistema aguenta sob carga.

Essas dimensões são interligadas. Roteamento entre regiões, por exemplo, melhora disponibilidade e throughput, mas pode aumentar a latência. Os cinco padrões apresentados a seguir focam principalmente em disponibilidade — mantendo a inferência operacional por meio de failover, distribuição geográfica e isolamento de cotas.

Uma abordagem incremental: do nativo ao gateway

A progressão sugerida segue uma lógica de “engatinhar, caminhar, correr”: começa com recursos nativos do Amazon Bedrock e avança até orquestração multi-modelo via LLM Gateway. Isso permite adotar os padrões gradualmente, conforme a maturidade e os requisitos da aplicação. Os exemplos de código para cada padrão estão disponíveis no repositório GitHub oficial.

Antes de começar, é necessário verificar se o software adequado está instalado e se a conta AWS está configurada corretamente — consulte os pré-requisitos no repositório. Vale lembrar que os padrões descritos criam recursos AWS que geram cobranças, incluindo requisições de inferência no Amazon Bedrock e logs no Amazon CloudWatch.

Padrão 1: Inferência entre regiões com Amazon Bedrock (CRIS)

A Inferência Entre Regiões do Amazon Bedrock (CRIS) é um recurso nativo que serve de base para a resiliência por padrão. Com os perfis de inferência entre regiões, é possível aumentar o throughput, reduzir a chance de throttling dentro de uma única região AWS e distribuir o tráfego de modelos — sem gerenciamento manual.

O CRIS roteia automaticamente as requisições da região de origem para a região de destino mais adequada, considerando disponibilidade, latência e demanda em tempo real. Isso lida bem com picos inesperados de tráfego e reduz o impacto de cotas de serviço. Os perfis CRIS costumam estar vinculados a regiões comerciais dentro de uma mesma geografia — como EUA ou Europa — equilibrando desempenho e latência.

Para casos de uso que toleram maior latência, existe a opção dos perfis de Inferência Global Entre Regiões. Com um perfil Global, as requisições podem ser roteadas por múltiplas regiões comerciais onde o modelo está disponível, entregando throughput ainda maior do que os perfis padrão entre regiões.

No exemplo do repositório, ao enviar 10 requisições usando um perfil de inferência entre regiões, o CRIS distribui automaticamente a carga por 3 regiões AWS — demonstrando como o recurso atua de forma transparente para a aplicação.

Padrão 2: Sharding de contas AWS

Enquanto o CRIS multiplica o throughput dentro de uma conta AWS, o sharding de contas distribui requisições por múltiplas contas, cada uma com cotas independentes e perfis CRIS próprios. Isso cria fronteiras naturais de isolamento de falhas: problemas em uma conta não afetam as demais.

Essa abordagem é especialmente valiosa para arquiteturas multi-time e multi-tenant que exigem isolamento rígido entre workloads. Na demonstração do repositório, 10 requisições são enviadas para cada uma das duas contas AWS configuradas, e cada conta distribui independentemente a inferência entre regiões AWS — mostrando como o isolamento funciona na prática.

LLM Gateway: orquestração para cenários complexos

Para cenários de produção mais complexos, um LLM Gateway oferece capacidades de roteamento, failover e governança que vão além do que é possível com chamadas diretas à API. O gateway atua como um proxy inteligente entre as aplicações e os provedores de LLM, fornecendo uma camada de abstração unificada — permitindo acessar múltiplos modelos de diferentes fornecedores por uma única interface de API.

Essa padronização simplifica a integração e embute funcionalidades como salvaguardas de IA responsável, logging de auditoria, lógica automática de retry e fallback, e gerenciamento de cotas. O gateway também suporta roteamento inteligente e balanceamento de carga entre múltiplos modelos e contas, implementando rate limiting e gerenciamento de cotas com isolamento por consumidor.

Diversas opções de LLM Gateway — open source e comerciais — estão disponíveis hoje. Para as demonstrações do repositório, é utilizado o LiteLLM, uma opção leve e open source rodando localmente. Para implantações em escala, a AWS Solution for Multi-Provider Generative AI Gateway fornece uma implementação de referência que também usa LiteLLM, mas adiciona capacidades enterprise: implantação em containers no Amazon Elastic Container Service (ECS) ou no Amazon Elastic Kubernetes Service (EKS), escalabilidade automática, proteção com AWS WAF, gerenciamento de segredos e observabilidade completa via Amazon CloudWatch.

Padrão 3: Fallback automático entre modelos

O failover automático entre modelos mantém a disponibilidade mesmo quando os modelos primários atingem rate limits ou enfrentam interrupções. O padrão roteia requisições automaticamente entre modelos primários e secundários definidos pelo usuário.

Vale destacar: se a estratégia de fallback foca em otimizar qualidade e custo — e não apenas em esgotamento de cotas — o Amazon Bedrock Intelligent Prompt Routing oferece uma opção nativa, selecionando dinamicamente o modelo mais adequado para cada requisição sem necessidade de gateway externo.

Na demonstração com LiteLLM, o modelo primário tem um rate limit restritivo de 3 requisições por minuto (RPM) e o modelo de fallback tem capacidade de 25 RPM. Ao enviar 10 requisições simultâneas pelo gateway, as 3 primeiras vão para o modelo primário. Ao atingir o limite, o LiteLLM desvia automaticamente as 7 requisições restantes para o modelo de fallback — tudo sem intervenção manual ou lógica de retry no nível da aplicação. O resultado: 100% de sucesso nas 10 requisições.

Padrão 4: Balanceamento de carga entre modelos

O balanceamento de carga distribui requisições por múltiplas instâncias de modelo para otimizar a utilização de recursos e evitar gargalos. Além de maximizar o uso, a abordagem permite escalar rapidamente adicionando ou removendo instâncias conforme necessário.

Um caso de uso interessante é a avaliação de novos modelos antes do deploy completo: é possível implementar roteamento ponderado ou estratégias de A/B testing, direcionando apenas uma pequena porcentagem de requisições para o novo modelo enquanto a maioria continua usando os modelos já validados.

Na demonstração, o gateway distribui 10 requisições simultâneas por dois modelos usando uma estratégia de embaralhamento (shuffle). O balanceador roteia 3 requisições para cada um dos dois modelos primários configurados e, ao atingir o rate limit, as 4 requisições restantes são redirecionadas automaticamente para o modelo de fallback — resultando em 100% de sucesso.

Padrão 5: Isolamento de cotas em ambientes multi-tenant

O padrão de isolamento de cotas multi-tenant cria ambientes logicamente isolados, cada um com suas próprias cotas e rate limits, para gerenciar requisições em ambientes com múltiplos inquilinos. Ao implementar buckets de rate limiting independentes para cada consumidor, o padrão evita o problema do “vizinho barulhento” — onde o uso intenso de um consumidor impacta negativamente o desempenho dos demais.

Cada tenant recebe uma cota dedicada independente dos padrões de uso dos demais, garantindo alocação justa de recursos e qualidade de serviço consistente. Na demonstração, três consumidores com rate limits diferentes tentam acessar o mesmo modelo simultaneamente:

• Consumidor A: 3 RPM permitidos — ao enviar 5 requisições, apenas 3 têm sucesso e 2 são rejeitadas por rate limiting.
• Consumidor B: 10 RPM — 100% de sucesso nas 5 requisições.
• Consumidor C: 10 RPM — 100% de sucesso nas 5 requisições.

O resultado confirma que o isolamento funciona: o Consumidor A (“barulhento”) não afeta em nada a experiência dos Consumidores B e C.

Quando faz sentido aplicar esses padrões?

A resposta, como em quase tudo em arquitetura, é “depende”. Mas alguns cenários onde esses padrões claramente fazem sentido incluem:

• Alta disponibilidade: quando a aplicação não pode tolerar downtime, múltiplos modelos garantem failover automático.
• Escala além das cotas de um único modelo: usar o mesmo tipo de modelo em diferentes contas e regiões multiplica a capacidade total disponível.
• Isolamento multi-tenant: em aplicações SaaS, diferentes clientes podem usar modelos ou instâncias distintas, sem que o uso de um impacte os outros.
• Desenvolvimento vs. produção: configurações separadas para testes (modelos mais baratos e rápidos) e produção (modelos de maior qualidade) sem mudanças no código.

Conclusão

Os cinco padrões apresentados cobrem uma progressão completa para inferência LLM resiliente — desde o CRIS nativo do Amazon Bedrock até padrões mais complexos que requerem um LLM Gateway. Com essas estratégias, equipes ganham controle granular sobre disponibilidade de modelos, estratégias de failover e isolamento por consumidor ou aplicação.

O repositório GitHub traz exemplos de código e instruções passo a passo para testar cada padrão. Para uma implementação de referência completa de um LLM Gateway pronto para produção, a AWS Solution for Multi-Provider Generative AI Gateway é o ponto de partida recomendado. Para mais padrões arquiteturais e boas práticas de IA generativa, o Blog de Inteligência Artificial da AWS é uma boa fonte de consulta.

Fonte

Implementing resilience patterns with Amazon Bedrock and LLM gateway (https://aws.amazon.com/blogs/machine-learning/implementing-resilience-patterns-with-amazon-bedrock-and-llm-gateway/)

O que é o Claude Sonnet 5 e por que isso importa

A AWS anunciou a disponibilidade do Claude Sonnet 5, o modelo mais avançado da linha Sonnet da Anthropic, tanto no Amazon Bedrock quanto na Claude Platform on AWS. Este é o primeiro modelo Sonnet da geração mais recente da Anthropic e representa um avanço significativo em termos de capacidade, mantendo o equilíbrio de custo e velocidade que caracteriza a família Sonnet.

Em termos práticos, o Claude Sonnet 5 entrega uma inteligência próxima ao nível do Claude Opus — o modelo de ponta da Anthropic — mas com o preço e a performance da linha Sonnet. Isso significa que equipes podem usar um modelo de alto desempenho para tarefas cotidianas em escala, sem incorrer nos custos do tier Opus.

Duas formas de acessar o modelo na AWS

O Claude Sonnet 5 está disponível por dois caminhos dentro do ecossistema AWS:

• Amazon Bedrock: permite construir dentro do ambiente AWS já existente, mantendo segurança corporativa, residência regional de dados e escalabilidade de inferência.
• Claude Platform on AWS: oferece acesso à experiência nativa da plataforma da Anthropic via Console de Gerenciamento da AWS (AWS Management Console), com as mesmas APIs, funcionalidades e experiência de console que se teria trabalhando diretamente com a Anthropic — unificado com faturamento e autenticação AWS. Confira a documentação oficial da Claude Platform on AWS para mais detalhes.

O que diferencia o Claude Sonnet 5

O Sonnet 5 traz melhorias concretas em três frentes principais: raciocínio e planejamento, codificação e agentes autônomos.

Raciocínio e planejamento

O modelo consegue manter um plano ao longo de múltiplas etapas, rastrear o que já foi feito e o que ainda falta, e resolver problemas com menos rodadas de correção. Isso resulta em um comportamento mais previsível em operações de larga escala.

Codificação

O Sonnet 5 foi projetado para navegar em bases de código reais, aplicar mudanças em múltiplos arquivos e conduzir tarefas longas de depuração e refatoração até a conclusão. O código gerado é mais limpo e de fácil manutenção, exigindo menos supervisão humana.

Agentes autônomos

Para sistemas de agentes, o Claude Sonnet 5 funciona como um backbone mais confiável para operações automatizadas — lidando com cadeias de dependência complexas e uso de ferramentas em múltiplas etapas. É uma escolha sólida tanto para agentes voltados ao cliente quanto para automações internas.

Trabalho profissional

O modelo também se destaca na síntese de fontes longas, complexas e não estruturadas em entregas organizadas, como briefings, análises e relatórios.

Casos de uso por setor

O Claude Sonnet 5 é especialmente indicado para setores onde confiabilidade e raciocínio estruturado são críticos:

• Serviços financeiros: modelagem em planilhas, análise financeira e agentes de relatórios que auditam os próprios números durante a execução, suportando fluxos completos desde a ingestão de dados até a saída validada.
• Produtividade: construção e auditoria de relatórios, redação de documentos e análise estruturada com alta consistência. Com as capacidades de uso de computador (computer use), é possível automatizar fluxos de trabalho em navegadores e desktops que antes exigiam interação humana.
• Automação de agentes e fluxos de trabalho: serve como backbone para agentes em produção que chamam ferramentas e executam tarefas em múltiplas etapas sem supervisão contínua.

Como começar com o Claude Sonnet 5 no Amazon Bedrock

Para iniciar, é possível testar o modelo diretamente no console do Amazon Bedrock, acessando a seção Test > Playground e selecionando o Claude Sonnet 5.

Para acesso programático, o modelo pode ser chamado via Anthropic Messages API — usando o Anthropic SDK ou endpoints bedrock-mantle — ou pelas APIs Invoke e Converse no bedrock-runtime, via Interface de Linha de Comando da AWS (AWS CLI) ou AWS SDK.

Pré-requisitos

• Conta AWS ativa com acesso ao Amazon Bedrock
• AWS CLI instalado e configurado
• Python 3.8 ou superior
• Boto3 instalado: pip install boto3
• Anthropic SDK instalado: pip install anthropic[bedrock]
• Permissões de Gerenciamento de Identidade e Acesso (IAM): bedrock:InvokeModel, bedrock:InvokeModelWithResponseStream e bedrock:CreateInference

Exemplo com AWS SDK para Python (Boto3)

import boto3
import json

# Create a Bedrock Runtime client
bedrock_runtime = boto3.client(
    service_name="bedrock-runtime",
    region_name="us-east-1"
)

# Invoke Claude Sonnet 5
response = bedrock_runtime.invoke_model(
    modelId="us.anthropic.claude-sonnet-5",
    contentType="application/json",
    accept="application/json",
    body=json.dumps({
        "anthropic_version": "bedrock-2023-05-31",
        "max_tokens": 4096,
        "messages": [
            {
                "role": "user",
                "content": "Design a distributed architecture on AWS in Python that should support 100k requests per second across multiple geographic regions."
            }
        ]
    })
)

result = json.loads(response["body"].read())
print(result["content"][0]["text"])

Exemplo com a Converse API

import boto3

bedrock_runtime = boto3.client("bedrock-runtime", region_name="us-east-1")

response = bedrock_runtime.converse(
    modelId="us.anthropic.claude-sonnet-5",
    messages=[
        {
            "role": "user",
            "content": [
                {
                    "text": "Design a distributed architecture on AWS in Python that should support 100k requests per second across multiple geographic regions."
                }
            ]
        }
    ],
    inferenceConfig={
        "maxTokens": 4096
    }
)

print(response["output"]["message"]["content"][0]["text"])

Exemplo com Anthropic Messages API via SDK bedrock-mantle

from anthropic import AnthropicBedrockMantle

# Initialize the Bedrock Mantle client (uses SigV4 auth automatically)
mantle_client = AnthropicBedrockMantle(aws_region="us-east-1")

# Create a message using the Messages API
message = mantle_client.messages.create(
    model="anthropic.claude-sonnet-5",
    max_tokens=4096,
    messages=[
        {"role": "user", "content": "Design a distributed architecture on AWS in Python that should support 100k requests per second across multiple geographic regions"}
    ]
)

print(message.content[0].text)

Disponibilidade e precificação

O Claude Sonnet 5 já está disponível no Amazon Bedrock. A lista completa de regiões AWS suportadas pode ser consultada na documentação do Amazon Bedrock. O modelo também está disponível na Claude Platform on AWS nas regiões da América do Norte, América do Sul, Europa e Ásia-Pacífico.

Para experimentar, acesse o console do Amazon Bedrock, a Claude Platform on AWS, ou explore os notebooks de introdução disponíveis no GitHub. O Sonnet 5 está disponível com precificação promocional até 31 de agosto de 2026 — veja os detalhes na página de preços do Amazon Bedrock.

Vale destacar também que é possível potencializar ainda mais o Sonnet 5 utilizando a Otimização Avançada de Prompts (Advanced Prompt Optimization) no Amazon Bedrock. A funcionalidade recebe os prompts atuais, os avalia contra critérios definidos pelo usuário e gera versões otimizadas prontas para produção.

Fonte

Introducing Claude Sonnet 5 on AWS: Anthropic’s most capable Sonnet model (https://aws.amazon.com/blogs/machine-learning/introducing-claude-sonnet-5-on-aws-anthropics-most-capable-sonnet-model/)

O problema: formulários em papel ainda custam caro na saúde

O processamento manual de formulários em papel continua sendo um dos maiores custos operacionais no setor de saúde. Mesmo com os avanços em extração de dados de documentos digitalizados, a supervisão humana ainda é necessária na maioria dos casos — seja para corrigir erros de preenchimento, seja para lidar com extrações de baixa confiança geradas pelo processo de digitalização.

Para endereçar esse desafio, a AWS publicou um guia técnico mostrando como construir um pipeline automatizado de processamento de sinistros usando duas capacidades do Amazon Bedrock: o Amazon Bedrock Data Automation para extração inteligente de dados de formulários de sinistros, e o Amazon Bedrock AgentCore para hospedar um agente de IA que valida e transforma os dados extraídos em recursos FHIR (Recursos Interoperáveis de Saúde Rápidos) no AWS HealthLake.

Visão geral da solução

O fluxo proposto automatiza o processamento de formulários CMS-1500 — o formulário padrão de sinistros médicos nos Estados Unidos — usando serviços de IA da AWS. O processo começa quando um prestador de saúde faz o upload de um formulário em PDF para um bucket do Amazon Simple Storage Service (Amazon S3), o que dispara uma cadeia de processamento baseada no AWS Lambda.

Esse pipeline executa três funções principais:

• O Amazon Bedrock Data Automation extrai os dados estruturados do formulário usando processamento inteligente de documentos.
• Um agente de IA baseado no Strands Agents, rodando no Amazon Bedrock AgentCore, valida os dados extraídos consultando registros de pacientes e prestadores no AWS HealthLake, verificando completude e consistência.
• Se todas as validações passarem, o agente cria um recurso FHIR padronizado do sinistro no HealthLake e gera dois tipos de resumo: um técnico para os analistas de sinistros e outro em linguagem acessível para o paciente. Ambos são enviados como notificações via Amazon Simple Notification Service (Amazon SNS).

Fluxo arquitetural passo a passo

O diagrama da solução ilustra o seguinte fluxo:

1. Um usuário faz o upload do documento de sinistro para o Amazon S3.
2. O AWS Lambda é acionado automaticamente com a chegada do arquivo.
3. O Amazon Bedrock Data Automation extrai as informações do documento e retorna o resultado em formato JSON.
4. O Lambda aciona o AgentCore e passa o documento para processamento.
5. O AgentCore consulta o AWS HealthLake, cria o sinistro e retorna um JSON de resposta com o resumo.
6. O Lambda invoca o Amazon SNS para entregar uma resposta de erro ou de sucesso.

O Lambda atua como gatilho de eventos quando um documento é criado no S3 e funciona como um supervisor determinístico sobre o fluxo agêntico. Ele garante que cada documento seja processado ou encaminhado para uma fila de mensagens mortas para tratamento de exceções.

Como cada serviço funciona nessa arquitetura

Amazon Bedrock Data Automation

O Bedrock Data Automation simplifica o desenvolvimento de IA generativa e automatiza fluxos de trabalho que envolvem documentos, imagens, áudio e vídeos. Para o processamento de documentos, ele combina OCR (Reconhecimento Óptico de Caracteres) tradicional, modelos de aprendizado de máquina e IA generativa para extrair dados com precisão.

É possível usar Blueprints (artefatos de configuração) para especificar quais dados extrair de um documento e como fazer isso. Há templates pré-construídos ou a opção de criar configurações personalizadas para cada caso de uso. O output inclui pontuações de confiança e dados de bounding box para os campos e tabelas extraídos. No caso desta solução, o output personalizado produz uma representação JSON previsível do formulário CMS-1500 em suas diferentes variações de formato.

Amazon Bedrock AgentCore e o agente Strands

O AgentCore hospeda o agente Strands, que utiliza duas ferramentas para interagir com o HealthLake: create_fhir_claim e search_fhir_resources.

O fluxo de trabalho do agente segue esta lógica:

• Localizar as informações do Segurado, Paciente, Médico e Cobertura no AWS HealthLake para usar como referência no formulário de sinistro. A primeira tentativa usa chamadas diretas de método com parâmetros de busca padrão.
• Se necessário, o agente executa tentativas adicionais com diferentes parâmetros de busca, priorizando atributos com alta pontuação de confiança.
• Se as referências forem encontradas, o agente cria a representação FHIR do sinistro e a envia para o AWS HealthLake.
• Por fim, o agente gera um objeto JSON com o ID do sinistro (se criado), uma resposta para o analista humano e uma resposta para o paciente.

Pré-requisitos para implantar a solução

Antes de implantar a solução, é necessário ter:

• Uma conta AWS com permissões de administrador.
• Acesso ao Anthropic Claude Sonnet 4.6 no Amazon Bedrock. Veja mais detalhes em como acessar os modelos de fundação do Amazon Bedrock.
• NodeJS versão 24 ou superior.
• Node Package Manager (npm) versão 11.5 ou superior.
• Python versão 3.13 ou superior.
• AWS Cloud Development Kit (AWS CDK) versão 2.1025 ou superior.

Como implantar a solução

O AWS CDK e a interface de linha de comando do AgentCore são usados para a implantação. Os passos são os seguintes:

Clone o repositório:

git clone https://github.com/aws-samples/sample-agenticidptohealthlake.git

Execute os seguintes comandos a partir da raiz do repositório:

npm install
python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
pip install -r requirements.txt --python-version 3.12 --platform manylinux2014_aarch64 --target ./packaging/_dependencies --only-binary=:all:
cd agentcore
agentcore configure --entrypoint claimsprocessor.py
agentcore launch
python ./bin/package_for_lambda.py
npx cdk bootstrap
npx cdk deploy

Após o deploy, é necessário se inscrever no tópico SNS para receber notificações. Para isso:

• Acesse o console do Amazon SNS.
• Escolha Topics e selecione Agent-Notifications.
• Clique em Create subscription, escolha o protocolo email, informe seu endereço de e-mail e confirme a inscrição pelo link enviado ao e-mail.

Testando a solução: cenários de falha e sucesso

Cenário de falha

Para simular uma falha, basta omitir um dos recursos de referência obrigatórios no AWS HealthLake. O projeto inclui uma pasta sampledata. Use o script load_sampledata.py para carregar dados de teste, onde <data_store_id> é o valor de HealthLakeDatastoreArn obtido no output do cdk deploy:

python load_sampledata.py <data_store_id> bda_output_insuredid_error.json Patient,Insured,Practitioner

Em seguida, faça o upload do arquivo sample1_cms-1500-P.pdf para o bucket S3 dentro de uma pasta chamada /input. Como um dos recursos obrigatórios não foi carregado intencionalmente, o sistema deve gerar uma mensagem via SNS similar a:

“Não foi possível processar seu sinistro porque não encontramos suas informações de cobertura de seguro em nosso sistema. Entre em contato com sua seguradora para verificar o número da apólice G4683A com o plano AnyHealth Plus Medicare, ou ligue para nosso escritório para atualizar suas informações de cobertura.”

Esse cenário demonstra como o agente reconhece o problema e gera uma resposta amigável ao usuário sobre a falha no processamento do sinistro.

Cenário de sucesso

Para simular um processamento bem-sucedido, todos os recursos obrigatórios do HealthLake precisam existir. Nesse cenário, uma discrepância de dados é inserida intencionalmente para que o agente precise superá-la. No dado de exemplo, o número de identificação do segurado foi alterado.

Crie a referência ausente no HealthLake:

python load_sampledata.py <data_store_id> bda_output_insuredid_error.json Coverage

Reprocesse o PDF seguindo os mesmos passos anteriores. A mensagem recebida via SNS será similar a:

“Formulário CMS 1500 processado com sucesso para o paciente John Doe com diagnóstico de Dor nas Costas M54.9. O paciente foi identificado pela data de nascimento (1960-10-10). O segurado Jane Doe foi identificado por busca de nome após falha na busca por ID devido a uma discrepância entre o ID do sinistro (11-2234-10190) e o ID do banco de dados (11-2234-1019O) — o último caractere difere. A Dra. Jane Smith foi identificada como médica solicitante pelo ID 123456. A cobertura foi verificada na apólice Medicare G4683A emitida pela AnyHealth Plus. O sinistro inclui 4 procedimentos: CPT 97810 em 15/10/2005 (US$ 170), CPT 73521 em 20/10/2005 (US$ 120), CPT 98940 em 30/10/2005 (US$ 250) e CPT 97124 em 30/10/2005 (US$ 120), totalizando US$ 660.”

Essa mensagem oferece ao analista humano um resumo rápido do sinistro aprovado e qualquer observação relevante feita pelo agente durante o processo.

Boas práticas destacadas pela AWS

IA em tempo de design é melhor do que IA em tempo de execução

Nessa solução, a lógica de orquestração é conhecida antecipadamente. As etapas de processamento de documentos são previsíveis, e as consultas iniciais ao HealthLake seguem um padrão consistente. Como esses requisitos estão bem definidos em tempo de design, a lógica foi codificada explicitamente em vez de depender de servidores MCP (Protocolo de Contexto de Modelo) para inferir a ordem das operações em tempo de execução. O resultado é uma solução mais confiável e fácil de manter.

Para construir a solução, foi utilizado o Kiro, uma IDE agêntica que traduz especificações em linguagem natural para código funcional. O Kiro gerou as chamadas de API para o Bedrock Data Automation dentro do Lambda e construiu as ferramentas dentro do agente. Ao produzir código preciso e direcionado em tempo de design, em vez de emitir prompts amplos e exploratórios em tempo de execução, o número de chamadas ao Bedrock foi reduzido — o que ajuda a diminuir os custos operacionais e encurta o ciclo de desenvolvimento.

Supervisão determinística dos agentes

O uso do S3 e do Lambda nessa arquitetura foi intencional. O agente executa duas funções básicas: observar as chamadas explícitas de ferramentas e gerar o recurso FHIR para carregar no HealthLake. Em seguida, ele reporta de volta para a função Lambda, que atua como árbitro final de sucesso ou falha do sinistro.

Limpeza do ambiente

Para remover a solução, os seguintes comandos podem ser executados:

cd agentcore
python cleanup_resources.py
npx cdk destroy

Estimativa de custos

A AWS apresenta as seguintes considerações de custo para cada serviço utilizado. Os valores são baseados na precificação da AWS no momento da publicação original e podem variar:

• AgentCore Runtime: cobranças de US$ 0,0895 por vCPU-hora e memória a US$ 0,00945 por GB-hora, resultando em um custo nominal por documento.
• Amazon Bedrock Data Automation: US$ 0,04 por página para blueprints com até 30 campos; US$ 0,0005 para cada campo adicional além de 30.
• Cobranças de modelo para o agente usando Anthropic Claude Sonnet 3.7 V1. No documento de teste, os tokens foram aproximadamente 76 mil de entrada e 6 mil de saída. No modelo de preço sob demanda, isso representa US$ 0,23 de entrada e US$ 0,09 de saída, totalizando US$ 0,32 por documento.
• AWS HealthLake: cobrado por armazenamento por hora, a US$ 0,27 por hora para os primeiros 10 GB.
• Lambda, S3 e SNS: custos negligíveis por documento nessa arquitetura.

Conclusão

Embora o processamento de sinistros de saúde em produção frequentemente envolva etapas adicionais além das cobertas por essa solução, o padrão demonstrado evidencia o poder de integrar agentes de IA em fluxos de trabalho com documentos. Ao dar ao agente acesso direto às ferramentas de processamento, ele consegue oferecer insights valiosos de múltiplas formas: identificando possíveis problemas no sinistro, destacando áreas que precisam de revisão humana e gerando mensagens de status acessíveis para os pacientes.

O exemplo do cenário de sucesso ilustra uma situação real e frequente: uma discrepância entre a letra “o” e o número “0” em um identificador. Nesse caso, o agente navegou pela discrepância e processou o sinistro corretamente.

Para saber mais sobre como construir soluções de processamento inteligente de documentos, a AWS recomenda explorar a documentação do Amazon Bedrock ou conferir outras soluções de saúde no AWS Architecture Center.

Fonte

Build an agentic AI healthcare claims pipeline with Amazon Bedrock and AWS HealthLake (https://aws.amazon.com/blogs/machine-learning/build-an-agentic-ai-healthcare-claims-pipeline-with-amazon-bedrock-and-aws-healthlake/)

Quando agentes de IA falham em silêncio

Agentes de Inteligência Artificial (IA) em produção têm um comportamento peculiar quando algo dá errado: eles frequentemente falham sem disparar nenhum alerta. Podem retornar respostas plausíveis, mas incorretas; entrar em loops de raciocínio que nunca terminam; ou escolher ferramentas erradas para resolver um problema — tudo isso sem gerar uma exceção sequer nos logs tradicionais.

É justamente para endereçar esse cenário que a AWS apresentou o Amazon Bedrock AgentCore Observability. O recurso oferece visibilidade sobre a execução de agentes em três camadas: métricas, traces e logs estruturados. Com isso, é possível acompanhar cada etapa do raciocínio do agente, inspecionar chamadas de ferramentas e identificar exatamente onde o fluxo desviou do esperado — mesmo quando nenhum erro explícito foi lançado.

Este artigo é a Parte 1 de uma série de dois posts. A Parte 2 aborda otimização de desempenho e gerenciamento de memória.

Pré-requisitos

Para seguir os exemplos práticos descritos neste post, é necessário ter uma conta AWS com o Amazon Bedrock AgentCore habilitado, familiaridade com dashboards do Amazon CloudWatch e consultas básicas de logs, além de conhecimento de papéis e políticas do AWS Gerenciamento de Identidade e Acesso (IAM). Também é necessário ter o CloudWatch Transaction Search ativado na conta e um agente Bedrock AgentCore já implantado ou permissão para implantar um.

Os três padrões de falha mais comuns

Agentes de IA falham de forma diferente das aplicações tradicionais. Os problemas costumam se encaixar em três categorias: qualidade, confiabilidade e eficiência.

Falhas de qualidade

Ocorrem quando o agente conclui a tarefa, mas retorna resultados incorretos. Os sistemas de monitoramento registram execuções bem-sucedidas enquanto os usuários recebem respostas imprecisas. Alucinações são comuns: o agente pode referenciar políticas inexistentes ou gerar dados para preencher lacunas. Em sistemas com múltiplos agentes, esses erros se propagam quando a saída de um agente vira entrada de outro. Revisar os traces de execução é o caminho para identificar onde a lógica quebrou.

Falhas de confiabilidade

Impedem que o agente conclua seu fluxo de trabalho. Erros de invocação de ferramentas são causa frequente: um erro 401 indica credenciais ausentes ou expiradas; um 403 aponta para permissões IAM insuficientes; e um 400 sugere entrada inválida. Outro problema comum é a perda de contexto, onde o agente não retém o estado da sessão e trata requisições de acompanhamento como conversas novas.

Problemas de eficiência

Afetam custo e desempenho, não a correção. Alta latência reduz o engajamento do usuário. Uso excessivo de tokens aumenta o custo sem melhorar os resultados — isso ocorre quando agentes geram respostas muito longas, recuperam documentos completos desnecessariamente ou repetem chamadas de ferramentas em vez de usar cache.

O kit de ferramentas de observabilidade

O Bedrock AgentCore Observability combina três camadas que trabalham juntas para levar o time de engenharia da detecção de um problema até sua causa raiz.

Dashboards do Amazon CloudWatch

O dashboard GenAI Observability exibe volume de sessões, latência de invocação, uso de tokens e taxas de erro em uma visão unificada. É possível filtrar por ID do agente, ID da sessão ou intervalo de tempo. Alarmes do CloudWatch notificam automaticamente quando a latência ultrapassa limites aceitáveis ou quando a taxa de erros sobe acima do normal.

Traces com OpenTelemetry

Enquanto os dashboards mostram o comportamento do sistema em alto nível, os traces mostram como cada requisição é executada passo a passo. O Bedrock AgentCore emite traces distribuídos, logs estruturados em nível de span e métricas sob o namespace bedrock-agentcore do CloudWatch. Essa telemetria segue o protocolo OpenTelemetry (OTEL) e é roteada para o CloudWatch por padrão. Se a organização usar Datadog, Grafana Cloud ou Elastic Observability, é possível exportar a mesma telemetria para esses backends sem instrumentação adicional.

Cada trace captura o fluxo completo de execução: etapas de raciocínio, invocações de ferramentas, recuperações de memória e saídas finais.

Métricas-chave para monitorar

A recomendação é acompanhar três categorias:

• Desempenho: latência nos percentis 50, 95 e 99; tempo de recuperação de memória; tempo de resposta de ferramentas.
• Recursos: duração da sessão, sessões simultâneas e uso de tokens de entrada e saída separadamente.
• Confiabilidade: taxa de erros por categoria — autenticação, autorização, validação e timeout.

Habilitando a observabilidade

Antes de começar a depurar, é preciso ativar o CloudWatch Transaction Search na conta. Isso permite que o Bedrock AgentCore envie dados de trace e métricas ao CloudWatch. Após a ativação, o serviço passa a coletar dados de observabilidade em todos os agentes, sistemas de memória e integrações de ferramentas.

Cenário 1: Depurando loops infinitos

Loops infinitos ocorrem quando agentes não têm condições de encerramento adequadas ou não reconhecem quando cometem erros repetidos. Três causas raiz são as mais frequentes:

• Design de prompt inadequado: o prompt do sistema não estabelece condições de encerramento claras — não especifica quantas tentativas são razoáveis, quando declarar uma tarefa impossível ou quando escalar para um humano.
• Ausência de detecção de loop: o framework do agente não reconhece ações repetidas. Sem lógica explícita para rastrear tentativas anteriores, o agente não consegue perceber que está preso.
• Seleção incorreta de ferramenta: o agente escolhe consistentemente a ferramenta errada, como tentar resolver um cálculo matemático com uma ferramenta de busca na web.

Sintomas a observar

Quando um agente entra em loop, o uso de tokens aumenta significativamente e a duração da sessão cresce além do normal. Em alguns casos, o agente gera múltiplas respostas sem entrada do usuário. O detalhe mais enganoso: a taxa de erros permanece baixa, porque o agente não está travando — ele simplesmente não consegue concluir a tarefa. Alto consumo de tokens combinado com zero erros é o sinal clássico de loop infinito.

Diagnóstico: problema de engenharia de prompt

O primeiro passo é identificar a sessão problemática. A consulta abaixo no CloudWatch Logs Insights localiza sessões com uso de tokens anormalmente alto:

fields @timestamp, SessionId, TokenUsage
| filter TokenUsage > 10000
| sort TokenUsage desc
| limit 20

Com o SessionId em mãos, é possível examinar o padrão de raciocínio do agente naquela sessão:

fields @timestamp, @message, RequestId
| filter SessionId = "<SessionId>"
| filter Operation like /InvokeAgent/
| sort @timestamp asc
| limit 1000

Um trace com 177 spans e latência média de 85.590 ms (~85 segundos) é um sinal claro de loop. Respostas normais de agentes completam em 1 a 5 segundos.

Ao inspecionar os logs de raciocínio, um padrão repetitivo como o abaixo confirma o problema:

"Try using calculator tool with input 25"
"Result: 24.95"
"This is incorrect, try again"
"Try using calculator tool with input 25"
"Result: 24.95"
"This is incorrect, try again"

O trace OpenTelemetry revela a causa raiz: um prompt de sistema instruindo o agente a “nunca desistir” e “continuar tentando até obter a resposta exata” — sem nenhuma condição de encerramento. Para corrigir, basta adicionar instruções explícitas de término ao prompt, como: “Se você tentar a mesma ação três vezes sem sucesso, pare e explique ao usuário por que não consegue concluir a tarefa.” Também é recomendado definir um limite máximo de tokens por sessão (tipicamente 5.000 a 10.000 para um agente conversacional) e um limite de etapas de raciocínio de 10 a 15 passos como parada forçada.

Diagnóstico: falha na detecção de loop

Para examinar sequências de invocação de ferramentas, use:

fields @timestamp, ToolName, ToolInput, ToolOutput
| filter SessionId = "<SessionId>"
| filter Operation like /InvokeTool/
| sort @timestamp asc

Um padrão como o abaixo confirma falha na detecção de loop — a mesma ferramenta sendo chamada dezenas de vezes com entradas quase idênticas, nunca atingindo o valor exato exigido pelo prompt:

2026-02-02 22:02:39 | calculate_percentage | {"value": 25, "total": 100} | 25.0
2026-02-02 22:02:45 | calculate_percentage | {"value": 25, "total": 100} | 25.0
2026-02-02 22:02:51 | calculate_percentage | {"value": 25, "total": 100} | 25.0
[repetido mais 40 vezes]

A correção é adicionar lógica de detecção de loop ao framework do agente: rastrear invocações de ferramentas e etapas de raciocínio, forçar encerramento após três ações idênticas repetidas e configurar um alarme no CloudWatch para alertar quando o uso médio de tokens por sessão crescer significativamente.

Diagnóstico: seleção incorreta de ferramenta

Quando o agente escolhe a ferramenta errada, os logs de trace mostram um padrão como:

"User wants to calculate 25% of 100"
"I should use the web_search tool to find the answer"
[web_search returns irrelevant results]
"Let me try web_search again with different terms"

A solução é fornecer descrições mais claras para cada ferramenta, com exemplos explícitos de uso na configuração do agente:

{
  "tools": [
    {
      "name": "calculator",
      "description": "Use this tool for mathematical calculations, including percentages, arithmetic, and numerical operations. Example: calculating 25% of 100."
    },
    {
      "name": "web_search",
      "description": "Use this tool to find information on the internet. Do NOT use for mathematical calculations."
    }
  ]
}

Cenário 2: Falhas de invocação de ferramentas

Diferentemente dos loops, falhas de invocação de ferramentas geram erros explícitos e taxas de erro elevadas no dashboard. O desafio é identificar rapidamente a causa raiz. Cinco tipos de erro cobrem a maioria dos casos:

• Erros de autenticação (401): credenciais expiradas, ausentes ou método de autenticação incorreto.
• Erros de autorização (403): o papel IAM do agente não tem as políticas necessárias.
• Erros de validação (400): a entrada fornecida pelo agente não corresponde ao schema esperado pela ferramenta.
• Recurso não encontrado (404): nome de ferramenta incorreto, ID de recurso inválido ou ferramenta deletada.
• Erros de execução da ferramenta (500): a própria ferramenta falhou por erros internos, timeouts ou limites de taxa.

Diagnóstico: autenticação e autorização

Para identificar qual ferramenta falha com mais frequência:

fields @timestamp, ToolName, StatusCode, ErrorMessage
| filter Operation like /InvokeTool/
| filter StatusCode like /4[0-9][0-9]|5[0-9][0-9]/
| stats count(*) by ToolName, StatusCode
| sort count desc

No Bedrock AgentCore, as ferramentas são acessadas através de Gateways, e o papel de serviço do Gateway deve ter permissões para invocar os recursos downstream. Para erros 403, por exemplo, se o agente invoca uma função AWS Lambda através do gateway, o papel de serviço do Gateway precisa incluir:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowGatewayToInvokeLambdaTool",
      "Effect": "Allow",
      "Action": [
        "lambda:InvokeFunction"
      ],
      "Resource": [
        "arn:aws:lambda:us-east-1:123456789012:function:my-tool-function"
      ]
    }
  ]
}

Para problemas de credenciais, a recomendação é usar o AWS Secrets Manager para armazenar e rotacionar credenciais automaticamente. Um alarme no CloudWatch para taxas de erro de ferramentas acima de 5% permite investigação imediata.

Diagnóstico: erros de validação

Para erros 400, examine a entrada que o agente forneceu:

fields @timestamp, ToolName, ToolInput, ErrorMessage
| filter StatusCode = 400
| limit 50

Compare a entrada do agente com o schema esperado pela ferramenta. Um exemplo clássico de incompatibilidade:

Tool expected: {"customer_id": "string", "amount": number}
Agent provided: {"customer_id": 12345, "amount": "100.00"}

A correção envolve atualizar os schemas das ferramentas para corresponder à API atual e criar testes de integração que invoquem cada ferramenta com diferentes entradas, incluindo casos extremos.

Diagnóstico: erros de recurso e execução

Para erros 404 e 500, verifique primeiro os próprios logs e métricas da ferramenta — o problema pode não estar no agente. Use a consulta:

fields @timestamp, ToolName, ToolInput, ErrorMessage
| filter StatusCode = 404 or StatusCode = 500
| limit 50

Quando uma ferramenta falha, o agente deve registrar o erro com contexto completo, tentar novamente com backoff exponencial para falhas transitórias, tentar abordagens alternativas quando a ferramenta estiver indisponível e informar claramente o usuário quando não conseguir acessar a ferramenta.

Do diagnóstico reativo ao monitoramento proativo

As consultas apresentadas nos cenários anteriores ajudam a diagnosticar problemas depois que ocorrem. Para detectá-los antes que os usuários reportem, a AWS recomenda converter essas consultas diagnósticas em dashboards e alarmes persistentes.

• Criando um alarme do CloudWatch a partir do Logs Insights: filtros de métricas monitoram continuamente o grupo de logs do agente em busca de padrões que indicam falhas. Ao associar um alarme do CloudWatch, o time é alertado automaticamente — um sistema de alerta antecipado para loops infinitos sem necessidade de executar consultas manualmente.
• Construindo um dashboard do CloudWatch: adicione as consultas diagnósticas principais como widgets no dashboard para manter visibilidade contínua da saúde dos agentes.
• Monitoramento automatizado de precisão com AgentCore Evaluators: os AgentCore Evaluators oferecem avaliação contínua e automatizada do comportamento dos agentes em escala. Em vez de revisar traces manualmente quando algo dá errado, os Evaluators inspecionam sessões em tempo real e pontuam o desempenho do agente contra critérios de qualidade.

Limpeza de recursos

Após concluir os walkthroughs, é importante remover ou desabilitar os recursos criados para evitar cobranças contínuas. Isso inclui deletar consultas salvas no Logs Insights, remover alarmes criados para uso de tokens ou taxas de erro, desativar o CloudWatch Transaction Search se foi habilitado apenas para este exercício, e deletar qualquer agente de teste implantado no console do Amazon Bedrock. Vale destacar que desativar o CloudWatch Transaction Search interrompe toda coleta futura de traces — certifique-se de não precisar mais dos dados antes de desativá-lo.

Conclusão

O Amazon Bedrock AgentCore Observability oferece um framework prático para depurar agentes em produção. As três categorias de falhas — qualidade, confiabilidade e eficiência — têm padrões identificáveis, e as consultas do CloudWatch Logs Insights apresentadas neste post permitem ir da detecção de um problema à sua causa raiz em minutos, não horas. O próximo passo é a Parte 2 da série, que aborda gargalos de desempenho e vazamentos de memória em agentes de produção.

Fonte

Debugging production agents with Amazon Bedrock AgentCore Observability (https://aws.amazon.com/blogs/machine-learning/debugging-production-agents-with-amazon-bedrock-agentcore-observability/)