ADR: Scaling Agents to Production with AgentCore Runtime Quotas

Since Amazon Bedrock AgentCore launched, I've been closely tracking how financial engineering teams try to fit AI agents into workflows that demand auditability, controlled latency, and fault isolation. The recurring problem wasn't model capability — it was runtime infrastructure. Conservative session limits forced workaround architectures: SQS queues to serialize agent calls, Step Functions to manage session lifecycles outside the platform, and manual retry logic that duplicated what AgentCore itself should provide.

The July 1, 2026 announcement changes that calculus. With 5,000 active concurrent sessions in us-east-1 and us-west-2, and 2,500 in other supported regions, AgentCore becomes viable as a primary runtime for use cases that previously required hybrid solutions. The 200 agent interactions per second and 25 new sessions per second as defaults — without requiring a quota increase request — eliminate an entire category of operational friction when onboarding new workloads.

But raising the default ceiling doesn't solve the design problems that emerge when you actually use that capacity. In financial environments, every agent session carries sensitive context: customer data, transaction state, decision history. Horizontal session scaling amplifies the attack surface, observability complexity, and cost risk. The technical signal here isn't 'use more agents' — it's 'now you need a serious session control architecture'.

When you read '5,000 concurrent sessions', the first engineering reaction is: 'great, I can scale'. The second reaction — the one that matters — should be: 'what happens when I'm at 4,800 sessions and a burst of 300 simultaneous users tries to create new sessions at 25/s?'

The 25 new sessions per second limit is the real bottleneck in this architecture. In a financial system with market peaks — exchange open, settlement windows, credit events — the session creation rate can exceed this limit even with abundant headroom in the active session pool. This demands a session pre-warming pattern: creating sessions in advance and holding them in a managed pool, reusing them for incoming requests rather than creating a new session per user interaction.

The second pressure vector is context isolation. With 5,000 active sessions, each potentially carrying customer context in runtime memory, the question of where session state lives becomes critical. AgentCore manages session state internally, but for regulatory audit purposes in financial environments, you need an external, immutable audit trail. This means integrating AgentCore with DynamoDB (for projected session state with TTL and partition key on customerId#sessionId) and S3 with Object Lock for agent decision logs.

The third vector is cost. At 200 interactions/s sustained, with each interaction invoking a Bedrock model (Claude, Titan, or otherwise), token costs can scale non-linearly. Without per-session circuit breakers and without per-interaction token limits configured explicitly, a poorly instructed agent can consume a week's budget in hours.

For financial systems operating AgentCore in production, the decision I advocate is Option B with elements of Option C: a pre-warmed session pool managed by Lambda with admission control, combined with Step Functions orchestration for flows requiring approval or regulatory audit.

The reasoning is direct: the 25 new sessions/s limit is the only bottleneck that cannot be resolved with more runtime capacity — it is an API rate limit, not a compute capacity limit. Pre-warming transforms this limit from a burst bottleneck into a capacity planning parameter. With a Lambda scheduled every 5 minutes checking the pool and creating sessions up to a configurable target (say, 200 ready sessions), you absorb bursts of up to 200 simultaneous users without touching the creation limit.

For admission control, I use a DynamoDB table with partition key poolId and sort key sessionId, with a status attribute (AVAILABLE | IN_USE | DRAINING) and 30-minute TTL. A dispatcher Lambda performs a conditional UpdateItem with ConditionExpression: attribute_exists(sessionId) AND #status = :available — this ensures two concurrent dispatchers never assign the same session. Idempotency is guaranteed by the correlationId from the original request, stored as a session attribute.

For audit, every agent interaction — input, output, tools invoked, tokens consumed — is published to a Kinesis Data Firehose stream with S3 destination with Object Lock (COMPLIANCE mode, 7 years for Brazilian financial regulation). The KMS key policy restricts kms:Decrypt to audit roles with condition aws:PrincipalTag/Role: AuditReader, preventing the main application from accessing its own audit logs.

With 5,000 potentially active sessions, observability cannot be reactive — you need SLOs defined before going to production. The three signals I instrument in any financial-scale AgentCore deployment are:

1. Pool Utilization Ratio: sessions_in_use / pool_target. Alarm at 80% — not 100%. At 80%, the warmer Lambda should be triggered immediately to create additional sessions. If you wait for 100%, you're already rejecting requests. In CloudWatch, this is a custom metric published by the dispatcher with PoolId and Region dimensions, with an alarm action invoking the warmer via SNS.

2. Session Creation Lag: time between a new session request and the session being available for use. Under normal conditions with pre-warming, this should be zero (session already available in pool). If it starts rising, it indicates the warmer isn't keeping pace — or the 25 sessions/s limit is being hit. A CloudWatch Metric Math of p99(session_allocation_latency) above 500ms should fire a capacity alarm.

3. Token Budget Exhaustion Rate: percentage of interactions that hit the configured per-session token limit. In financial systems, an agent exhausting its token budget is likely in a loop or received an adversarial prompt. This signal should trigger both an operational alarm and a security event — correlated to sessionId and customerId for investigation.

For distributed correlation, I inject the original request's correlationId as an AgentCore session attribute and as a field in all Firehose events. This allows tracing a user interaction from API Gateway to the S3 audit log, through all model invocations — essential for compliance investigations.

The AgentCore quota increase arrives at a moment when global financial regulators — including Brazil's Central Bank with its AI guidelines for financial institutions, and DORA in Europe — are formalizing requirements for AI systems in production. Scaling agents to 5,000 concurrent sessions without a corresponding governance strategy is a regulatory risk, not just a technical one.

The three governance requirements every AgentCore deployment in a financial environment must address are: decision explainability, granular access control, and adversarial testability.

For explainability, recording each agent interaction in Firehose/S3 is not sufficient — you need to record why the agent made each decision: which tools it considered, which it discarded, what the intermediate reasoning was. This requires configuring AgentCore with enableTrace: true and capturing trace events, not just the final output. In a BACEN audit, 'the model decided' is not an acceptable answer.

For access control, each AgentCore session must be associated with a verified end-user identity — not just the application's IAM role. This means propagating the sub from the user's JWT token as a session attribute and using that attribute in tool authorization policies within the agent. An agent that can invoke any tool for any user is a violation of least-privilege at the runtime level.

For adversarial testability, with 200 interactions/s available, you have capacity to run automated red team tests in staging without impacting production. Implement a CI/CD pipeline that executes a known set of adversarial prompts against each new agent instruction version before deployment — and block the deploy if the inadequate response rate exceeds a defined threshold.