2 seconds across 2 GB is not an agent latency result. Separate runtime start from model work.

AWS reported on 18 September that its new AgentCore Runtime V2 held P75 cold-start latency at about 2 seconds across container images from 200 MB to 2 GB. The comparison used 5,000 cold invocations per agent and an empty echo workload, so the number measures the runtime start path rather than an agent's end-to-end response.

That distinction is the useful part of the launch. A production agent can spend seconds on model calls, tools and orchestration after its environment is ready. Treating cold-start improvement as user-perceived latency hides the layer that actually owns the delay.

Benchmark the platform and the agent separately

AWS says the original runtime's cold-start latency rose from roughly 5.4 seconds to nearly 30 seconds as image size increased in its test. V2 instead prepares the environment once, snapshots it, and restores that prepared state for new instances. AWS documents the same platform behaviour: V2 restores snapshots so cold starts remain consistent regardless of image size or concurrency.

The test is deliberately narrow. The echo agent calls no model and no tools, and its own code ran in about 34 milliseconds at P75. That makes the experiment useful for isolating infrastructure overhead, but unsuitable as an application latency claim.

A faster runtime removes one latency component. It does not make the agent loop fast.

Memory economics now depend on the session shape

V2 also changes how memory is accounted for. Instead of holding a session's high-water mark until termination, AWS says memory is paged in as needed and reclaimed when it becomes cold or is released. That matters most for long-running or bursty agents whose peak footprint is a poor description of average use.

The deployment decision therefore needs workload traces, not just a container size. Teams should record memory over the full session, idle periods, resume frequency and concurrency bursts. A runtime that lowers GB-hours for a bursty agent may have a different economic result for a steady workload.

Put three clocks in the production SLO

For interactive agents, measure runtime start latency, time to first useful model output and total task completion separately. For long-running agents, add resume latency and memory GB-hours per completed task. AWS notes that sessions can preserve state across multiple invocations, so session affinity also belongs in the test: a client that loses its session identifier can create a new environment and reintroduce startup cost.

The practical migration gate is an A/B test on the real workload. Run V1 and V2 against the same traffic trace, capture percentile startup and end-to-end latency, then compare cost per completed task. If only the platform-start number improves, the next optimisation belongs higher in the agent stack.

Written by the Devence Lab research team.