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.

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.
- 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 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:
- Conversational — messages with roles such as
USER/ASSISTANTand text content. - 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/ListSessionsthat 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
| Concern | Why IngestData helps |
|---|---|
| GDPR data minimisation | Avoid storing a second copy of raw dialogue in short-term memory when you only need distilled facts |
| Purpose limitation | Separate "extract preferences" pipelines from "keep full session for replay" |
| Cost / storage hygiene | Skip short-term overhead for content you would never read back from AgentCore |
| Agent reliability | Populate LTM from CRM events / JSON signals, not only chat turns |
| Ops | Kinesis 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) withmemoryId,actorId,sessionId,contentTimestamp, and aninline.payloadarray 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
StartMemoryExtractionJobto redrive. Pair with CloudWatchFailedExtractionand 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).
- Minimise raw retention in AgentCore — prefer IngestData when verbatim short-term storage is unnecessary.
- Purpose limitation — document why each strategy extracts what it extracts; avoid "ingest everything."
- Lawful basis & DPIA — update AI / agent DPIAs for LTM namespaces that hold customer or employee data.
- Retention & deletion — define how memory records are expired or deleted when the subject requests erasure; map actorId to your identity model.
- Access control — IAM least privilege on ingest and retrieve; separate roles for ops redrive vs application write.
- Cross-border — confirm AgentCore Memory region choice against your UK/EU residency commitments.
- 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
IngestDatawith conversational + one JSON payload and optional metadata. - Emit
contentTimestamp, stableactorId/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
CreateEventpath 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-pattern | Better approach |
|---|---|
| Ingesting full PII dumps "just in case" | Curate JSON fields; strip identifiers not needed for the strategy |
| Assuming ingest = records ready | Explicit verify + Kinesis |
| Ignoring failed extraction queues | Redrive playbook + CloudWatch alarms |
| Mixing unrelated actors in one sessionId | Stable identity model per subject |
| Relying on IngestData for audit verbatim | Keep 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)
- Accept —
IngestDatareturns success → content accepted, not yet guaranteed extracted. - Wait — seconds to minutes depending on size and strategies.
- Verify —
ListMemoryRecords/RetrieveMemoryRecordsfor expected namespace facts. - Notify — Kinesis stream for record-created events into your observability bus.
- Fail — watch
FailedExtraction;ListMemoryExtractionJobsfor the memory resource. - Fix — payload shape, strategy config, IAM, or content quality issues.
- Redrive —
StartMemoryExtractionJobafter the root cause is cleared. - Evidence — retain job IDs and timestamps for change / incident tickets (UK regulated teams will ask).
When to choose IngestData vs CreateEvent
| Need | Prefer |
|---|---|
| Distilled preferences / facts only | IngestData |
| Already store verbatim transcripts elsewhere | IngestData |
| Must replay / branch short-term sessions | CreateEvent |
| Debugging conversational state with GetEvent | CreateEvent |
| Hybrid: LTM from CRM JSON + STM for live chat | Both — split by pipeline |
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.

