AgentCore Memory

AWS Bedrock AgentCore is a managed memory service — sessions, events, retrieval, summarization all server-side. agentfootprint’s AgentCoreStore maps the MemoryStore interface onto AgentCore’s session/event model so you can use it as a drop-in for InMemoryStore in production.

Install

npm install @aws-sdk/client-bedrock-agent-runtime

Lazy peer-dep declared in peerDependenciesMeta with optional: true. AWS credentials resolved via the standard SDK chain (env, profile, IAM role).

Subpath import

import { AgentCoreStore } from 'agentfootprint/memory-agentcore';

Subpath keeps the main barrel small + lets bundlers tree-shake when AgentCore isn’t used.

Use

examples/memory/09-agentcore-store.ts (excerpt — see full example)

const store = new AgentCoreStore({
  memoryId: 'arn:aws:bedrock:us-east-1:000000000000:memory/demo',
  _client: fakeClient,
});

const memory = defineMemory({
  id: 'agentcore-window',
  description: 'Last 10 turns persisted in AgentCore Memory.',
  type: MEMORY_TYPES.EPISODIC,
  strategy: { kind: MEMORY_STRATEGIES.WINDOW, size: 10 },
  store,
});

The store implements every MemoryStore method except search(). Pair with defineMemory({ store, ... }) like any other adapter.

Mapping to AgentCore primitives

MemoryStore call	AgentCore mapping
MemoryIdentity tuple	AgentCore sessionId (derived deterministically from identity)
MemoryEntry	AgentCore event payload (JSON envelope keyed by entry id)
put / putMany	PutMemoryEvent (sequentialized — no batch API)
get	GetMemoryEvent
list	ListMemoryEvents (cursor via nextToken)
delete	DeleteMemoryEvent
forget	DeleteMemorySession
seen / recordSignature	In-process shadow Map (NOT durable — see caveats)
feedback / getFeedback	In-process shadow Map (NOT durable)
search	NOT exposed — see caveats

Caveats (call out before adopting)

These are documented in the JSDoc; promoted here for visibility:

1. putIfVersion is emulated — AgentCore’s PutMemoryEvent overwrites unconditionally. The adapter does read-then-write inside a JS critical section. Adequate for single-writer-per-session deploys; weaker for multi-writer.

2. Built-in summarization may double-compress — AgentCore has its own server-side summarization. Mixing defineMemory({ strategy: SUMMARIZE }) on top will double-compress. Pick one summarizer.

3. seen / feedback are in-process — they don’t survive process restart. For durable recognition, use RedisStore instead (or layer Redis on top of AgentCore).

4. search() not exposed — AgentCore’s retrieval API is opaque (server-side retrieval pipeline). Mapping it to MemoryStore.search (cosine + threshold) would be a leaky abstraction. A separate agentcoreRetrieve() helper is planned for v2.5.

5. AWS rate limits apply — production deployments should wrap with withRetry and budget calls per session. AWS SDK has built-in retry; tune via the SDK’s maxAttempts config.

Test injection

AgentCoreStore({ _client: ... }) accepts a mock-injected client for tests — no live AWS account needed for CI:

const mockClient = {
  putEvent: async () => ({}),
  getEvent: async () => ({ payload: '...' }),
  listEvents: async () => ({ events: [] }),
  deleteEvent: async () => ({}),
  deleteSession: async () => ({}),
};

const store = new AgentCoreStore({ memoryId: 'test', _client: mockClient });

When to use AgentCore vs Redis vs InMemory

• Production AWS-native deployment — AgentCore is the natural choice if you’re already on Bedrock.
• Production multi-tenant with low latency + durable feedback — Redis (RedisStore).
• Dev / test / single-process — InMemoryStore.
• Hybrid — combine: AgentCore for causal snapshots; Redis for hot recent + feedback.

Next steps

• Memory store adapters — full adapter matrix
• Memory guide — types × strategies that pair with this store
• AWS Bedrock provider — paired LLM provider