AI Agent - Aug 9, 2026

AgentCore GovCloud Memory: Short-Term vs Long-Term

Quick answer

Use short-term memory when an agent must reload raw interactions for a conversation. Use long-term memory when it must retrieve selected summaries, facts, knowledge, or preferences across sessions. Use both only when the value of cross-session recall justifies separate controls for raw events and asynchronously extracted records.

For a regulated workload, memory is a data system, not a convenience toggle. Define identity mapping, allowed content, encryption, namespaces, retention, deletion, retrieval filters, provenance, correction, monitoring, and incident response before enabling it in AWS GovCloud (US-West).

Short-term memory stores events

AWS describes short-term memory as raw interactions stored as events. Each event belongs to a sessionId; an implementation can write questions, answers, instructions, or structured information and later list or retrieve those events.

This supports conversation continuity, but it also creates a replayable record. Decide:

  • which message roles and tool results may be stored;
  • whether attachments, secrets, controlled data, or downstream responses are prohibited;
  • how a caller is mapped to an actor and session;
  • who can list sessions and events;
  • retention and deletion behavior;
  • what the application does when retrieval fails or returns unexpected content.

AWS notes that event metadata is not intended for sensitive content because it is not encrypted with a customer-managed key. Keep sensitive values out of metadata and recheck current encryption documentation for event bodies and memory resources.

Long-term memory stores extracted records

Long-term generation runs asynchronously after raw context is stored. AgentCore extracts information, consolidates it with existing information, and stores memory records that can be retrieved across sessions, including through semantic search.

That introduces a different failure model:

  • an extraction can be incomplete or wrong;
  • a preference may expire;
  • two source events may conflict;
  • a correction in the system of record may not update the memory;
  • retrieval may return a plausible but irrelevant record;
  • deleted source events and derived records may have different lifecycle paths.

Treat long-term records as generated context. Preserve provenance where the workflow requires it, expose correction and deletion paths, and verify important facts against an approved source of record.

Decision table

NeedCandidate choiceMain review
Resume one conversation after a restartShort-termEvent content, session mapping, retention
Recall a preference across conversationsLong-termExtraction accuracy, expiry, consent, correction
Support both continuity and personalizationBothTwo-store lifecycle, identity, provenance, deletion
Stateless or highly sensitive taskDisabledWhether approved context can be supplied per request
Authoritative customer or case factsExternal system of recordAgent retrieves only authorized, current fields

Long-term memory is not a replacement for Retrieval-Augmented Generation over governed documents or for a transactional database. Choose the source based on who owns the fact and how it is corrected.

Actor, session, and namespace boundaries

An actor ID represents the user, tenant, agent, or system whose memory is being addressed. A session ID identifies a conversation. Long-term strategies can use namespace templates to organize retrieval.

These identifiers are security-relevant inputs, but they are not authentication. The application must derive them from an authenticated and authorized context, prevent caller override, test cross-tenant denial, and keep stable mapping rules through migrations.

Include negative cases: a valid user with another tenant’s actor ID, a reused session ID, missing actor context, an administrator with overly broad list access, and an agent attempting to store prohibited material.

Managed harness memory versus an existing resource

The current Harness documentation describes managed memory, bring-your-own AgentCore Memory, or disabled memory. Managed memory can reduce setup work; an existing memory resource may be needed for custom namespace templates, KMS choices, or sharing across approved harnesses.

Do not infer that a default is approved. Record who owns the memory resource, which harnesses can use it, how changes are versioned, how deletion behaves when the harness is removed, and which costs continue after a pilot.

GovCloud readiness checks

  1. Confirm Memory access in the intended us-gov-west-1 account and record current APIs and quotas.
  2. Map every event field, metadata field, extraction output, namespace, retrieval query, and log.
  3. Define actor and session mapping from authenticated identity; block caller-controlled tenant selection.
  4. Test allowed retrieval, cross-tenant denial, stale records, conflicting records, correction, deletion, export, backup, and incident isolation.
  5. Verify that any model, external tool, identity provider, or support workflow does not create an unapproved path outside GovCloud.
  6. Keep compliance and records-management approval separate from a successful technical test.

Frequently asked questions

What is short-term memory in AgentCore?

Short-term memory stores raw interactions as events associated with a session ID so an agent can recover conversation context. Applications still decide what to write, who may retrieve it, and how long it should remain.

What is long-term memory in AgentCore?

Long-term memory asynchronously extracts and consolidates selected information from stored interactions into records that can be retrieved across sessions. An extracted record is generated context, not verified ground truth.

Should a regulated agent enable both memory types?

Only when the use case needs both session replay and cross-session recall and the team can govern both stores. A lower-risk design may use short-term memory only, an approved external system of record, or no persistent memory.

Does actor and session scoping replace authorization?

No. Actor and session identifiers organize and isolate retrieval only when the application maps them correctly. They do not authenticate the caller, prove tenant ownership, authorize content, or prevent an application from passing the wrong identifier.

Continue by decision

Official sources

Source check: August 9, 2026. Verify Region support, memory strategies, encryption, metadata treatment, retention, deletion, managed-memory behavior, quotas, and prices before use.