Memory in Frameworks & at the Limits

By this point you've driven AgentCore Memory directly: create_event to write a turn, retrieve_memories to pull back long-term records, the MemorySessionManager/MemorySession helpers from the Python SDK. Frameworks don't replace any of that — they wire those same data-plane calls into the agent loop so you stop threading session state by hand.

The mental model is unchanged from the SDK lessons:

• Short-term = raw turn-by-turn events you write with CreateEvent; immutable, scoped by actorId + sessionId.
• Long-term = insights the service extracts asynchronously via the strategies you attached, retrieved with RetrieveMemoryRecords.
• No strategies = only short-term events; nothing gets extracted.

What a framework integration adds is the plumbing: on each turn it persists the user/assistant messages as an event and, before the model runs, retrieves relevant long-term records and injects them into context. AgentCore ships a first-party integration for Strands (the AWS-native SDK) that does exactly this through a session manager. For other frameworks like LangGraph, there is no confirmed first-party module — you call the same data-plane methods yourself from inside your nodes.

turn arrives ─▶ retrieve_memories (long-term context)
             ─▶ model call
             ─▶ create_event (persist the new turn)
             ─▶ async extraction runs later → memory records

Keep the eventual-consistency rule from the SDK lesson in mind: extraction is asynchronous, so a retrieve_memories fired immediately after the matching create_event may return nothing until the strategy pipeline catches up.

The Strands integration lives in bedrock_agentcore.memory.integrations.strands. You build a config object that binds a memory resource to one actor/session, wrap it in a session manager, and hand that manager to the Strands Agent. From then on, Strands persists turns and retrieves context through AgentCore automatically.

The two classes that matter:

• AgentCoreMemoryConfig(memory_id, session_id, actor_id, batch_size=...) — binds an existing memory resource to a single conversation: which memory, which actor, which session, and how aggressively to batch writes.
• AgentCoreMemorySessionManager(agentcore_memory_config, region_name) — the session manager that performs the create_event / retrieve_memories calls on the framework's behalf.

from strands import Agent
from bedrock_agentcore.memory.integrations.strands import (
    AgentCoreMemoryConfig,
    AgentCoreMemorySessionManager,
)

memory_config = AgentCoreMemoryConfig(
    memory_id="mem-123",           # an ACTIVE memory resource
    actor_id="customer-456",       # who this conversation is about
    session_id="session-789",      # this specific conversation
    batch_size=1,                  # 1 = flush every turn (see the gotcha below)
)

session_manager = AgentCoreMemorySessionManager(
    agentcore_memory_config=memory_config,
    region_name="us-east-1",
)

# Hand the session manager to the Strands Agent — that's the whole wiring.
agent = Agent(session_manager=session_manager)

response = agent("I'm allergic to peanuts — remember that for next time.")

Note the binding granularity: a config is per actor + session. A new conversation (new session_id) or a different end user (new actor_id) means a new AgentCoreMemoryConfig and a new session manager. This mirrors AgentCore's core concepts exactly — the actorId/sessionId pair is the scoping key for short-term events.

Underneath, the memory resource itself still has to exist and be ACTIVE, with whatever strategies you want attached at CreateMemory time. The integration consumes a memory; it does not create one.

AgentCoreMemoryConfig takes a batch_size. This is the single most important operational detail in the Strands integration, and it bites people in production.

With batch_size > 1, the session manager buffers messages in memory and only flushes a CreateEvent once the buffer reaches the threshold. Batching cuts the number of data-plane calls (and the per-event cost), which is attractive under load. But if your process ends — the agent finishes, the request returns, the container is reclaimed — while messages are still sitting below the threshold in the buffer, those buffered messages are never written and are silently lost. No error, no retry; the turns simply vanish from memory.

The fix is to make the flush deterministic. Either use the session manager as a context manager so it flushes on exit, or call close() explicitly in a finally:

# Option A — with-block: the buffer is flushed when the block exits
with AgentCoreMemorySessionManager(
    agentcore_memory_config=memory_config,
    region_name="us-east-1",
) as session_manager:
    agent = Agent(session_manager=session_manager)
    agent("Book me the 9am, and I prefer aisle seats.")
    agent("Actually make it the 10am.")
# <- buffered messages are flushed here, even with batch_size > 1

# Option B — explicit close() in finally
session_manager = AgentCoreMemorySessionManager(
    agentcore_memory_config=AgentCoreMemoryConfig(
        memory_id="mem-123", actor_id="customer-456",
        session_id="session-789", batch_size=10,
    ),
    region_name="us-east-1",
)
try:
    agent = Agent(session_manager=session_manager)
    agent("...")
finally:
    session_manager.close()   # flush whatever is still buffered

The safest default while you're learning is batch_size=1, which flushes every turn — no buffer to lose. Reach for a larger batch_size only once you've wrapped the manager in a with block or a guaranteed close(), and especially in any short-lived, per-request handler where the process may exit between turns.

There is no confirmed first-party AgentCore Memory integration module for LangGraph at the time of writing. Don't go looking for a magic session manager — the supported pattern is to call the same data-plane methods (create_event / retrieve_memories) directly from inside your graph nodes, using the Python SDK you already know.

A typical shape: a retrieve node that pulls long-term context before the model node, and a persist node that writes the completed turn as an event.

from bedrock_agentcore.memory import MemoryClient

memory = MemoryClient(region_name="us-east-1")
MEMORY_ID = "mem-123"

def retrieve_node(state):
    """Pull relevant long-term records before the model runs."""
    records = memory.retrieve_memories(
        memory_id=MEMORY_ID,
        namespace=f"/users/{state['actor_id']}/preferences/",
        query=state["user_input"],
        top_k=5,
    )
    state["memory_context"] = records
    return state

def persist_node(state):
    """Write the completed turn as a short-term event."""
    memory.create_event(
        memory_id=MEMORY_ID,
        actor_id=state["actor_id"],
        session_id=state["session_id"],
        messages=[
            (state["user_input"], "USER"),
            (state["assistant_output"], "ASSISTANT"),
        ],
    )
    return state

# graph.add_node("retrieve", retrieve_node)
# graph.add_node("persist", persist_node)
# graph.add_edge("retrieve", "model")
# graph.add_edge("model", "persist")

Because you own the calls, you also own the flush — there's no hidden buffer to lose, but you must place the create_event somewhere it always runs after the model turn. Cross-check the official samples before you commit to an exact signature: the AgentCore samples repo, under 01-tutorials/04-AgentCore-memory/, has the up-to-date framework patterns and is the source of truth as these integrations evolve.

Several quotas shape how you architect a Memory-backed agent. Every number here is [VOLATILE] — verify the live quotas page before you rely on it; the values below are as of writing. Crucially, note which limits are adjustable (you can request an increase) versus fixed (hard, design around them).

The two that most often force a design change:

• 6 strategies per memory, not adjustable. You cannot buy your way past it. If you need more than six extraction behaviors, split across multiple memory resources or consolidate strategies. Plan your semantic/summary/user-preference/episodic mix up front.
• 100 messages per CreateEvent. A single event can hold multiple messages (a USER + ASSISTANT pair, plus TOOL results), but not unbounded history — chunk long transcripts into multiple events.

The TPS limits are per operation, so a burst of writes from many concurrent sessions can throttle on CreateEvent (10 TPS, and only 5 TPS for conversational payloads per actor/session). Catch ThrottlingException and back off. Retention is bounded 7–365 days with an SDK default of 90 — raw short-term events expire on that schedule, so anything you need beyond it must live as a long-term record.

AgentCore Memory is consumption-based, and the dimensions map onto the short-term / long-term split you already know. As always, the exact rates are [VOLATILE] — learn the dimensions and price them against the live pricing page.

The billing dimensions:

• Per short-term event — each CreateEvent you write. (This is exactly what batch_size trades off: fewer events, lower cost — at the durability risk above.)
• Per long-term record stored, per month — the extracted memory records that strategies produce, billed for as long as they're retained.
• Per retrieval — each RetrieveMemoryRecords / retrieve_memories call.

On top of that, the extraction work itself can incur separate Bedrock model charges, depending on the strategy tier:

• Built-in strategies — AgentCore runs the managed extraction/consolidation pipeline; the extraction tokens count against the long-term extraction budget.
• Built-in with overrides and self-managed strategies — these call a Bedrock model you choose, and those LLM calls are billed to your account in addition to the Memory dimensions above. Overrides require a memoryExecutionRoleArn.

The lever you actually watch in operations is token consumption for long-term extraction, which is metered. Monitor it via the CloudWatch metric TokenCount in the Bedrock-AgentCore namespace, and remember the built-in extraction budget (150,000 tokens/min as of writing) and the per-session episodic budget (50,000 tokens).

import boto3

cw = boto3.client("cloudwatch", region_name="us-east-1")
resp = cw.get_metric_statistics(
    Namespace="Bedrock-AgentCore",
    MetricName="TokenCount",
    StartTime="2026-06-01T00:00:00Z",
    EndTime="2026-06-04T00:00:00Z",
    Period=3600,
    Statistics=["Sum"],
)
# Alarm on this to catch a runaway extraction bill from a chatty agent.

The practical takeaway: a verbose agent with several built-in strategies generates a lot of extraction tokens. Episodic in particular is heavier (it adds a Reflection step). Alarm on TokenCount before a noisy rollout, not after the bill arrives.