Blog

Controle centralizado para agentes de codificação com IA generativa

À medida que as organizações avançam da experimentação individual para a adoção gerenciada de agentes de IA, surge uma necessidade prática: controlar o acesso aos modelos de forma consistente entre desenvolvedores e equipes. O OpenAI ChatGPT Codex, combinado com o LiteLLM, oferece exatamente isso — um ponto de controle centralizado para roteamento de modelos, identidade com escopo definido, orçamentos, limites de uso e telemetria.

A AWS publicou um guia completo mostrando como implantar um gateway LiteLLM operado pelo próprio cliente no Serviço de Contêiner Elástico da Amazon (Amazon ECS), conectá-lo a um modelo OpenAI no Amazon Bedrock e configurar o Codex para enviar requisições por esse gateway. A implementação completa está disponível no repositório guidance-codex. Para o caminho principal, o recomendado é seguir o guia de início rápido do LiteLLM na AWS.

Visão geral da arquitetura

A solução posiciona o LiteLLM entre o Codex e o Amazon Bedrock. O gateway se torna o ponto de controle compartilhado para autenticação de modelos, roteamento, orçamentos, limites de taxa e telemetria. O Codex mantém a responsabilidade pelo loop local de execução de tarefas e ferramentas na estação de trabalho do desenvolvedor.

O fluxo de requisição ocorre em cinco etapas:

• O Codex envia o contexto da tarefa atual e as definições de ferramentas disponíveis para o endpoint /v1/responses do gateway.
• O Balanceador de Carga de Aplicação (ALB) e o AWS WAF aplicam controles de rede e de camada web antes de encaminhar a requisição ao LiteLLM no AWS Fargate.
• O LiteLLM autentica o chamador, verifica o modelo configurado e a política de consumo, e usa a função de tarefa do ECS para invocar o modelo aprovado no Amazon Bedrock.
• O Amazon Bedrock retorna texto ou uma chamada de função através do LiteLLM. Se o modelo solicitar uma ferramenta, o Codex a executa localmente sob sua política de sandbox e aprovação.
• O Codex envia o resultado da ferramenta pelo LiteLLM na próxima requisição Responses, e o loop continua.

A implantação de referência também utiliza: Amazon RDS para PostgreSQL (para estado, uso e dados de orçamento do LiteLLM), AWS Secrets Manager e AWS KMS para armazenamento de chaves, Amazon CloudWatch para logs e alarmes, Amazon ECR para imagem imutável do gateway, e proteções opcionais do AWS WAF.

Por que usar o LiteLLM nesse padrão?

O LiteLLM é um gateway de IA de código aberto que fornece roteamento de modelos, chaves virtuais, orçamentos, limites de taxa e telemetria de uso por trás de endpoints compatíveis com a API. Nesse padrão, o cliente opera o LiteLLM e sua infraestrutura de suporte dentro da própria conta AWS.

O acesso direto ao Amazon Bedrock é a opção de menor complexidade quando identidade nativa da AWS, políticas do Gerenciamento de Identidade e Acesso (IAM) e logs do AWS CloudTrail atendem aos requisitos. Um gateway se torna útil quando a equipe de sistemas precisa de controles adicionais consistentes entre desenvolvedores, equipes ou provedores de modelos. O LiteLLM é uma boa opção quando é necessário:

• Permitir apenas aliases de modelos aprovados.
• Emitir chaves de gateway com escopo por usuário ou equipe.
• Aplicar orçamentos fixos e limites de requisições por minuto ou tokens por minuto.
• Centralizar política de roteamento e fallback.
• Operar o gateway, banco de dados, rede, logs e processo de atualização na própria conta AWS.

A principal contrapartida é a responsabilidade operacional: a equipe fica responsável pela disponibilidade do gateway, ciclo de vida do banco de dados, atualizações de versão, resposta a incidentes e planejamento de capacidade.

Implantando o gateway LiteLLM no Amazon ECS

Pré-requisitos

Para o passo a passo, são necessários: uma conta AWS com permissões para criar Rede Virtual Privada (VPC), Amazon ECS, Elastic Load Balancing, Amazon RDS, Amazon ECR, AWS WAF, IAM, AWS KMS, Secrets Manager e recursos do CloudWatch; acesso ao modelo OpenAI selecionado no Amazon Bedrock na região de implantação; Interface de Linha de Comando da AWS (AWS CLI) versão 2 com perfil autenticado; Docker com Buildx; Codex CLI; e Python 3. Para implantação com HTTPS, é necessária uma zona hospedada pública no Amazon Route 53 ou um certificado existente no AWS Certificate Manager (ACM) na mesma região.

Nota de custos: A solução cria recursos faturáveis, incluindo um ALB, tarefas Fargate, Amazon RDS, AWS WAF, logs e inferência de modelos. Consulte o AWS Pricing Calculator para sua região e siga a seção de limpeza após o passo a passo.

Implantando o LiteLLM no Amazon ECS

Clone o repositório e crie um arquivo de ambiente de implantação local:

git clone https://github.com/openai-on-aws/guidance-codex.git
cd guidance-codex
git checkout feat/enterprise-gateway-readiness
cp deployment/litellm/.env.deploy.example \
   deployment/litellm/.env.deploy

Configure o perfil AWS, regiões, CIDR de origem e valores de DNS ou certificado. O trecho a seguir mostra as configurações orientadas à produção:

AWS_PROFILE=your-profile
AWS_REGION=us-east-1
BEDROCK_REGION=us-east-1
ENABLE_TLS=true
GATEWAY_DOMAIN_NAME=codex-gateway.example.com
ROUTE53_HOSTED_ZONE_ID=Z0123456789EXAMPLE
ALB_CERTIFICATE_ARN=
ALLOWED_CIDR=203.0.113.10/32
ENABLE_WAF=true
DB_MULTI_AZ=true
DESIRED_COUNT=2
MIN_TASK_COUNT=2
MAX_TASK_COUNT=10

Execute a verificação prévia somente leitura:

make litellm-check

Construa a imagem LiteLLM revisada e envie para o Amazon ECR:

CONFIRM_AWS_WRITE=1 make litellm-build

Crie um conjunto de alterações do CloudFormation sem executá-lo:

make litellm-plan

Revise o conjunto de alterações e, em seguida, implante:

CONFIRM_AWS_WRITE=1 make litellm-deploy
make litellm-status

Criando uma identidade de gateway com escopo definido

Não distribua a chave mestra do LiteLLM para os desenvolvedores. Configure uma identidade de usuário ou equipe no arquivo de implantação:

CODEX_API_SECRET_ID=codex-litellm-gateway/alice-key
CODEX_KEY_ALIAS=alice@example.com
CODEX_KEY_USER_ID=alice@example.com
CODEX_KEY_MODELS=gpt-5.5
CODEX_KEY_MAX_BUDGET=50
CODEX_KEY_BUDGET_DURATION=30d
CODEX_KEY_TPM_LIMIT=100000
CODEX_KEY_RPM_LIMIT=1000

Provisione a chave:

CONFIRM_AWS_WRITE=1 make litellm-provision-key

O helper resolve a credencial mestra em um processo filho, chama a API /key/generate do LiteLLM com as políticas configuradas de modelo, orçamento e taxa, e grava a chave gerada diretamente em um segredo do Secrets Manager criptografado com KMS.

Configurando o Codex

Gere o bloco de provedor:

make litellm-codex-config

O helper lê o endpoint do gateway implantado a partir do CloudFormation e imprime a configuração de provedor do Codex. Adicione a saída ao arquivo de configuração em nível de usuário ~/.codex/config.toml. A configuração gerada tem este formato:

model = "gpt-5.5"
model_provider = "litellm-gateway"
web_search = "disabled"

[model_providers.litellm-gateway]
name = "LiteLLM Gateway"
base_url = "https://codex-gateway.example.com/v1"
wire_api = "responses"

[model_providers.litellm-gateway.auth]
command = "/absolute/path/to/python3"
args = [
  "/absolute/path/to/deployment/scripts/aws-secret-auth.py",
  "--aws-cli", "/absolute/path/to/aws",
  "--region", "us-east-1",
  "--secret-id", "codex-litellm-gateway/alice-key",
  "--field", "LITELLM_API_KEY",
  "--profile", "developer-profile",
  "print-token"
]
timeout_ms = 30000
refresh_interval_ms = 300000

Testando o Codex através do LiteLLM

Inicie uma sessão interativa do Codex e use /status para verificar que litellm-gateway é o provedor selecionado. Para um teste não interativo repetível, execute primeiro uma requisição mínima de verificação:

codex exec --sandbox read-only --ephemeral \
  "Reply with exactly LITELLM_GATEWAY_OK and no other text."

Em seguida, exercite o loop do agente com uma tarefa que exija tanto inferência de modelo quanto uma ferramenta local:

codex exec --sandbox read-only --ephemeral \
  "Read README.md with shell tools and summarize the deployment architecture. Do not modify files."

Validando o contrato da Responses API

Um prompt de texto bem-sucedido não prova que um fluxo de trabalho de agente é compatível. O Codex depende de mais do que uma resposta básica de chat. Execute a sonda estrita incluída:

make litellm-validate

A sonda verifica: campos obrigatórios do objeto Responses e formato de saída; continuação semântica com previous_response_id; streaming de eventos enviados pelo servidor com uma resposta terminal completa; e uma chamada de ferramenta forçada com ID de chamada.

O script de validação é um portão de compatibilidade, não um teste de carga. Antes da produção, também é importante testar sessões de agentes concorrentes, streams de longa duração, cancelamento de requisições, revogação de chaves, recuperação de falhas e pico de tráfego esperado.

Operacionalizando o LiteLLM para uso empresarial

A compatibilidade é apenas o ponto de partida. Antes de integrar desenvolvedores, é necessário definir como o gateway controlará o acesso ao modelo, atribuirá uso, aplicará política de consumo e fornecerá registro operacional para cada requisição.

Comece pela superfície de modelos que os desenvolvedores têm permissão de usar. Publique aliases de gateway estáveis apenas para modelos aprovados pela organização e fixe cada mapeamento upstream em deployment/litellm/litellm_config.yaml. Emita chaves com escopo separadas para usuários, equipes ou cargas de trabalho em vez de distribuir a chave mestra do LiteLLM.

A mesma identidade com escopo pode aplicar política de consumo. Defina CODEX_KEY_MAX_BUDGET, CODEX_KEY_BUDGET_DURATION, CODEX_KEY_TPM_LIMIT e CODEX_KEY_RPM_LIMIT ao provisionar uma chave.

Operar o gateway também requer uma visão do caminho completo de requisições. Monitore contagens de tarefas desejadas e em execução no ECS, rollback de implantação, saúde e latência do alvo do ALB, saúde do Amazon RDS, requisições e rejeições do LiteLLM, uso de tokens, gasto, acesso a segredos, mudanças de IAM e bloqueios do AWS WAF.

Implantações em produção devem habilitar o Amazon Bedrock Guardrails no caminho de acesso ao modelo para filtragem de conteúdo, detecção de tópicos negados e verificações de fundamentação. Os controles em nível de gateway (orçamentos, limites de taxa e roteamento) complementam, mas não substituem, as salvaguardas de IA responsável aplicadas na camada do modelo.

Caminhos alternativos de acesso

Acesso direto com IAM Identity Center

Use o provedor nativo amazon-bedrock do Codex quando identidade nativa da AWS e controles de auditoria forem suficientes:

model_provider = "amazon-bedrock"
model = "openai.gpt-5.5"

[model_providers.amazon-bedrock.aws]
profile = "codex-bedrock"
region = "us-east-1"

O desenvolvedor faz login com um perfil nomeado do IAM Identity Center:

aws sso login --profile codex-bedrock

Esse caminho remove o gateway, o banco de dados e as operações associadas. O guia de início rápido do IAM Identity Center do repositório inclui comandos CloudFormation e helpers para criar um grupo isolado e conjunto de permissões, atribuir o grupo a uma conta AWS, imprimir a configuração do cliente e validar o perfil autenticado contra o Amazon Bedrock.

Acesso gerenciado ou híbrido com Portkey

O Portkey pode ser útil quando o cliente deseja um plano de controle gerenciado, roteamento centralizado e política, ou um plano de dados híbrido suportado sem operar a pilha de referência do LiteLLM. Para uma avaliação do Codex, configure uma chave de workspace do Portkey, um provedor do Amazon Bedrock Model Catalog e o protocolo wire Responses:

model_provider = "portkey"
model = "@bedrock-validation/"

[model_providers.portkey]
name = "Portkey"
base_url = "https://api.portkey.ai/v1"
env_key = "PORTKEY_API_KEY"
wire_api = "responses"

Execute a mesma sonda estrita de Responses antes de promover para produção. Escolha o Portkey quando o modelo operacional gerenciado ou híbrido for mais importante do que executar o gateway inteiramente na sua conta AWS. Consulte o guia de início rápido de avaliação do Portkey para mais detalhes.

Limpeza dos recursos

Visualize o que o CloudFormation excluirá e reterá:

make litellm-cleanup-plan

Exclua o gateway somente após confirmar seu nome exato de pilha:

CONFIRM_STACK_DELETE=codex-litellm-gateway \
  make litellm-cleanup

A pilha de referência cria um snapshot final do Amazon RDS e retém chaves KMS, segredos do Secrets Manager, o grupo de logs do CloudWatch e o bucket de logs de acesso do ALB. Imagens do ECR e segredos de chaves com escopo provisionadas também ficam fora da exclusão da pilha. Revise e remova os recursos retidos de acordo com sua política de retenção de dados.

Conclusão

Rotear o Codex através do LiteLLM fornece um ponto de controle operado pelo cliente para seleção de modelos, identidade com escopo, orçamentos, limites de taxa e telemetria, preservando o modelo local de execução de tarefas e ferramentas do Codex. A porta de produção importante não é se um gateway pode retornar texto — é se o gateway preserva os comportamentos da Responses API que um fluxo de trabalho de agente precisa e se a equipe de sistema consegue operar a infraestrutura adicionada de forma confiável.

A recomendação é começar com acesso direto via IAM Identity Center quando os controles nativos da AWS atendem ao requisito. Adicionar o LiteLLM quando a política de gateway operada pelo cliente justificar o trabalho operacional. E avaliar o Portkey quando um modelo operacional gerenciado ou híbrido for o melhor encaixe organizacional — aplicando os mesmos testes de contrato a cada caminho.

Recursos adicionais

• Implementação do Guidance for Codex na AWS
• OpenAI no Amazon Bedrock
• Documentação do Amazon Bedrock
• Guia de início rápido do LiteLLM na AWS
• Guia de início rápido do IAM Identity Center
• Guia de implantação em produção
• Provedores de modelos personalizados do Codex
• Usando o Codex com o Amazon Bedrock
• Amazon ECS no AWS Fargate
• Documentação do AWS IAM Identity Center
• Documentação do proxy LiteLLM
• Integração do Portkey com Codex

Fonte

Set up OpenAI ChatGPT Codex with LiteLLM on Amazon ECS and Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/set-up-openai-chatgpt-codex-with-litellm-on-amazon-ecs-and-amazon-bedrock/)

Um agente que funciona no notebook não é um agente em produção

Essa é a premissa central de um guia técnico publicado pela AWS sobre como migrar workloads agênticos para o Amazon Bedrock AgentCore. O texto parte de um ponto muito honesto: a inferência do modelo raramente é o problema em produção. O que consome o time de engenharia são as responsabilidades operacionais que aparecem depois — isolamento de sessão, persistência de estado, autenticação de ferramentas, patching de infraestrutura, entre outras.

O guia mapeia dez dessas cargas operacionais e mostra como o AgentCore as absorve progressivamente, em estágios. O agente de exemplo é um bot de suporte ao cliente construído com LangGraph: ele classifica mensagens, escala clientes insatisfeitos e responde os demais usando três ferramentas. As chamadas de modelo já passam pelo Amazon Bedrock desde o início — mas isso, como o próprio guia destaca, não é a vantagem que parece.

O que o AgentCore cobre — e o que continua sendo seu

Antes de entrar nos estágios, o guia faz questão de ser claro sobre o escopo do AgentCore. Ele é descrito como uma plataforma para construir, conectar e otimizar agentes em escala, com qualquer framework ou modelo. Mas ele não elimina tudo:

• Runtime assume o compute: patching de sistema operacional, auto scaling e isolamento de sessão deixam de ser sua responsabilidade.
• Gateway assume a autenticação das ferramentas e as publica como ferramentas Protocolo de Contexto de Modelo (MCP — Model Context Protocol).
• Memory assume o estado da conversa, tornando-o durável entre turnos, processos e dias.

O que continua sendo responsabilidade da equipe: configuração de Rede Virtual Privada (VPC — Virtual Private Cloud), regras de Firewall de Aplicação Web (WAF — Web Application Firewall), políticas de Gerenciamento de Identidade e Acesso (IAM — Identity and Access Management), rotação de segredos e atualizações de dependências (estas últimas só saem do seu escopo no Estágio 3).

Estágio 0: o agente que você já tem

Antes de mover qualquer coisa, o guia recomenda registrar uma linha de base: quais ferramentas foram executadas e qual foi a mensagem final do estado do grafo. Isso transforma o próximo estágio em uma comparação objetiva, não em uma aposta.

O agente do exemplo usa ChatBedrockConverse como modelo, um MemorySaver com thread_id como checkpointer, e três ferramentas (lookup_order, process_return e search_faq) como funções @tool. O roteamento é feito por um nó classify_intent com uma função Python determinística.

O único problema real nesse estágio é o estado: um dicionário em memória morre com o processo, e duas réplicas não conseguem ver as conversas uma da outra. Tudo o mais funciona bem em escala de produção — mas esse ponto não.

Para quem chega de OpenAI ou Anthropic direto, a única mudança necessária neste estágio é trocar o construtor do modelo pelo ChatBedrockConverse, passando o ID do modelo e a região AWS. A lista de modelos disponíveis por região pode ser consultada na documentação de modelos suportados por região no Amazon Bedrock.

Estágio 1: o mesmo agente, migrado

O Estágio 1 move cinco das dez cargas operacionais sem alterar o comportamento do agente. Três coisas mudam: o Runtime assume o processo, duas das três ferramentas vão para o Gateway, e o estado da conversa passa para o Memory.

Runtime: hospedando o loop

O loop existente é envolvido por BedrockAgentCoreApp com um entrypoint decorado. O thread_id que antes era escolhido manualmente agora chega como context.session_id do RequestContext que o Runtime injeta. O guia faz um alerta importante: construa o grafo uma vez e mantenha-o, porque reconstruir por requisição pode derrubar a sessão MCP das ferramentas.

from bedrock_agentcore import BedrockAgentCoreApp
from langchain_core.messages import HumanMessage

app = BedrockAgentCoreApp()

@app.entrypoint
def agent_invocation(payload, context):
    state = support_graph().invoke(
        {"messages": [HumanMessage(payload.get("prompt", ""))]},
        config={"configurable": {"thread_id": context.session_id or "local-session"}},
    )
    return {"result": state["messages"][-1].text}

if __name__ == "__main__":
    app.run()

O mesmo wrapper funciona com loops CrewAI, LlamaIndex ou qualquer outro: aceite um dicionário de payload, invoque, retorne um dicionário.

Gateway: publicando ferramentas como MCP

O motivo de colocar uma ferramenta atrás de um gateway é o que vem junto: a autenticação sai do seu código e a ferramenta publicada passa a ser acessível por outros agentes futuros, não apenas pelo agente atual.

lookup_order e process_return são publicadas como ferramentas MCP pelo AgentCore Gateway a partir de uma função Lambda. A criação é feita com duas chamadas no cliente bedrock-agentcore-control: uma para criar o gateway (escolhendo o tipo de autorizador — AWS_IAM ou CUSTOM_JWT) e outra para registrar o target apontando para a função Lambda com o schema JSON das ferramentas.

client = boto3.client("bedrock-agentcore-control", region_name=region)
gateway = client.create_gateway(
    name="MigratedAgentGateway",
    roleArn=role_arn,
    protocolType="MCP",
    authorizerType="AWS_IAM",
)
gateway_id = gateway["gatewayId"]
gateway_url = gateway["gatewayUrl"]

As ferramentas descobertas chegam prefixadas com o nome do target e três underscores: lookup_order vira supportTools___lookup_order. search_faq permanece como função Python local em todos os estágios — e o guia deixa claro que esse é o caso normal, não um compromisso. Uma ferramenta que nenhum outro agente precisa e nenhuma política controla não tem nada a ganhar com a migração para o Gateway.

Memory: estado que sobrevive ao processo

O MemorySaver do Estágio 0 é substituído por um checkpointer respaldado pelo AgentCore Memory, identificado por actor_id e sessão. O checkpointer já vem como dependência instalada (langgraph-checkpoint-aws) e não precisa de código customizado:

from langgraph_checkpoint_aws import AgentCoreMemorySaver
graph = build_graph(
    llm=llm,
    tools=tools,
    checkpointer=AgentCoreMemorySaver(memory_id, region_name=region),
)
state = graph.invoke(
    {"messages": [HumanMessage(prompt)]},
    config={"configurable": {"thread_id": session_id, "actor_id": actor_id}},
)

O guia recomenda testar a durabilidade explicitamente: um segundo processo, compartilhando apenas os IDs de memória, actor e sessão, deve conseguir responder sobre uma conversa que nunca foi carregada localmente.

Deploy e armadilhas comuns

O deploy usa uma codeConfiguration: um zip do código-fonte no Amazon S3 com as dependências vendorizadas ao lado. Sem container, sem Amazon Elastic Container Registry (ECR — Elastic Container Registry), sem Docker. Mas há duas armadilhas que custam tempo real:

• Wheels de plataforma errada: o Runtime roda em ARM64 Linux. Instale as dependências para o target correto: --platform manylinux2014_aarch64 --python-version 3.12 --only-binary=:all:
• Dependência faltando no zip: um requirements.txt dentro do zip é inerte. O arquivo é o ambiente finalizado. Se uma dependência falta, o erro aparece como timeout de inicialização do Runtime, não como ModuleNotFoundError.

Estágio 2: reconstruindo o loop por escolha

O Estágio 2 não move cargas operacionais — ele muda quem decide o próximo passo. Faz sentido quando o roteamento escrito à mão (route_intent) se torna o gargalo: cada nova intenção exige um novo nó no grafo em vez de uma linha no prompt.

Com Strands Agents, o planejamento passa para o modelo. O add_conditional_edges não tem equivalente — e o guia é explícito sobre o trade-off: o branch determinístico e auditável é trocado por um planejamento que não é nem um nem outro.

O gerenciamento de memória colapsa em um objeto de configuração e um argumento de construtor, reutilizando o Gateway, o target e o Memory store do Estágio 1:

config = AgentCoreMemoryConfig(
    memory_id=memory_id,
    session_id=session_id,
    actor_id=actor_id
)
kwargs["session_manager"] = AgentCoreMemorySessionManager(
    config, region_name=region_name
)
return Agent(**kwargs)

Policy: decisão determinística de volta em cada chamada de ferramenta

Para compensar a perda do branch auditável, a Policy do Amazon Bedrock AgentCore coloca uma decisão determinística na frente de cada chamada de ferramenta via Gateway, usando regras Cedar avaliadas no plano de dados — em um caminho que a aplicação não consegue contornar. Um guardrail na saída do modelo não está nesse caminho; quando ele roda, a chamada já aconteceu.

O exemplo do guia usa duas regras: uma identidade somente-leitura pode chamar lookup_order; uma identidade privilegiada pode também chamar process_return. Cedar é default-deny — a recusa do caller somente-leitura é simplesmente a ausência de uma regra permit correspondente.

Estágio 3: entregando o loop

O Estágio 3 é documentado no guia, mas não construído no walkthrough. Um AgentCore harness executa o loop por você, alimentado por Strands Agents. O agente é declarado como configuração (modelo, prompt de sistema, ferramentas, memória e limites) e a AWS o executa — trocar de modelo vira uma mudança de configuração, não um redeploy.

O pré-requisito é que o agente já seja um loop orientado a modelo (não um grafo), o que significa que o Estágio 2 precede obrigatoriamente o Estágio 3. É o único ponto do guia onde a ordem recomendada é também a única ordem possível. Seis das dez cargas operacionais se movem aqui — e atualização de dependências é a única que só sai do seu escopo neste estágio.

Armadilhas comuns de migração

O guia fecha com três padrões que custam mais tempo às equipes após a migração:

1. Assumir paridade de comportamento

O agente não vai se comportar de forma idêntica após a migração, e sem critérios acordados antes da mudança, qualquer diferença de redação vira uma discussão sem fim. A recomendação é definir critérios de aceitação baseados em resultados, não em implementação — e usar o AgentCore Evaluations para testá-los.

2. Manter estado no processo

Uma sessão não é uma invocação: ela contém múltiplas invocações, e o Runtime encerra o ambiente de execução após 15 minutos de inatividade por padrão, provisionando um novo para a mesma sessão. Esse timeout é configurável via idleRuntimeSessionTimeout (de 60 segundos a 8 horas), mas ajustá-lo move o prazo — não o elimina. A sessão sobrevive; o estado em memória, não.

3. Subestimar a arquitetura de autenticação

Lacunas de autenticação custam retrabalho, não configuração. Mapeie primeiro todos os fluxos: como o agente se autentica em APIs externas, como usuários se autenticam no agente, como as permissões são escopadas. O AgentCore Identity responde à primeira questão, referenciado no target do gateway no lugar de GATEWAY_IAM_ROLE.

Pré-requisitos para seguir o walkthrough

Para reproduzir o guia, são necessários: uma conta AWS com acesso ao Amazon Bedrock habilitado, Python 3.12 e a Interface de Linha de Comando AWS (AWS CLI) configurada com credenciais para criar recursos de AgentCore, Lambda, Amazon S3 e IAM. Também é necessário habilitar o CloudWatch Transaction Search uma vez na conta — sem isso, os traces gerados não podem ser visualizados.

O repositório de exemplo está organizado por estágio, permitindo comparar cada um com o anterior. O setup cria um ambiente virtual e instala sete dependências com um único script.

Conclusão

O Estágio 1 é um ponto de parada válido: você mantém a orquestração em que confia, em compute gerenciado, com ferramentas gerenciadas e estado durável. O Estágio 2 é outro ponto de parada, para agentes onde o roteamento escrito à mão virou o gargalo. O Estágio 3 tira o loop do seu codebase.

O guia também destaca que nenhuma dessas migrações precisa ser feita duas vezes: as features do AgentCore se encaixam como um argumento de keyword para as ferramentas do gateway, uma dependência pinada para o checkpointer, um objeto de configuração para o session manager e um arquivo de regras Cedar para a Policy.

Para aprofundamento, a AWS recomenda clonar o repositório de exemplo, ler a comparação de arquitetura de segurança e consultar a documentação do Amazon Bedrock AgentCore.

Fonte

Migrate agentic workloads to Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/migrate-agentic-workloads-to-amazon-bedrock-agentcore/)

E-mail, IA e tempo perdido

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

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

O que é o Amazon Quick

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

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

Visão geral da solução

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

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

Pré-requisitos para a integração

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

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

Passo a passo da configuração

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

Etapa 1: Adicionar o conector do Microsoft Outlook

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

Etapa 2: Autorizar a integração

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

Etapa 3: Autorizar o acesso do Amazon Quick ao Outlook

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

Etapa 4: Verificar o status da conexão

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

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

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

Casos de uso por ferramenta

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

Quick Chat Agents

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

Quick Flows

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

Quick Automate

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

Recursos adicionais

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

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

Fonte

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

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

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

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

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

O processo importa mais do que a tecnologia

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

Qualidade do processo determina qualidade do agente

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

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

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

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

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

Projete agentes com responsabilidades claras e delimitadas

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

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

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

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

Combine agentes com etapas determinísticas

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

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

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

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

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

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

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

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

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

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

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

Avalie seus workflows agênticos

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

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

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

Construa observabilidade na automação

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

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

Gerencie identidade e acesso com cuidado

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

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

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

Conclusão

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

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

Fonte

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

Disponibilidade expandida das instâncias P6-B300

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

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

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

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

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

Por que isso importa para cargas de trabalho de IA?

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

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

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

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

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

Saiba mais

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

Fonte

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

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

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

O que torna as instâncias P6-B200 especiais

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

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

Escalabilidade segura com o AWS Nitro System

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

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

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

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

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

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

Saiba mais

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

Fonte

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

O problema que o AgentCore resolve na prática

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

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

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

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

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

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

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

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

Desafio de negócio

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

Arquitetura da Solução 1

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

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

Detalhes de implementação

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

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

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

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

As principais decisões de design incluem:

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

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

Solução 2: handoffs seguros de software

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

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

Desafio de negócio

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

Arquitetura da Solução 2

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

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

Capacidades principais

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

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

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

Detalhes de implementação

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

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

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

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

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

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

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

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

Kiro

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

OpenAI ChatGPT Codex

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

Claude Code

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

O fluxo combinado

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

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

Boas práticas

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

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

Conclusão

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

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

Fonte

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

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

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

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

Cada modelo tem um perfil de uso bem definido:

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

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

Perfis de inferência global GPT-5.6

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

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

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

Pré-requisitos

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

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

Verificando os perfis de inferência ativos

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

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

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

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

Via console do Amazon Bedrock

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

Invocando o GPT-5.6 pelo Amazon Bedrock Runtime

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

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

OpenAI Responses API

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

from aws_bedrock_token_generator import provide_token
from openai import OpenAI

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

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

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

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

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

OpenAI Chat Completions API

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

from aws_bedrock_token_generator import provide_token
from openai import OpenAI

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

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

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

Amazon Bedrock Converse API

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

import boto3

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

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

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

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

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

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

Trabalhando com cache de prompts

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

Configurando o Codex com GPT-5.6 no Amazon Bedrock

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

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

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

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

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

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

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

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

Gerenciamento de cotas

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

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

Monitoramento e registro de logs

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

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

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

[otel]
environment = "production"

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

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

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

Conclusão

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

Fonte

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

O problema que toda equipe de suporte conhece

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

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

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

A solução em duas camadas

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

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

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

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

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

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

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

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

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

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

1.2 Analisador de chamados com RAG

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

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

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

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

1.3 Inteligência de fluxo de valor

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

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

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

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

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

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

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

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

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

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

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

2.3 Experiência agêntica incorporada

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

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

Resultados mensuráveis

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

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

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

Fonte

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