ADR: Escalando Agentes em Produção com AgentCore Runtime Quotas

Desde o lançamento do Amazon Bedrock AgentCore, tenho acompanhado de perto como equipes de engenharia financeira tentam encaixar agentes de IA em fluxos de trabalho que exigem auditabilidade, latência controlada e isolamento de falhas. O problema recorrente não era a capacidade do modelo, era a infraestrutura de runtime. Limites conservadores de sessão forçavam arquiteturas de contorno: filas SQS para serializar chamadas de agente, Step Functions para gerenciar ciclos de vida de sessão fora da plataforma, e lógica de retry manual que duplicava o que o próprio AgentCore deveria fornecer.

O anúncio de 1º de julho de 2026 muda esse cálculo. Com 5.000 sessões ativas simultâneas em us-east-1 e us-west-2, e 2.500 nas demais regiões suportadas, o AgentCore passa a ser viável como runtime primário para casos de uso que antes exigiam soluções híbridas. Os 200 agent interactions per second e os 25 new sessions per second como padrão, sem necessidade de solicitação de aumento, eliminam uma categoria inteira de atrito operacional no onboarding de novos workloads.

Mas elevar o teto padrão não resolve os problemas de design que surgem quando você realmente usa essa capacidade. Em ambientes financeiros, cada sessão de agente carrega contexto sensível: dados de cliente, estado de transação, histórico de decisão. A escala horizontal de sessões amplifica a superfície de ataque, a complexidade de observabilidade e os riscos de custo. O sinal técnico aqui não é 'use mais agentes', é 'agora você precisa de uma arquitetura de controle de sessão séria'.

Quando você lê '5.000 sessões simultâneas', a primeira reação de engenharia é: 'ótimo, posso escalar'. A segunda reação, a que importa, deveria ser: 'o que acontece quando eu chego em 4.800 sessões e um burst de 300 usuários simultâneos tenta criar novas sessões a 25/s?'

O limite de 25 novas sessões por segundo é o gargalo real nessa arquitetura. Em um sistema financeiro com picos de mercado, abertura de bolsa, janelas de liquidação, eventos de crédito, a taxa de criação de sessão pode exceder esse limite mesmo com headroom abundante no pool de sessões ativas. Isso exige um padrão de session pre-warming: criar sessões antecipadamente e mantê-las em um pool gerenciado, reutilizando-as para requisições entrantes em vez de criar uma nova sessão por interação de usuário.

O segundo vetor de pressão é o isolamento de contexto. Com 5.000 sessões ativas, cada uma potencialmente carregando contexto de cliente em memória de runtime, a questão de onde o estado de sessão vive torna-se crítica. O AgentCore gerencia o estado de sessão internamente, mas para fins de auditoria regulatória em ambientes financeiros, você precisa de uma trilha de auditoria externa e imutável. Isso significa integrar o AgentCore com DynamoDB (para estado de sessão projetado com TTL e partition key por customerId#sessionId) e S3 com Object Lock para logs de decisão de agente.

O terceiro vetor é custo. A 200 interações/s sustentadas, com cada interação invocando um modelo Bedrock (Claude, Titan, ou outro), os custos de token podem escalar não-linearmente. Sem circuit breakers por sessão e sem limites de token por interação configurados explicitamente, um agente mal instruído pode consumir orçamento de uma semana em horas.

Para sistemas financeiros operando com AgentCore em produção, a decisão que defendo é a Opção B com elementos da Opção C: um pool de sessões pré-aquecidas gerenciado por Lambda com controle de admissão, combinado com orquestração via Step Functions para fluxos que exigem aprovação ou auditoria regulatória.

O raciocínio é direto: o limite de 25 novas sessões/s é o único gargalo que não pode ser resolvido com mais capacidade de runtime, ele é um limite de taxa de API, não de capacidade de computação. Pre-warming transforma esse limite de um gargalo de burst em um parâmetro de planejamento de capacidade. Com um Lambda agendado a cada 5 minutos verificando o pool e criando sessões até um target configurável (digamos, 200 sessões prontas), você absorve bursts de até 200 usuários simultâneos sem tocar no limite de criação.

Para o controle de admissão, uso um DynamoDB com partition key poolId e sort key sessionId, com um atributo status (AVAILABLE | IN_USE | DRAINING) e TTL de 30 minutos. Uma Lambda de dispatcher faz um UpdateItem condicional com ConditionExpression: attribute_exists(sessionId) AND #status = :available, isso garante que dois dispatchers concorrentes nunca atribuam a mesma sessão. A idempotência é garantida pelo correlationId da requisição original, armazenado como atributo da sessão.

Para auditoria, cada interação de agente, entrada, saída, ferramentas invocadas, tokens consumidos, é publicada em um stream Kinesis Data Firehose com destino S3 com Object Lock (COMPLIANCE mode, 7 anos para regulação financeira brasileira). O KMS key policy restringe kms:Decrypt a roles de auditoria com condição aws:PrincipalTag/Role: AuditReader, impedindo que a aplicação principal acesse seus próprios logs de auditoria.

Com 5.000 sessões potencialmente ativas, a observabilidade não pode ser reativa, você precisa de SLOs definidos antes de ir para produção. Os três sinais que instrumentalizo em qualquer deployment AgentCore em escala financeira são:

1. Pool Utilization Ratio: sessions_in_use / pool_target. Alarme em 80%, não em 100%. A 80%, o warmer Lambda deve ser acionado imediatamente para criar sessões adicionais. Se você esperar 100%, já está rejeitando requisições. No CloudWatch, isso é uma métrica customizada publicada pelo dispatcher com dimensões PoolId e Region, com um alarm action que invoca o warmer via SNS.

2. Session Creation Lag: tempo entre a requisição de nova sessão e a sessão estar disponível para uso. Em condições normais com pre-warming, isso deve ser zero (sessão já disponível no pool). Se começar a subir, indica que o warmer não está mantendo o ritmo, ou que o limite de 25 sessões/s está sendo atingido. Um CloudWatch Metric Math de p99(session_allocation_latency) acima de 500ms deve disparar um alarme de capacidade.

3. Token Budget Exhaustion Rate: percentual de interações que atingiram o limite de tokens configurado por sessão. Em sistemas financeiros, um agente que esgota seu budget de tokens provavelmente está em um loop ou recebeu um prompt adversarial. Esse sinal deve acionar tanto um alarme operacional quanto um evento de segurança, com correlação ao sessionId e customerId para investigação.

Para correlação distribuída, injeto o correlationId da requisição original como atributo de sessão AgentCore e como campo em todos os eventos Firehose. Isso permite rastrear uma interação de usuário desde o API Gateway até o log de auditoria S3, passando por todas as invocações de modelo, essencial para investigações de compliance.

O aumento de cotas do AgentCore chega em um momento em que reguladores financeiros globais, incluindo o Banco Central do Brasil com suas diretrizes de IA para instituições financeiras, e o DORA na Europa, estão formalizando requisitos para sistemas de IA em produção. Escalar agentes para 5.000 sessões simultâneas sem uma estratégia de governança correspondente é um risco regulatório, não apenas técnico.

Os três requisitos de governança que todo deployment AgentCore em ambiente financeiro deve endereçar são: explicabilidade de decisão, controle de acesso granular e testabilidade adversarial.

Para explicabilidade, o registro de cada interação de agente no Firehose/S3 não é suficiente, você precisa registrar por que o agente tomou cada decisão: quais ferramentas considerou, quais descartou, qual foi o raciocínio intermediário. Isso requer configurar o AgentCore com enableTrace: true e capturar os trace events, não apenas o output final. Em uma auditoria do BACEN, 'o modelo decidiu' não é uma resposta aceitável.

Para controle de acesso, cada sessão AgentCore deve ser associada a uma identidade de usuário final verificada, não apenas à role IAM da aplicação. Isso significa propagar o sub do token JWT do usuário como atributo de sessão e usar esse atributo em políticas de autorização de ferramenta dentro do agente. Um agente que pode invocar qualquer ferramenta para qualquer usuário é uma violação do princípio de menor privilégio no nível de runtime.

Para testabilidade adversarial, com 200 interações/s disponíveis, você tem capacidade para rodar testes de red team automatizados em ambiente de staging sem impactar produção. Implemente um pipeline de CI/CD que executa um conjunto de prompts adversariais conhecidos contra cada nova versão de instrução de agente antes do deploy, e bloqueie o deploy se a taxa de resposta inadequada exceder um threshold definido.