AWSArchitecture

AgentCore Memory IngestData: A UK Playbook for Direct Long-Term Memory

Sep 8 2026: AgentCore Memory IngestData extracts long-term memory without creating a short-term event. UK playbook for payloads, verify/redrive and GDPR minimisation.

AQ
Ali Qaiser
AWS Certified | ServiceNow Architect | Enterprise AI Consultant
13 September 2026
8 min read
AgentCore Memory IngestData: A UK Playbook for Direct Long-Term Memory
In brief

Sep 8 2026: AgentCore Memory IngestData extracts long-term memory without creating a short-term event. UK playbook for payloads, verify/redrive and GDPR minimisation.

Key Takeaways
  • IngestData submits conversational or JSON content for LTM extraction without a short-term event.
  • Verify with List/RetrieveMemoryRecords; stream creates via Kinesis; redrive failures with List/StartMemoryExtractionJob.
  • Use IngestData when you already retain raw interactions or only need distilled records — CreateEvent when you need STM replay.
  • UK GDPR: minimise raw retention in AgentCore, purpose-limit strategies, and align actorId to erasure runbooks.
  • 14-day path: pattern choice → ingest pilot → ops/redrive → DPO/cyber assure.

Long-term memory without short-term clutter — a UK AgentCore pattern

On 8 September 2026, AWS announced that Amazon Bedrock AgentCore Memory can accept content for long-term memory (LTM) extraction via IngestData — without first persisting a short-term memory event. Until now, extraction strategies typically required content to land as a short-term event before it could become durable memory records. Direct ingest lets UK teams adopt LTM independently of short-term event storage.

That matters for estates that already keep transcripts in their own systems of record, or that want preferences and structured facts without retaining another copy of the raw conversation inside AgentCore short-term memory.

Cloud AI infrastructureCloud AI infrastructure

What IngestData is — and is not

IngestData submits content to a memory resource. A successful call means the content was accepted for asynchronous processing. Extracted LTM records become available through the same retrieval APIs you already use: ListMemoryRecords, RetrieveMemoryRecords, GetMemoryRecord.

Payload types:

  1. Conversational — messages with roles such as USER / ASSISTANT and text content.
  2. JSON — behavioural events, activity logs, system events, preference objects.

You can attach optional metadata that feeds the same structured-metadata extraction path used with CreateEvent. Content is scoped by namespace, actorId (end user or agent) and sessionId. Sharing the same actor/session/namespace treats content as related context during extraction. Configured LTM strategies receive the fan-out — except self-managed strategies, which keep their own processing workflows.

What IngestData is not:

  • It does not create a short-term event. You cannot later GetEvent / ListEvents / ListSessions that content, or reorganise it with branching the way you would for stored events.
  • It is not a synchronous "memory is ready" API — verify extraction after processing.
  • It does not replace your application-of-record for audit trails if you still need verbatim interactions.

If you need the raw interaction as a retrievable short-term event, keep using CreateEvent.

Why UK boards and platform owners should care

ConcernWhy IngestData helps
GDPR data minimisationAvoid storing a second copy of raw dialogue in short-term memory when you only need distilled facts
Purpose limitationSeparate "extract preferences" pipelines from "keep full session for replay"
Cost / storage hygieneSkip short-term overhead for content you would never read back from AgentCore
Agent reliabilityPopulate LTM from CRM events / JSON signals, not only chat turns
OpsKinesis notifications + extraction-job redrive give a production control loop

Architecture sketch for UK estates

[App / CRM / workflow events]
        |  conversational or JSON (+ optional metadata)
        v
   IngestData  --->  LTM strategies (configured on memory)
        |                 |
        |                 +--> memory records (namespace-scoped)
        |                 +--> optional Kinesis notify
        v
   Verify: List / RetrieveMemoryRecords
   Failures: ListMemoryExtractionJobs -> StartMemoryExtractionJob (redrive)

Implementation notes from the developer guide:

  • Use the Bedrock AgentCore data-plane client (ingest_data) with memoryId, actorId, sessionId, contentTimestamp, and an inline.payload array mixing conversational and JSON items as needed.
  • After ingest, records typically appear within seconds to minutes depending on content size and strategy configuration.
  • Configure a Kinesis stream for real-time create notifications when you need event-driven UX or audit hooks.
  • On failure, AgentCore queues failed jobs per memory resource — list them, fix the root cause, then StartMemoryExtractionJob to redrive. Pair with CloudWatch FailedExtraction and application logs/traces for observability.

UK GDPR and security checklist

Treat LTM as personal data when it can identify a natural person (preferences, behavioural JSON, loyalty identifiers, support context).

  1. Minimise raw retention in AgentCore — prefer IngestData when verbatim short-term storage is unnecessary.
  2. Purpose limitation — document why each strategy extracts what it extracts; avoid "ingest everything."
  3. Lawful basis & DPIA — update AI / agent DPIAs for LTM namespaces that hold customer or employee data.
  4. Retention & deletion — define how memory records are expired or deleted when the subject requests erasure; map actorId to your identity model.
  5. Access control — IAM least privilege on ingest and retrieve; separate roles for ops redrive vs application write.
  6. Cross-border — confirm AgentCore Memory region choice against your UK/EU residency commitments.
  7. Vendor / subprocessors — keep the AWS processing description aligned with your Article 28 pack.

14-day UK action checklist

Days 1–3 — Decide the pattern

  • Inventory which agents need LTM only vs full short-term sessions.
  • Pick one low-risk pilot (e.g. seat/meal preferences or non-sensitive ops JSON).
  • Confirm memory strategies and namespaces for that pilot.

Days 4–7 — Implement ingest

  • Wire IngestData with conversational + one JSON payload and optional metadata.
  • Emit contentTimestamp, stable actorId / sessionId.
  • Add verification polls via ListMemoryRecords / RetrieveMemoryRecords.

Days 8–11 — Production ops

  • Attach Kinesis notifications for record-created events.
  • Enable FailedExtraction monitoring; rehearse ListMemoryExtractionJobs → StartMemoryExtractionJob.
  • Document redrive runbook for on-call.

Days 12–14 — Assure

  • DPO / cyber review: minimisation, retention, access logs.
  • Promote behind a feature flag; keep CreateEvent path for journeys that still need short-term replay.
  • Soft CTA: if you want an architecture review of AgentCore Memory vs your existing transcript store, AIATS Free Evaluation is available for UK teams.

Risks and anti-patterns

Anti-patternBetter approach
Ingesting full PII dumps "just in case"Curate JSON fields; strip identifiers not needed for the strategy
Assuming ingest = records readyExplicit verify + Kinesis
Ignoring failed extraction queuesRedrive playbook + CloudWatch alarms
Mixing unrelated actors in one sessionIdStable identity model per subject
Relying on IngestData for audit verbatimKeep system-of-record transcripts separately

Closing

IngestData is a small API with a large operating-model implication: UK agent platforms can grow long-term memory without forcing every signal through short-term event storage. Use it where minimisation and cost hygiene matter; keep CreateEvent where replay and branching still matter; and treat extraction failures as first-class ops.

Docs to keep open while you build: the long-term ingest guide and the 8 Sep 2026 What's New note.

Worked example (Python data plane)

The following pattern mirrors the public developer guide: mix conversational turns with a structured JSON preference object in one ingest.

import boto3
from datetime import datetime

data_client = boto3.client('bedrock-agentcore', region_name='eu-west-2')

response = data_client.ingest_data(
    memoryId='mem-uk-pilot-001',
    actorId='customer-gb-123',
    sessionId='session-renewal-456',
    contentTimestamp=datetime.utcnow(),
    source={
        'inline': {
            'payload': [
                {
                    'conversational': {
                        'content': {'text': 'I prefer window seats on flights.'},
                        'role': 'USER'
                    }
                },
                {
                    'conversational': {
                        'content': {'text': "Noted — I'll remember your window seat preference."},
                        'role': 'ASSISTANT'
                    }
                },
                {
                    'json': {
                        'content': {
                            'customer_tier': 'gold',
                            'preferences': {'seat': 'window', 'meal': 'vegetarian'},
                            'loyalty_points': 48200
                        }
                    }
                }
            ]
        }
    }
)
print('Ingested into session:', response['sessionId'])

UK note: pin the region to your residency choice (eu-west-2 / eu-west-1 as appropriate), keep actorId aligned to your IdP subject, and avoid packing unnecessary loyalty or CRM fields into JSON if the strategy does not need them.

Verification and redrive runbook (ops-ready)

  1. Accept — IngestData returns success → content accepted, not yet guaranteed extracted.
  2. Wait — seconds to minutes depending on size and strategies.
  3. Verify — ListMemoryRecords / RetrieveMemoryRecords for expected namespace facts.
  4. Notify — Kinesis stream for record-created events into your observability bus.
  5. Fail — watch FailedExtraction; ListMemoryExtractionJobs for the memory resource.
  6. Fix — payload shape, strategy config, IAM, or content quality issues.
  7. Redrive — StartMemoryExtractionJob after the root cause is cleared.
  8. Evidence — retain job IDs and timestamps for change / incident tickets (UK regulated teams will ask).

When to choose IngestData vs CreateEvent

NeedPrefer
Distilled preferences / facts onlyIngestData
Already store verbatim transcripts elsewhereIngestData
Must replay / branch short-term sessionsCreateEvent
Debugging conversational state with GetEventCreateEvent
Hybrid: LTM from CRM JSON + STM for live chatBoth — split by pipeline
Expert Commentary

Direct LTM ingest is a data-minimisation win for UK agent estates — but only if verification, redrive and retention are designed as products, not afterthoughts.

Topics
AWSAmazon BedrockAgentCoreMemoryIngestDataLong-Term MemoryKinesisGDPRUKAI Agents
All insights

Need Help With Your Implementation?

Get expert guidance from our certified ServiceNow and AWS architects.

Schedule a Consultation