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

AWS lifecycle notice (June 30, 2026) — Amazon Bedrock Agents Classic is in maintenance for new customers after July 30, 2026. Net-new agents should use Bedrock AgentCore. Full matrix: lifecycle roundup.

On June 17, 2026, 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.

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.

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

First-party signals we reuse (not eCommerce outcomes) — 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 TCO silhouette: support-style AgentCore at 50K sessions/mo ~$791/mo platform + model (decision guide). Memory events and retrievals are extra AgentCore lines — model them on the AgentCore pricing calculator. They are not “smarter commerce.”

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

Opinionated take: prefer tools over Memory for facts (price, ATP, order status, policy version). Use Memory for conversation continuity that those systems do not hold. Trade-off: an extra getOrder each turn. You avoid a polite agent that is confidently a week out of date.

FactualMinds helps merchants connect agents to storefronts and back-office systems — with Memory treated as a bounded notebook, not a second CRM.

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.

How this sits on AWS

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 30 July 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.

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.”

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.

What broke

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 you NOT enable long-term AgentCore Memory for a commerce agent?

Skip it when tools already return the facts, when you have no deletion path, or when shopper and associate namespaces are not split. Remembering everything is not desirable.

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

Shadow PII, missed retention clocks, cross-shopper leak. Memory is conversational state. CRM is the profile store.

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

PAN, passwords, health data, live ATP, live price, other shoppers’ tickets. Prefer a tool read.

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

Wrong status, wrong address, wrong size. If asOf on the system of record is newer, trust the system.

Can shopper JWTs retrieve associate Memory?

No. Namespace by audience and shopper id. Identity still matters after export.

Does Harness Memory replace HITL ticket state?

No. Approvals and notify keys belong in the ticket system. Memory is not the operations ledger.

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