AWSAWS Certified Generative AI Developer - Professional2026-102.1 Implement agentic AI solutions and tool integrations
Separate state lifetimes and isolation boundaries
Completed by the knowledge check
Learning objective
Separate agent working state, sessions, and AgentCore Memory while enforcing per-user and per-tenant isolation.
Core idea
Agent state has several lifetimes. Working state supports the current reasoning task. A session groups related interactions and can preserve an execution environment between invocations. Durable memory lets a later interaction recover conversation history or retrieve extracted insights.
These lifetimes do not create interchangeable security boundaries. A Runtime session isolates compute from other sessions, but AWS explicitly states that AgentCore does not enforce session-to-user mappings. Your backend must bind the authenticated user and tenant to the session and to the memory selectors used by the agent.
The design question is therefore both “how long must this survive?” and “who may select it?” Persisting the right data under an attacker-selected identifier preserves the wrong person’s context reliably. Treat identifiers and namespaces as part of the authorization contract, not as convenient model arguments.
How it works
Keep working state and session identity separate
Working state can include a partial plan, validated tool results, remaining attempts, and pending approval. It belongs to the current operation. Your application decides which fields need durable storage and which should disappear when the operation ends. Conversation text is one input to that state, not proof of a completed business action.
AgentCore Runtime uses runtimeSessionId to address a session. Reusing it across related InvokeAgentRuntime calls preserves context within the execution environment; using a different identifier separates the interactions. AWS instructs applications to generate unique session IDs with at least 33 characters.
For microVM compute, each session receives isolated compute, memory, and filesystem resources. By default, memory and disk data survive only for that compute lifecycle. Stopping the compute does not mean that the logical session identifier can never be used again: another invocation can provision new compute for the same session. Configured session storage can preserve filesystem data across stop/resume cycles.
Maintain the user-to-session relationship in your backend. Verify ownership every time the caller supplies a session reference. A difficult-to-guess ID reduces accidental collision and guessing risk, but it is not a substitute for that ownership check. Include the tenant in the ownership relation so that an employee belonging to two organizations cannot mix their contexts.
Use Memory for durable events and extracted insights
AgentCore Memory separates short-term and long-term memory. Short-term memory stores raw interactions as events. CreateEvent writes events; ListEvents reads conversation history; GetEvent retrieves a specific event. The relevant selection includes the memory resource, actorId, and sessionId.
An actor identifies the user or other entity whose interactions you store. A session groups an interaction period for that actor. These Memory identifiers are conceptually distinct from runtimeSessionId: you may map them in your application, but do not assume that reusing a Runtime ID automatically configures Memory access.
Long-term memory stores extracted insights such as facts, preferences, or summaries. Extraction and consolidation run asynchronously after input is stored through CreateEvent or submitted through IngestData. RetrieveMemoryRecords performs semantic retrieval of extracted records. A successful event write is therefore not proof that a corresponding long-term insight is immediately retrievable.
Choose raw events when you need the actual conversational sequence. Choose extracted records when you need relevant information across conversations. Use an authoritative business store for transaction truth; an extracted recollection that a payment succeeded cannot replace the payment system’s record.
Scope namespaces and enforce access
Long-term strategies place records under namespace templates. A path containing {actorId} scopes records by actor; adding {sessionId} narrows them to a conversation. A strategy-only or global namespace can span actors. Select that broader scope deliberately for shared knowledge, rather than accidentally exposing private preferences to every user.
AgentCore Memory also supports custom namespace variables. Declare them through namespaceKeys and supply their values in CreateEvent through extractionConfig.namespaceVariables. For example, your template can include an organization dimension before the actor. Custom keys and values must be lowercase; AWS permits up to five namespace keys per memory resource and five custom variables per template.
Derive the organization and actor from verified identity in your backend. Do not let a model or request payload choose another organization’s namespace. Use unambiguous path segments and a trailing slash so that a prefix intended for one actor does not collide with another actor’s longer identifier.
IAM supplies concrete access controls beyond naming conventions. CreateEvent, GetEvent, and ListEvents support the bedrock-agentcore:actorId and bedrock-agentcore:sessionId condition keys. RetrieveMemoryRecords supports bedrock-agentcore:namespace and bedrock-agentcore:strategyId. Scope permissions to the Memory resource and apply the conditions appropriate to each operation; an event condition does not automatically constrain semantic record retrieval.
The Strands integration uses AgentCoreMemoryConfig with memory_id, actor_id, and session_id, then passes an AgentCoreMemorySessionManager through the Agent constructor’s session_manager parameter. Construct that configuration from trusted mappings for the current caller. Attaching a session manager automates persistence behavior; it does not establish the caller’s tenant identity.
Key distinctions and trade-offs
The following layers solve different problems:
| Layer | What it preserves | What you must authorize |
|---|---|---|
| Working state | Current task’s intermediate observations and controls | Access to the running task and its operations |
| Runtime session | Execution context across related invocations | User and tenant ownership of runtimeSessionId |
| Memory events | Durable raw conversation history | Memory resource, actor, and session selectors |
| Long-term records | Extracted insights across interactions | Memory resource, strategy, and namespace |
Compute isolation versus data authorization: Separate microVMs prevent one execution environment from reading another’s local state. Shared external stores still require authorized selectors and scoped permissions.
Shared resource versus separate resources: A shared Memory resource can organize users through actor and namespace boundaries. Separate resources let you attach a resource-based policy on each Memory resource to control which principals can perform memory operations, at the cost of more resource management. In either design, verify user ownership within the tenant.
Architecture / decision scenario
A software-support assistant serves several customer organizations. One engineer works in two organizations and opens separate conversations for each. The backend binds each request to the authenticated engineer plus the selected, authorized organization.
It allocates separate Runtime sessions, stores their ownership mappings, and creates the Strands memory configuration from those mappings. Short-term events use tenant-qualified actor identities. Long-term namespace templates include an organization variable and {actorId}; the backend supplies the organization through extractionConfig.namespaceVariables.
The execution permissions constrain event access through actor and session conditions and constrain RetrieveMemoryRecords through namespace conditions. If a request supplies another tenant’s session or namespace, the backend rejects it before retrieval. The model never receives that tenant’s memory.
When compute stops, the assistant reloads durable events for an authorized conversation. When a preference has just been recorded, it can use the raw event while asynchronous extraction completes. It does not treat a missing extracted record as evidence that the event was lost.
Common exam traps
- Assuming Runtime automatically binds every session ID to an end user.
- Equating isolated compute with authorization to shared Memory resources.
- Treating
actorId,sessionId, andruntimeSessionIdas interchangeable fields. - Expecting long-term extraction to complete synchronously with
CreateEvent. - Using a global namespace for private user preferences.
- Allowing the model to choose tenant identifiers or memory namespace variables.
- Applying event IAM conditions while leaving record retrieval broadly permitted.
What to remember
- Select state storage by lifetime and by authorized owner.
- Bind Runtime sessions to authenticated users and tenants in the backend.
- Use events for raw history and long-term records for extracted insights.
- Enforce actor, session, strategy, and namespace conditions on the operations that support them.
- Build Strands session-manager configuration from trusted identity mappings.
Knowledge check
A caller sends a well-formed, 40-character runtimeSessionId that belongs to a session another tenant’s user created. Which check stops the backend from invoking that session for this caller?
A support assistant must replay the exact sequence of a conversation after its compute stops, and must recall each user’s stated preferences in later conversations. Which AgentCore storage division fits?
runtimeSessionIdAn execution role restricts CreateEvent, GetEvent, and ListEvents with bedrock-agentcore:actorId and bedrock-agentcore:sessionId conditions, but allows RetrieveMemoryRecords on the Memory resource without conditions. Which change closes the isolation gap?
actorId and sessionId conditions to RetrieveMemoryRecordsnamespace and strategyId conditions to RetrieveMemoryRecordsA user stated a preference a few seconds ago, and CreateEvent returned success. RetrieveMemoryRecords for that user’s namespace returns nothing about it. What should the assistant do?
IngestData to make it retrievable at onceCreateEvent or IngestData , so a successful write does not mean a record is retrievable yet. The raw event is already available to authorized reads, and widening the namespace would expose other users’ records without fixing the delay.