Assign state to the required lifetime

Learning objective

Distinguish agent sessions, runtime state, and durable memory. You should be able to identify which information belongs to a conversation, what disappears with its compute, and what the application must persist and reload. Detailed identity and state-isolation design belongs to 2.1.3.

Core idea

A session groups related interactions. Runtime state is the working information held while the agent executes: conversation objects, intermediate results, counters, and files. Durable memory stores information independently of the active process so it can be retrieved after that process stops.

These categories overlap in use but differ in lifecycle. A session identifier can route two requests to related execution context without being a permanent conversation archive. Persisted conversation events can be called short-term memory even though they survive a process restart. “Short-term” and “durable” answer different questions: what the information represents and what lifecycle it survives.

How it works

Group related interactions into sessions

In Amazon Bedrock AgentCore Runtime, your application supplies a runtimeSessionId to InvokeAgentRuntime. Reusing that identifier groups related invocations into the same Runtime session. AWS documents isolated execution environments and preservation of context between invocations to the same session.

The identifier’s owner matters. AWS explicitly states that AgentCore does not enforce session-to-user mappings; your client backend maintains that relationship. A client-provided string is not proof that the caller may access the associated conversation. Bind requests to the authenticated user’s allowed session before invoking the runtime. Implementation details belong to 2.1.3.

Also avoid assuming that every AWS API uses interchangeable session identifiers. A Runtime session identifier identifies the execution session for AgentCore Runtime. AgentCore Memory uses sessionId to group stored events and actorId to identify their actor. Your application can maintain a relationship between those values, but the relationship is part of its design rather than a guarantee created by similar field names.

Keep working state within its compute boundary

The AgentCore Runtime session documentation describes default compute context as ephemeral. Values in process memory and files on its default filesystem persist for the compute lifecycle. They can support related invocations while that compute remains available, but they are not an independent durable record. Compute stops after inactivity (idleRuntimeSessionTimeout, default 15 minutes), on reaching maxLifetime (default 8 hours), on an explicit StopRuntimeSession call, or when health checks deem it unhealthy. The next invocation provisions replacement compute. You set both timeouts through LifecycleConfiguration, up to 8 hours on microVMs or 14 days on Instances.

Runtime also supports configured session storage: a persistent directory that survives compute termination across session stop/resume cycles. This is an explicit configuration, not a property of every local file. The state lifecycle therefore depends on where you write it. An in-memory object, a default local file, and a file under a configured persistent mount have different recovery expectations.

Distinguish a stopped compute from a deleted session identity. AWS documents that a stopped Runtime session can become active on the next invocation with replacement compute, and that the session remains valid until the Runtime ARN is deleted. Reusing its identifier does not reconstruct lost in-memory objects. Persist and reload required information through an appropriate store rather than treating identifier validity as evidence that the old working state exists.

A Runtime session can stop and become active again many times before its identity ends.

For example, a transient lookup result can remain in working state if repeating the lookup is acceptable. A conversation the user expects to resume after compute termination needs an explicit persistence and reconstruction path. A business action that must not execute twice needs an authoritative action record; conversational memory alone is not that transaction boundary. See 2.1.11 for retry-safe effects.

Persist raw interactions as short-term memory

AgentCore Memory short-term memory stores raw interactions as events. Use CreateEvent to capture conversational or structured information. Events are organized by sessionId and actorId. ListEvents retrieves event history. See 2.1.3 for the additional event and session operations.

These stored events can support continuity after a service restart or when a customer returns to a previous conversation. That makes short-term memory a persistent representation of the conversation, distinct from the Runtime’s in-process history. The application still needs to retrieve the events and assemble the relevant context for the next model call.

Saving an event does not mean the model has received it. Storage, retrieval, and context assembly are separate steps. A model invocation that omits the retrieved history cannot benefit from that history merely because the memory service contains it. Context selection is covered in 0.8 and 1.3.9.

Retrieve extracted information as long-term memory

AgentCore Memory long-term memory holds information extracted from interactions, such as summaries, facts, or preferences, across sessions. When long-term strategies are configured, extraction and consolidation run asynchronously after raw information is submitted. Do not assume that an immediately preceding event already has an extracted memory record available.

RetrieveMemoryRecords performs semantic search for relevant memories. See 2.1.3 for the additional memory-record operations. Long-term strategies organize records under namespaces; actor and session organization determine the intended retrieval scope.

A summarized preference is useful context, but it is not proof of the user’s present intent. A customer might have preferred home delivery in a previous conversation and choose collection today. Preserve the current request and verify consequential choices instead of allowing a recalled preference to silently override explicit input. A memory summary also differs from the raw event history: it may omit details needed to audit an earlier decision.

Key distinctions and trade-offs

Use the lifecycle requirement to classify information:

Persisting more history improves reconstruction but increases the information that must be governed and selected. Extracted memory reduces the amount of raw history needed for personalization but is not a lossless audit archive. Choose the representation by the decision it must support rather than by the word “memory.”

Architecture / decision scenario

A support agent handles a customer’s delivery issue across two visits. During the first visit, its Runtime working state contains a carrier lookup and a loop counter. The backend maps the authenticated customer to the allowed runtimeSessionId and stores the exchanges using CreateEvent with the intended actor and Memory session identifiers.

The compute stops before the customer returns. The same Runtime identifier can resume the session, but the application reloads events with ListEvents rather than assuming its old in-memory history survived. It refreshes the carrier lookup because shipment status can change.

For a separate conversation, the application retrieves an extracted delivery preference through RetrieveMemoryRecords. It treats that record as supporting context and confirms the customer’s chosen delivery method. If the user requests a refund, the agent checks the authoritative action record rather than inferring completion from a conversation summary. Each form of state serves a distinct continuity or correctness requirement.

Common exam traps

• Treating a session identifier as a permanent conversation archive.
• Assuming every local file survives Runtime compute termination.
• Equating AgentCore Memory short-term events with ephemeral process memory.
• Assuming Runtime enforces session-to-user ownership for the application.
• Expecting asynchronous long-term extraction to finish before the next request.
• Treating a recalled preference or summary as authoritative business state.

What to remember

• Sessions group interactions; working state supports active execution.
• Default Runtime compute context is ephemeral; configured storage changes file persistence.
• Short-term Memory events can survive restart despite their name.
• Long-term memory extracts useful information across sessions asynchronously.
• Persist, retrieve, and assemble required context explicitly.

Knowledge check

References

• AWS, Use isolated sessions for agents
• AWS, Lifecycle settings for AgentCore Runtime
• AWS, Memory types
• AWS, Memory organization in AgentCore Memory