Isolation remains the central promise
AWS has released a next-generation runtime for Amazon Bedrock AgentCore, targeting the infrastructure problems that appear when AI agents move from demonstrations to long-running production work. Every session continues to run inside its own hardware-isolated Firecracker MicroVM with a distinct identity, policy and audit trail. AWS says the updated runtime starts sessions up to 15 times faster, supports four times more compute and can use memory up to 68 per cent more efficiently without weakening that isolation model.
The release matters because agent workloads do not behave like ordinary request-response APIs. A coding agent may compile a repository, a browser agent may hold state across many pages, and an operational agent may pause while waiting for a model, a tool or a person. Pre-provisioned pools reduce latency but waste capacity, while on-demand sandboxes can make every task feel slow. AgentCore is AWS’s attempt to make an isolated session the default unit of execution without forcing platform teams to operate the sandbox fleet themselves.
AWS now supports sessions with up to eight vCPUs and 32 GB of memory, plus container images as large as 10 GB. It says sessions start in under two seconds regardless of image size or concurrency. That expands the practical range from lightweight tool orchestration to code compilation, browser work and some local inference. Buyers should still benchmark their own image initialisation, dependency loading and regional concurrency because a platform headline does not describe end-to-end time before an agent produces useful work.
More compute without warm pools
Removing the need for warm pools can simplify operations significantly. Teams no longer have to predict agent demand, keep clusters idle for a latency target or build their own process for destroying a compromised session. The MicroVM boundary also gives each task a separate identity and policy. That is valuable when an agent executes untrusted code, but it is not a complete security system: the tools, outbound network paths and credentials made available inside the session remain the organisation’s responsibility.
The new runtime reclaims memory after an agent releases it and can scale an idle session to zero. AWS says this can reduce memory consumption by up to 68 per cent for multi-turn agents that spend time waiting. Always-on agents can use a committed baseline with capacity to burst to four times that level. The commercial idea is sound: billing should reflect actual work rather than pauses. Cost testing should include model calls, storage, networking and tools, not just runtime memory.
Usage-aligned infrastructure also changes how developers should write agents. A process that holds unnecessary state or leaks memory will now have a measurable cost signature. Teams should instrument session duration, active compute, waiting time and retries, then relate those measures to completed outcomes. An agent that starts quickly but repeatedly re-runs a failed tool can be more expensive than a slower deterministic workflow. FinOps needs task-level evidence rather than a monthly aggregate for the entire agent platform.
Billing follows active work more closely
AWS has extended the isolation concept to working data. A session can dynamically mount and save work to a filesystem such as Amazon S3 through FUSE. This reduces the need for ad hoc copying of files, credentials and tool outputs across the execution boundary. The data remains governed by the session identity and access policy while the job runs. AWS plans per-session folder scoping through session-labelled credentials, which will make the storage boundary more granular.
Mounted storage brings its own design questions. An ephemeral compute environment can still leave durable data behind, so retention, encryption, versioning and deletion policies must be explicit. Agents should not receive access to an entire bucket because one task needs a folder. Teams also need to test partial writes, revoked access and concurrent sessions attempting to update the same artefact. The audit trail should connect every stored object with the agent session and the human or service that initiated it.
Migration should be controlled rather than automatic. Run representative agents on both runtime generations, holding models and tools constant, then compare cold starts, memory, cost, completion quality and failure recovery. Security teams should repeat network and identity tests because a more efficient runtime can change timing and concurrency assumptions. Operational playbooks need to cover session termination, evidence preservation and what happens when storage or a downstream tool is unavailable.
Data joins compute inside the boundary
The next-generation AgentCore runtime strengthens AWS’s pitch that production agents need a purpose-built managed execution layer, not only access to foundation models. Faster starts and larger sessions are immediately useful, but the durable advantage will be whether isolation, identity, storage and billing remain understandable at scale. Australian teams should confirm regional availability and data paths for every connected service rather than assume the runtime location governs the whole workflow. Organisations should treat the runtime as a security and operations boundary with measurable service objectives. That discipline turns infrastructure improvements into safer autonomy instead of simply enabling agents to run more code faster.