The managed runtime gets a new version
AWS has released a new version of Amazon Bedrock AgentCore Runtime, the managed compute layer used to run AI agents. Its AWS announcement, dated 18 September, names two principal changes: memory can be returned as a session stops using it, and a prepared environment can be restored quickly for a new instance. Developers opt in by setting platformVersion to V2 when creating or updating a runtime.
This is a deployment change, not a new model. An agent can be capable on paper and still feel unreliable if it waits too long to start, holds expensive resources after a burst or scales poorly when many sessions arrive together. AgentCore’s update addresses those operational frictions while retaining a serverless model that does not require customers to pre-provision capacity.
Memory follows actual use more closely
The previous runtime could keep memory assigned after an agent had finished a high-memory part of its session. V2 starts with a smaller resident footprint, allocates more when the workload touches it and reclaims memory that is no longer actively used. AWS says billing can therefore track real use rather than the peak retained for the whole session.
That distinction matters for an agent with uneven work. It might load a document, create a temporary representation, call a model and then wait for a person to approve the next step. Paying as though the largest intermediate object remained live throughout would distort the economics of a long session. Reclamation may reduce that cost, although the magnitude depends on how the application allocates and releases memory.
Developers should not assume the platform can reclaim data the application still references. Profiling remains valuable: measure memory over a full representative session, including idle periods and failure paths. If a process caches large objects indefinitely, a more elastic runtime alone will not correct the design.
A snapshot changes start-up behaviour
For cold starts, AWS says the runtime launches a container, waits until it is healthy and then captures a snapshot. New instances restore that prepared state rather than repeating one-time initialisation. The company reports P75 cold-start times between 1.9 and 2.0 seconds for images from 200 MB to 2 GB in its tests, compared with 5.4 to 30 seconds on V1.
Those are vendor test results, not a universal service-level promise. A real agent may connect to external systems, load different dependencies or do work after restoration that the benchmark’s simple test did not include. A production evaluation should measure user-visible time to first useful action, not just the moment an instance starts.
Snapshotting also makes initialisation behaviour more important. Teams should check which secrets, configuration values and network connections are established before the snapshot, and which should instead be refreshed per session. Correctness and isolation come before shaving seconds from a start-up graph.
What to measure before switching
The most useful comparison is a production-shaped load test. Run short interactive sessions, longer tool-using sessions and simultaneous starts. Measure P50 and P75 time to first action, memory through each stage and the total bill over a full work cycle. A snapshot improvement may be especially visible after idle periods, while memory savings may matter most in extended sessions.
Correctness checks should run alongside performance checks. Verify that per-session credentials remain isolated, that updated configuration takes effect when expected and that a failed tool call leaves no ambiguous state. Those are operational requirements for an agent handling real work, not optional extras to revisit after a speed test.
A comparison should include the older runtime as a control, using the same image, workload and region. It should record warm starts separately from cold starts. Otherwise, an apparent improvement may simply reflect a different traffic pattern. Teams also need to examine pricing under sustained load, because lower memory use does not necessarily make every deployment cheaper.
Regional and migration limits
AWS lists five initial regions: US East in Northern Virginia and Ohio, US West in Oregon, Europe in Ireland, and Asia Pacific in Tokyo. An Australian region is not named in the announcement. Australian organisations should check routing and data-location requirements before treating the update as locally available.
The release retains hardware-enforced session isolation, scale to zero and pay-for-use characteristics, according to AWS. Existing runtimes do not become V2 merely because the announcement has been published; the platform version must be selected. Teams should use a staged rollout, compare identical traffic and keep a clear rollback path if an agent’s dependencies behave differently after snapshot restoration.
The immediate value of the announcement is operational choice. V2 offers a way to run the same style of managed agent with potentially lower idle-memory cost and more predictable starts. The decision to migrate should follow measured latency, memory, price and correctness under each team’s own workload, not the benchmark alone.