AI Agent Memory for eCommerce: What Should Your Agents Remember? (2026)

Week two of a support chat in September 2026. A shopper changed their shipping address in the account UI yesterday. Today they ask about a delay. The agent cites the old address from Memory and drafts a notice to the wrong place. The CRM had the update. Memory did not.

AI agent memory for eCommerce is a layering problem. Remembering everything is not desirable. AgentCore Memory is session and long-term conversational state. It is not the customer profile store, not the OMS, and not a substitute for Identity. Net-new agents should not start on Agents Classic after July 30, 2026.

This post is not an anonymized client engagement. We do not invent recall-accuracy or CSAT KPIs. Demo order ids are fixtures.

The job. Draw five layers. Decide what belongs in Memory vs what belongs in a tool read from CRM, OMS, or PIM.

This week. Copy the retention policy artifact. Name TTL and a deletion path. Prefer tools over Memory for facts.

A person still signs. Open approvals, notify keys, and anything that moves money or PII.

Skip it when facts already live in OMS, CRM, or PIM and the agent can call tools.

Our take: Memory is a bounded notebook, not a second CRM. An extra getOrder each turn beats a polite agent that is confidently a week out of date.

Copy the retention table — agent-memory-retention-policy.md. Name TTL, owner system, and deletion path per layer for your store. Series folder: ecommerce-ai-agents-series/.

Five layers (stop calling all of them “memory”)

flowchart TB
  turn[This turn]
  turn --> sess[Session context]
  turn --> tools[Gateway tools]
  tools --> crm[CRM]
  tools --> oms[OMS / WMS]
  tools --> pim[PIM / policy KB]
  sess --> ltm[AgentCore Memory optional]
  hitl[HITL tickets] --> ops[Operational state]
  ltm -.->|never wins if asOf newer| tools

Managed Knowledge Base is not this table. KB holds documents (return policy PDF, size charts). Memory holds conversational state. Most production agents need KB for policy and tools for orders. Do not dump the catalog into Memory — store-agents distinction.

What each layer should remember (and refuse)

Session. The current getOrder payload, the last specialist evidence blob, the shopper’s question. Isolated by Runtime microVM session. Do not reuse a short session id across shoppers. The InvokeHarness sketch in the autonomy post already requires runtimeSessionId of at least 33 characters.

Customer context. Size preference, language, loyalty tier — in CRM. The agent may read them via getAccount / getTier. Putting them only in Memory means a CRM update never wins. Permissions: shopper JWT reads this shopper; associate JWT reads what Cedar allows. Security.

Business history. ORD-1001 shipped; RMA open; SKU-TEE-BLU-M ATP. These facts have asOf. Memory must not override a newer tool result. Goldens: fail if the agent cites Memory when getShipment.asOf is newer.

Long-term Memory. Optional notes the systems of record will never hold: “shopper asked to avoid gift-wrap this conversation.” Even then, TTL it. Align deletion with the privacy policy. If you cannot name the job that forgets, do not enable the store.

Operational state. HITL ticket id, “delay notice already sent for exception X,” last daily brief timestamp. Idempotency keys live here — HITL architecture. Memory is a bad ledger.

If two layers own the same field, pick one. Address lives in CRM. Status lives in OMS. “Customer likes blue” is either a CRM preference attribute or it is not a fact — it is not both Memory and a merchandising flag. Dual ownership is how stale Memory wins a tool argument in the prompt even when your table says otherwise.

Deletion is a named job, not a slide. When a shopper exercises access/erasure rights, AgentCore Memory for that shopper id must be in the same runbook as CRM and helpdesk. If legal cannot point at the namespace, disable long-term Memory until they can. We are not publishing a FactualMinds DSR completion-time KPI; we are saying the path has to exist.

Privacy, permissions, stale information

• Do not store PAN, passwords, MFA secrets, health data, government IDs, or raw payment payloads in Memory. Payment capture is out of the tool set.
• Shopper JWT must not retrieve another shopper’s Memory. Namespace by shopper id and audience (shopper vs associate).
• Retention: match privacy policy and marketplace rules. “Keep forever for personalization” is not a policy.
• Stale Memory rule: if asOf on CRM / OMS / PIM / price / ATP is newer, trust the system. Prompt text cannot override that.
• Multi-agent: specialists must not treat shared Memory as a bus. Closed questions + tools — when to split.
• Audit: CloudTrail on bedrock-agentcore.amazonaws.com plus Memory retrieval traces. If you cannot show what was recalled, you cannot defend it.

Strands 1.0 after export still does not replace Identity. Swarm shared working memory is a different bag — do not use it as CRM-for-refunds.

For your technical lead

On June 17, 2026, Amazon Bedrock AgentCore Harness reached general availability (What’s New). Harness can attach Memory as configuration. That is a reason to write a retention policy, not a reason to remember every SKU the shopper hovered.

Agents Classic is in maintenance for new customers after July 30, 2026. Net-new agents should use Bedrock AgentCore. Full matrix: lifecycle roundup.

Harness config can enable Memory. Runtime isolation still scopes the session. Gateway tools still fetch systems of record. There is no native Shopify Memory connector — Shopify customer records stay in Shopify / your CRM behind tools you own.

Agents Classic after July 30, 2026 is the wrong net-new path. Classic conversation state is not this retention table.

Browser off. Memory plus Browser is how you persist scraped HTML as if it were ATP. Support-shaped pilots with Browser left hot tracked roughly 3× Runtime-shaped spend — ship map.

Context: Python 3.12+, boto3 ≥ 1.38.0, supported region. Sketch — pin the model your account allows. This invoke does not configure Memory; it shows the session boundary.

# Sketch — InvokeHarness. runtimeSessionId must be at least 33 characters.
# Memory, if enabled on the harness, is scoped to this session / configured namespace — not a CRM.
import boto3
import uuid

client = boto3.client("bedrock-agentcore", region_name="us-west-2")
response = client.invoke_harness(
    harnessArn="arn:aws:bedrock-agentcore:us-west-2:123456789012:harness/commerce-support",
    runtimeSessionId=str(uuid.uuid4()),
    messages=[{"role": "user", "content": [{"text": "Where is order ORD-1001?"}]}],
)

If getOrder is attached, this turn should call it. A Memory hit from last week is not status.

First-party signals we reuse (not store results) — Gateway server-side tools cut median tool round-trip ~180 ms → ~95 ms on a B2B CRM assistant (12 tools, ~8k turns/day) — Gateway post. Platform cost silhouette: support-style AgentCore at 50K sessions/mo ~$791/mo platform plus model (decision guide). Memory events and retrievals are extra AgentCore lines — model them on the AgentCore pricing calculator. They are not “smarter commerce.”

The CRM canary (~180 → ~95 ms) is why a tool re-read is cheap enough to prefer over a remembered price. Your PIM p95 still dominates. ~$791/mo at 50K sessions is platform-plus-model for a support-shaped mix; Memory retrievals stack on top — they are not savings from “the agent already knows.”

What broke — Week two of a support harness with long-term Memory on “for personalization.” A shopper changed shipping address in the account UI. Next chat, the agent cited the old address from Memory and drafted a delay notice to the wrong place. Detection: HITL reviewer compared Memory blob to getAccount; asOf on CRM was newer; Policy never saw a write because notify was Fully Automated on a template that interpolated Memory. Fix: strip address from Memory; require getAccount for any destination field; goldens that fail if Memory supplies address/ATP/price; TTL Memory to session-only for support. Lesson: remembering everything is how you ship stale PII with a friendly tone.

A second failure mode: shared Memory across specialists as a shadow CRM — operations team. Facts from tools. Conflicts to HITL.

What to do this week

1. Draw the five layers against your systems. Empty boxes are fine. Dual ownership is not.
2. Copy agent-memory-retention-policy.md. Name TTL and deletion job.
3. List fields that must never land in Memory (PAN, passwords, live ATP, live price).
4. Confirm shopper vs associate namespaces before you enable long-term Memory.
5. Add goldens: Memory must lose to a newer tool asOf.
6. Browser off. Model Memory events on the AgentCore pricing calculator.
7. Run monday-checklist.md. Contact us if Memory is currently your profile store.

What this post doesn’t cover

• HITL queue payload and fail-closed SLA — post 38
• Secrets, payment boundary, Cedar on writes — post 39
• Shopify / ERP / CRM tool catalog — post 60
• Measured personalization lift from long-term Memory on a named store — we are not inventing it
• AWS Context (still Coming soon as of the August 2026 ship map) as a Memory substitute

FAQ

When should we NOT enable long-term AgentCore Memory for a commerce agent?

Skip long-term Memory when facts already live in OMS, CRM, or PIM and the agent can call tools. Also skip it when you cannot name a deletion path that matches your privacy policy, or when shopper and associate sessions might share a namespace. Remembering everything is how you serve yesterday’s address as truth.

What could go wrong if Memory is treated as the CRM?

You store PII the CRM already owns, miss legal retention clocks, and leak preferences across shoppers if runtimeSessionId is reused or too short. Memory is conversational state. The profile store is CRM. The order store is OMS. Tools win when asOf on the system of record is newer.

When should we NOT store something in Memory even if it would help the next turn?

Do not store PAN, passwords, health data, government IDs, or raw card data — ever. Do not store live ATP or live price as Memory facts; they go stale. Do not store another shopper’s tickets in this session. Prefer a tool read with a freshness SLA.

What could go wrong if stale Memory beats a live OMS read?

The agent cites a shipped status from last week’s session while getShipment says delivered. Or it recommends a size the CRM updated. Rule: if asOf on the system of record is newer, trust the system. Goldens must fail when Memory contradicts a tool.

Can shopper JWTs retrieve associate Memory?

No. Namespace Memory by audience and shopper id. Identity JWT claims must reach the retrieval path. A shared Admin token plus Memory is a cross-customer incident waiting on the first reused session.

Does Harness Memory replace HITL ticket state?

No. Open approvals, last brief, and “already notified” belong in the ticket system with idempotency keys. Memory is not the operations ledger. HITL payloads still need session id plus tool trace.

Need a retention table before long-term Memory goes on? Contact FactualMinds or see Amazon Bedrock.