Amazon Web Services announced the new AgentCore runtime on September 18, 2026, a reworked version of the managed compute layer in Amazon Bedrock AgentCore that the company says reclaims memory as agent sessions release it and delivers consistent cold start times regardless of container image size or concurrency.
AgentCore runtime is the managed compute layer that gives developers a fully managed environment to deploy and run agents without building or maintaining infrastructure. AWS said thousands of teams have used it to run production agents since launch, and that the first version established a serverless foundation with session isolation, scale-to-zero behavior, and pay-per-use pricing. That consumption model carries over: billing follows resource usage with no charge for idle CPU waiting on I/O, and the platform scales all the way down to zero when an agent has no work.
The Problems the Launch Addresses
In the original runtime, a session held its allocated memory from the moment of allocation until the session ended, because nothing reclaimed it along the way. AWS said that left long-running or bursty agents paying for their high-water mark around the clock, well after the memory had stopped being used, a particular gap for agents that spike occasionally but sit idle most of the day.
Startup behavior was the second challenge. AWS said a session that lands on an already-initialized environment starts in under 100 milliseconds, but keeping environments warm enough to guarantee that means holding compute in reserve, so most sessions begin with a cold start that boots a fresh environment, pulls the image, and initializes the agent before the first request runs. That latency grows with image size and concurrency and is worst under bursty traffic, when the most sessions arrive and the fewest ready environments remain. According to AWS, customers worked around both issues by holding spare environments ready, optimizing memory allocation, and tearing capacity down to keep costs in check.
What AWS Measured
To isolate what the platform itself adds to a cold start, AWS tested an empty echo agent that returns its input and calls no model and no tools. A Python client on an Amazon EC2 instance in us-west-2 invoked agents in us-east-1 over the public internet with no VPC peering, using the boto3 SDK, so each client-side measurement includes the round trip between the two AWS Regions on top of the platform’s own start time. The company sent 5,000 cold invocations per agent across both runtime versions and five image sizes, within default account quotas.
Measured that way, AWS reported that the new runtime delivered a P75 cold start latency of about 2 seconds from a 200 MB image up to 2 GB, because image size has no effect on it, while the original runtime’s latency rose with image size from roughly 5.4 seconds to nearly 30 seconds. In the echo test, the agent’s own code ran in about 34 milliseconds at P75, so nearly all of the measured time was platform start time. AWS suggests hiding start time for interactive agents by beginning the session as soon as a user engages, such as when they open a chat, so the environment warms while they type a first request.
How the New Runtime Works
The new runtime starts each session from a small memory profile rather than a fully provisioned footprint, then allocates and pages in additional memory on demand as the workload touches it. When an agent releases per-request buffers or lets cached data expire between requests, the platform takes the memory back instead of letting it stay claimed until the session ends. AWS said it tuned the reclamation behavior based on an analysis of allocation patterns across billions of sessions.
Cold starts change because each agent loads once and then runs from a snapshot. When a runtime is created or updated, AgentCore launches the container, waits for it to report healthy, and captures a snapshot of the running environment, so one-time initialization such as loading model artifacts and fetching static configuration is already done. Every new instance restores that snapshot instead of initializing from scratch. AWS said the runtime strips caches and transient memory from the snapshot so its size stays roughly flat as the container image grows, which holds restore latency steady across a wide range of image sizes.
Billing shifts with the memory model. The new runtime charges for the memory an agent actively uses, loaded on demand and reclaimed when idle, rather than for holding the whole container image in memory for the life of a session. AWS characterized the change as a higher rate applied to far fewer GB-hours, and said that for most agents the footprint drops more than the rate rises, so the bill goes down.
Platform Versions, Regions, and Limits
Developers turn the new runtime on by setting the platformVersion field to V2 when creating or updating a runtime, according to the AgentCore Developer Guide. V1 is the default: omitting the field at creation produces a V1 runtime, and omitting it on an update keeps the runtime’s current platform version. V2 is available in us-east-1, us-east-2, us-west-2, eu-west-1, and ap-northeast-1.
Because a V2 create or update prepares and snapshots the environment, those operations run for several minutes before the runtime reaches READY, where a V1 runtime becomes ready in seconds. AgentCore takes the snapshot on the first healthy response from the container’s /ping endpoint, and if the container does not report healthy within 120 seconds of startup, creation fails with a health check error. The guide also states that V2 currently caps total environment-variable size at 1.5 KB for direct code deployments and 2.5 KB for container agents, compared with 4 KB on V1, and that AWS CloudFormation and the AWS CDK do not currently support setting platformVersion.
Snapshots follow the runtime’s versions and endpoints rather than being managed directly. AgentCore prepares a snapshot when an endpoint points to a version and deletes one when no endpoint points to it, and deletion can take up to 8 hours, the maximum session lifetime, because sessions already running on the snapshot continue until they end. Sessions run in dedicated microVMs with isolated CPU, memory, and filesystem resources, persist for up to 8 hours, and terminate after 15 minutes of inactivity, after which the microVM is terminated and memory is sanitized.
Roadmap and Getting Started
Beyond the launch, AWS listed several capabilities on the way: committed baseline discounts that reserve a memory floor per session with on-demand bursting above it, aimed at steady always-active sessions; larger RAM, vCPU, and session storage; x86 microVM support; suspend-and-resume with memory snapshotting plus runtime hooks for serializing state before an active session terminates; and session context keys that give each session a scoped identity for unattended agents.
AWS pointed developers to the AgentCore Developer Guide, the AgentCore samples repository on GitHub, and an accompanying load test example that demonstrates the new runtime’s cold start latency inside a user’s own AWS account.
