AgentCore course → Lesson 4

Lesson 4· ~10 min· Reading + retrieval practice

Memory and context

Memory is the capability most likely to surprise a customer on their first invoice, and the one where the compliance-friendly choice happens to also be the cheap one. It is also where the mental model most people arrive with is simply wrong.

Start from what you have

You've wired up a checkpointer and watched a context window fill with turns until quality degraded. You know the naive answer (persist the transcript, replay it) and you know it doesn't scale. AgentCore takes the other road, and that difference is the whole lesson.

The correction most customers need

Long-term memory in AgentCore is not a transcript. AWS is explicit: instead of saving all raw conversation data, long-term memory preserves only the key insights: conversation summaries, facts and knowledge, or user preferences."Instead of saving all raw conversation data, long-term memory preserves only the key insights." Long-term memory. Retrieved 2026-08-05.

Raw turns arrive as events. A strategy then extracts and consolidates structured insight from them, and it is that distilled output which persists across sessions. AWS's own example is the right one to reuse: a customer mentions their preferred shoe brand in one chat, and in a completely different conversation later the agent recalls it and makes a tailored suggestion.

The one idea

Short-term memory holds the conversation. Long-term memory holds conclusions drawn from conversations. The strategy in between is where you control cost, quality, and where your data goes.

A top-down lifecycle. An agent turn writes a short-term memory event, which
              is meter one at twenty-five cents per thousand. A memory strategy distils
              events into long-term records that persist across sessions; holding them is
              meter two at seventy-five or twenty-five cents per thousand per month.
              Later turns read records back, and each retrieval is meter three at fifty
              cents per thousand, usually the largest line.
Figure 1. One lifecycle, three meters. A turn writes an event, which is meter one. A strategy distils events into long-term records; holding those records is meter two, charged monthly. Later turns and later sessions read records back, and each read is meter three. Retrieval is usually the biggest line, because a chatty agent reads far more often than it writes.

Open full-size diagram

The ledger: three meters, one lifecycle

Memory bills on three separate meters, and teams model the first two while forgetting the third. The figures below are the worked support-agent sketch from the pricing card: 10,000 sessions, 8 turns each, 2 memory retrievals per turn.

1 Events written $0.25 / 1k Fires on every turn. The raw material, before any strategy touches it. 80,000 events. Lever — turns per session. Mostly fixed by the product, so mostly not yours to move. $20.00
2 Records stored $0.75 or $0.25 / 1k / month Charged monthly for as long as you keep them. 15,000 distilled records, priced here at the built-in tier. Lever — the strategy tier. A configuration change, and it is 3× cheaper on the other side of it. $11.25
3 Records retrieved $0.50 / 1k Fires every time the agent consults memory. A chatty agent reads far more often than it writes. 160,000 retrievals. Lever — retrievals per turn. An application design decision, not a configuration flag, and the largest one available. $80.00
Memory, all three meters $111.25
Runtime compute, for the same workload $27.00

Read the two levers against each other, because the asymmetry is the finding. Switching storage tiers saves $7.50. Halving retrievals per turn saves $40. Retrieval discipline — consulting memory once per turn instead of twice, caching within a turn, narrowing the namespace queried — is worth five times more than the configuration change, and it is the thing nobody models. Retrieval alone is about three times the entire Runtime bill.

Say this to a customer

"Memory bills on three meters, not one: what you write, what you keep, and what you read back. Almost everyone models the first two. Reading back is usually the biggest line, so before you ship, decide how many times per turn your agent really needs to consult memory. Twice instead of once can double that part of your bill."

The one configuration change that moves two lines at once

Above the choice of which strategy sits the choice of how much of it you own. Three tiers, and this is the decision worth walking a customer through carefully, because it moves meter 2 and data residency together.

Strategy tiers and what each controls
Tier What you control Storage cost
per 1k records / month
Cross-region inference
Built-in Nothing. AWS's default extraction and consolidation $0.75 Yes, unavoidable
Built-in with overrides Your own extraction prompts, and you pick the foundation model for extraction and consolidation $0.25 Avoidable
Self-managed The entire extraction and consolidation pipeline; AgentCore provides only storage and retrieval $0.25 Avoidable

The mechanism connecting those last two columns is worth understanding rather than memorising. Long-term memory has to run inference to extract insight from raw turns. On a built-in strategy, AWS chooses the model, which means AWS also chooses where it runs, hence cross-region inference. On built-in with overrides you select the foundation model yourself, and AWS documents this as precisely the way to manage model selection and avoid cross-region inference.Overrides let you provide your own instructions and select a specific foundation model for extraction and consolidation (Customize a built-in strategy); the CRIS opt-out via built-in-with-overrides is stated in Cross-region inference. Retrieved 2026-08-05.

The rare easy win in Canada

Almost every compliance conversation is a trade-off. This one is not. Built-in with overrides is simultaneously the cheaper storage tier and the one that lets a Canadian customer keep memory inference in-region. Three times cheaper on stored records and better on residency. Lead with it.

What the strategy actually extracts

Three built-in strategies, each answering a different question about the user. Naming them precisely is what makes you sound like you have used this.

Semantic
Extracts facts and contextual knowledge — entities, events, details discussed — building a persistent knowledge base. Answers: what is true about this user's world?
User preferences
Extracts preferences, choices, and styles, building a persistent profile per user. Answers: what does this user like and expect?
Summary
Condenses conversations into summaries rather than retaining the turns. Answers: what happened, in brief?

Memory records are organised into namespaces, patterns such as /users/{actorId}/preferences/.Strategy types, namespaces, and the extraction and consolidation steps, Configure built-in strategies and Memory strategies. Retrieved 2026-08-05. That is the mechanism behind the claim that memory stores can be shared between agents: two agents pointed at the same namespace see the same accumulated understanding of a user. For a startup running a support agent and a sales agent, that is the difference between one coherent product and two that contradict each other.

Don't overclaim

AWS does not publish extraction latency, how long consolidation takes to make a new fact retrievable, or any accuracy figure for the built-in strategies. If a customer asks "will it remember the right things," the honest answer is that it depends on their domain and is worth measuring with Evaluations, which is Lesson 5, rather than assuming.

Read this next: 6 minutes

AgentCore Developer Guide: Long-term memory

The page that fixes the transcript misconception, with the shoe-brand example you can reuse verbatim in a meeting. Follow it with Configure built-in strategies if you want to be able to name the three strategy types confidently. Retrieved 2026-08-05.

Retrieval practice

Four questions. Question three interleaves Lesson 2 on purpose, because it is the confusion customers make most often.

  1. What does AgentCore long-term memory actually persist across sessions?

    • The raw conversation turns, stored verbatim
    • Insight extracted from turns by a strategy
    • The vector embeddings of every user message

    Answer: B. Extracted insight, not raw turns.

  2. A Canadian customer needs memory inference to stay in-region. Which tier do you recommend?

    • Built-in, because AWS manages the model for you
    • Self-managed, because you own the whole pipeline
    • Built-in with overrides, because you pick the model

    Answer: C. Built-in with overrides, cheaper and in-region.

  3. A customer says "if sessions are isolated, how can the agent remember me?" What is the resolution?

    • Isolation bounds compute; Memory persists on purpose
    • Isolation is relaxed whenever Memory is enabled
    • Memory only works inside a single live session

    Answer: A. Different boundaries. Isolation is compute; Memory is deliberate persistence.

  4. In the worked support-agent sketch, which single change saves the most money?

    • Moving storage to the cheaper overrides tier
    • Halving how often each turn reads memory back
    • Halving the compute each session consumes

    Answer: B (halving retrievals per turn).

Where to go next

You can now explain to a founder what their agent will remember, how it decides what to keep, roughly what it will cost per thousand sessions, and which tier to pick if they care about residency.

Lesson 5 answers the question that separates a good AgentCore conversation from a great one: how do you know the agent is actually any good, and how do you make it better on evidence rather than instinct?

Questions to take forward