Runtime and Memory — where the agent runs and what it remembers
Lesson 2 of 6 in Amazon Bedrock AgentCore, Service by Service.
Runtime is the serverless substrate. You hand it a container image and a framework of your choosing; it gives you an endpoint and a session model. The unit that matters is the session, identified by a runtimeSessionId — if the caller does not supply one, Runtime generates it on the first invocation.
Each session runs in its own dedicated microVM with isolated CPU, memory and filesystem. When the session ends, the entire microVM is destroyed and its memory sanitized. That is the architectural answer to a question every multi-tenant agent platform has to answer: what stops user B’s agent from reading the temp files user A’s agent just wrote? Not a namespace convention, not a prompt instruction — a discarded virtual machine.
Vignette. A tax-prep agent for a mid-size accounting firm. Each client engagement opens a session; the agent downloads statements, writes scratch CSVs, runs calculations for forty minutes, produces a summary, and the session closes. Two accountants working two clients at the same second get two microVMs. Nothing the first agent wrote to /tmp can leak into the second, because there is no shared /tmp to leak through.
Session lifecycle
A session is Active while it is doing work, Idle while it waits for the next invocation, and Terminated when it is gone. As of September 2026 the documented defaults are termination after 15 minutes of inactivity and a maximum lifetime of 8 hours.
The subtlety: a long-running background task would otherwise look like inactivity. Runtime resolves this through the health check — a session that reports HealthyBusy stays Active while it grinds. So "8 hours" is not a request timeout you must beat; it is the ceiling on one continuous session.
Treat both numbers as current defaults, not laws. Check AgentCore Runtime Service Quotas before you design around them.
microVM vs Instances
Two substrates, same session concept.
microVM sessions are the default: serverless, per-session isolation, up to 8 hours, nothing to manage.
Runtime Instances (GA August 2026) run sessions on isolated EC2 instances from a capacity provider — including GPU-accelerated, memory-optimized and compute-optimized families — with sessions up to 14 days and persistent volumes that survive a stop and re-attach on resume under the same runtimeSessionId. Deleting the session deprovisions the volume. You pay managed-compute charges in addition to EC2 costs.
Choose Instances when the agent needs a working directory that outlives a pause, a GPU, or a lifetime measured in days — a research agent maintaining a checked-out monorepo, say. Choose microVMs for everything else.
Long-running and async work
Runtime exposes two invocation shapes against the same session: InvokeAgentRuntime for agent reasoning, and InvokeAgentRuntimeCommand for deterministic shell commands. That pairing matters more than it looks — it lets your control plane run a scripted git clone or pytest in the same isolated environment the model is reasoning about, without asking the model to do it.
Bidirectional streaming arrived in December 2025, and Runtime supports A2A as well as MCP, so an AgentCore-hosted agent can be addressed as a peer agent rather than only as an HTTP endpoint.
AWS marketing calls the 8-hour window "industry-leading". Ignore the adjective; the number is the useful part.
Memory is the durable half. It offers two memory types, and the distinction is not "small and big" — it is raw versus distilled.
Short-term memory stores raw interaction events: messages, tool calls, results. It is the in-session transcript, written and read immediately.
Long-term memory stores insights extracted across sessions — user preferences, semantic facts, summaries — retrieved later by semantic search. Extraction is driven by configurable memory strategies, and this is the fact that trips people up: without a strategy configured, a Memory resource only stores short-term events. Long-term memory is not a bigger bucket you get for free; it is a pipeline you opt into.
Vignette. A travel-booking agent. Short-term memory holds this conversation — the dates being negotiated, the three flights already rejected. Long-term memory holds "prefers aisle, will not fly overnight, always books in EUR", extracted from a dozen previous bookings by a user-preference strategy, and retrieved by semantic search on the first turn of the thirteenth.
| Dimension | Short-term | Long-term |
|---|---|---|
What is stored | Raw events: messages, tool calls, results | Extracted insights: preferences, semantic facts, summaries, episodes |
Scope | One session, scoped by | Across sessions for an actor, addressed by namespace path |
How it is produced | You write events as they happen | A configured strategy extracts from events — none configured, nothing extracted |
Availability after write | Immediate | Asynchronous — there is a delay before extracted records are retrievable |
How it is read | Listed back as the recent transcript | Semantic search over extracted records ( |
Use it for | Continuity inside the task | Personalisation and context that should outlive the task |
The strategies: semantic, summarization, user preference, episodic, custom
A strategy tells Memory what kind of insight to mine from the event stream. Semantic pulls out facts. Summarization condenses a session. User preference captures stated and inferred preferences. Episodic (added December 2025) retains what happened as episodes. Custom lets you define your own extraction. A self-managed strategy option arrived at GA for teams that want to do the extraction themselves and just store the result.
Pick strategies by what you will actually retrieve. Every strategy is an extraction pipeline that costs money and adds records to search; configuring all five "in case" is how retrieval quality degrades.
Namespaces and actors — how isolation works
Events are scoped by actorId plus sessionId, so each actor’s memory is isolated. An actor need not be a human: it can be a user, another agent, or a system component.
Long-term retrieval addresses namespace paths with template variables — for example /summary/{actorId}/{sessionId}/ — mapped to the configured strategies. AWS lists namespace-based memory isolation among AgentCore’s security capabilities, alongside microVM session isolation and encrypted credential storage.
Design your actorId scheme deliberately on day one. If you key memory by tenant instead of by end user, you have built a cross-user data leak with a schema.
Why asynchronous extraction changes your read path
Long-term extraction runs in the background: there is a delay between ingesting an event and the extracted memory becoming available. AWS’s own guidance is to use short-term memory for immediate retrieval while long-term records consolidate.
Concretely: do not write an event and then, on the next turn, expect long-term search to find its distilled form. The read path for "what did the user just say" is short-term. The read path for "what does this user generally want" is long-term. Conflating the two produces an agent that is intermittently forgetful in exactly the way that is hardest to reproduce.
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.