Agent memory as a managed service

An agent with no memory re-meets you every session: same questions, same context-gathering, same mistakes. The concepts chapter drew the line that makes this chapter possible: prompt caching recycles processing, but only memory changes what the model sees. This chapter covers memory as an agentic design problem first (the pipeline every system implements, and the questions no vendor answers for you), then decodes AgentCore Memory as one implementation among an ecosystem of them.

The pipeline, vendor-free

Every agent memory system, open-source or managed, is the same five stages wearing different names:

capture -----> extract -----> store -----> retrieve -----> inject
(transcripts   (turn raw      (somewhere    (find what's    (put it in
 and events)    history into   durable and   relevant to     the context
                facts worth    queryable)    this moment)    window)
                keeping)

Capture you already own: the event store is a perfect capture layer, which is why memory is cheap to add to an event-sourced platform. Extract is the interesting stage: raw transcripts are too long and too noisy to be memory, so something (a model call, usually) distills them: "user prefers staging deploys on Fridays," "the payments-db pool was resized in v841." Store and retrieve are a database problem with an embedding flavor (Part 7 builds this pair). Inject closes the loop: retrieved memories enter the prompt, costing tokens, which makes memory a budget line, not a free good.

The ecosystem maps onto the pipeline cleanly. Open-source memory engines (the MemGPT lineage that became Letta, mem0, LangMem and kin) are opinionated bundles of extract-store-retrieve. Anthropic's memory tool inverts control: the model reads and writes a memory directory through tool calls, making extraction a behavior instead of a pipeline stage. Vector stores alone are just stage three. And AgentCore Memory is AWS's managed bundle of the middle three stages, wired for capture from Runtime sessions.

AgentCore Memory, decoded

Two layers, matching the two timescales that keep coming up:

• Short-term memory is session-scoped: the running conversation and working state, available across turns (and across the idle gaps from the previous chapter) without you schlepping transcripts around. This is convenience, not intelligence: the same thing your event store rebuilds, held for you.
• Long-term memory is where the pipeline lives. You configure strategies, which are extraction policies by another name: a semantic-facts strategy distills stable facts from conversations, a summary strategy keeps rolling summaries, a user-preferences strategy watches for durable preferences, and (added after GA) an episodic flavor captures how past tasks went, so an agent can consult precedent. Extraction runs asynchronously off your sessions; retrieval is a query returning relevant memories for injection.

Being a managed pipeline, it makes the platform-shaped promises: namespacing per user or per agent (the isolation gate again: one tenant's facts must never surface in another's retrieval), IAM on the APIs, integration with Runtime sessions, and encryption choices. That is genuinely most of the operational surface of a memory system, and building the equivalent well is a Part 7 sized job.

What buying does not answer

The design questions travel with you, whoever runs the database, and they are worth naming because they are where memory systems actually fail:

• What deserves remembering? Extraction tuned loose fills the store with trivia that pollutes retrieval; tuned tight, the agent forgets what mattered. This is a precision-recall dial with no vendor default that fits your domain.
• Is it still true? Facts age ("the pool size is 10" was true Tuesday). Memories need provenance (which session, which evidence) and staleness policy (decay, re-verification, or overwrite on contradiction). A memory with no provenance is a rumor with persistence.
• When do you consult it? Injecting everything every turn is the always-loaded tax (tokens, and retrieval noise); retrieving on demand is cheaper but adds a judgment call about when to look. The companion context-engineering book prices this trade in detail; the short version is that consult-rate decides the answer, and both extremes are usually wrong.
• Does it actually work? Memory needs its own evals: plant a fact, add distracting sessions, probe later, score. Part 7 builds that harness. Without it, memory quality is a feeling, and the failure mode (an agent confidently acting on a stale or misattributed memory) is worse than amnesia, because amnesia at least asks.

Don't be confused: session state vs memory. Session state is where the current job is: the transcript, the checkpoints, things the event store holds so a crash or an idle gap loses nothing. Memory is what the platform knows independent of any job: facts, preferences, precedents, useful next month in a session that has not started yet. State wants perfect fidelity and dies with the run's relevance; memory wants distillation and outlives every run. Systems that conflate them either bloat memory with transcripts or lose state to summarization.

Choosing a shape

The honest default mirrors the sandbox chapter to come: buy or adopt a pipeline to start, keep your capture layer sovereign (the event store feeds any of the four shapes), and let the memory evals, not the feature lists, pick the winner for your workload.

👉 Next: tools over the wire, where the protocol under half the modern agent ecosystem gets built from scratch in 150 lines, and AgentCore Gateway turns out to be a factory for exactly what you just built.