Retained Memory

Retained memory is the part of Memory that carries learned context forward across work. Unlike authored knowledge bases, retained memory starts from what the agent has observed during interactions: a user preference the agent noticed, a decision made in an earlier thread, a fact the agent confirmed and needs again.

The design decision that matters most — and the load-bearing implementation of the Reliability operating guarantee at the memory layer — is this: ThinkWork owns the memory contract; the engine underneath is pluggable. Agents, tools, and compiled Memory pages all read from the same interface regardless of whether the backing engine is Hindsight or AgentCore Memory. Swap the engine; the agents that consume memory do not change.

What long-term memory is for

Memory is the right place for things like:

• User or team preferences. “Marco prefers Slack over email.” “This team’s code reviews should cite the style guide.”
• Durable facts worth recalling across threads. “The Austin office moved to 2nd and Lavaca.” “Our incident post-mortems live in /docs/incidents/.”
• Ongoing project context. “The backend migration ships in Q3, not Q2.”
• Summaries of earlier work. “Last month we decided to use Hindsight as the primary memory engine.”
• Follow-up items. “The customer asked about billing reports — still pending response.”

It’s not the right place for:

• Verbatim thread transcripts. That’s what the thread record is for.
• Authored source material. That’s document knowledge.
• The wiki. The wiki is derived from memory — it’s a layer above, not memory itself.

Why the contract matters

Imagine ThinkWork hard-coded one memory engine. Every agent, tool, skill pack, and wiki compile would be coupled to that engine’s API. Swapping engines — or running two in parallel for different deployments — would ripple through the system.

Instead, the harness exposes a stable contract:

• retain(event) — a post-turn side effect that the engine can use to extract learnings. Adapters implement this differently (AgentCore Memory does background strategy extraction; Hindsight does reflection).
• recall(query, ownerId, k) — retrieve relevant prior memories for a given owner and query.
• inspect(ownerId) — list / browse / search memories. Used by the admin UI and the wiki compile pipeline.
• export(ownerId) — a durable export format. Used for backups and for migrating between adapters.

Agents call the contract. Tools call the contract. The Memory compile pipeline calls inspect. Swapping from Hindsight to AgentCore Memory does not require changing any caller — only the adapter implementation changes.

Tip

The contract is the stable part. The engine is pluggable. When you’re thinking about memory in ThinkWork, think in terms of the contract operations first — then figure out which engine your deployment happens to use.

The two adapters today

ThinkWork supports two long-term memory adapters. Exactly one is canonical per deployment — you don’t mix them within a single deployment.

Hindsight — hosted default

Hindsight is the richer adapter and the default for hosted ThinkWork. It runs as an ECS Fargate service in your VPC (opt-in via enable_hindsight = true in Terraform) and offers:

• Semantic recall with strong precision tuning.
• Entity extraction from retained events — names, places, decisions surfaced automatically.
• Reflection primitives — the engine can introspect its own memories and synthesize higher-order facts.
• A cursor API for incremental reads — the compounding-memory pipeline uses this to process new memories into the wiki.

Hindsight is the better fit when you want:

• Stronger inspectability (an operator can browse memories with rich metadata).
• Structured entity data flowing into downstream systems (including the wiki).
• Reflection and summarization built into the memory layer, not bolted on.

The cost: Hindsight is an ECS service, so you’re running a (small) long-lived container in your account. That’s not zero operational cost, and it’s a different mental model from pure-Lambda deployments.

AgentCore Memory — serverless-friendly

AgentCore Memory is the serverless-native alternative. It’s a managed AWS service — no container to run — with four built-in strategies that extract learnings automatically:

• Semantic — durable facts.
• Summarization — rolling summaries of thread clusters.
• User preference — preferences inferred from interactions.
• Episodic — chronological episodes.

Every agent turn auto-emits a CreateEvent after completion; the background strategies process that stream without ThinkWork having to orchestrate them.

AgentCore Memory is the better fit when you want:

• A pure-serverless deployment with nothing long-lived to run.
• AWS-managed primitives rather than another service to operate.
• Lower infrastructure sprawl.

The cost: AgentCore Memory’s strategies are what they are — less tunable than Hindsight’s engine, and the compile pipeline currently only runs against Hindsight because Hindsight’s cursor API is what the compile job consumes. AgentCore Memory tenants will not have compiled pages in v1.

Practical differences

A side-by-side of what matters in practice:

Dimension	Hindsight	AgentCore Memory
Deployment shape	ECS Fargate service	AWS-managed, nothing to run
Opt-in	enable_hindsight = true	Always on with AgentCore
Cursor reads (for wiki compile)	Yes	Not in v1
Entity extraction	Yes, into structured metadata	Via semantic strategy, less structured
Reflection	Yes	Via summarization strategy
Best for	Rich memory + wiki	Lean serverless deployments

Hosted ThinkWork defaults to Hindsight precisely because compiled pages are a first-class feature there. Self-hosted deployments that want the simplest infra and do not need compiled pages today can run AgentCore Memory and add Hindsight later if the needs shift.

Short-term vs. long-term, again

Worth repeating: short-term context comes from thread history. Long-term memory is the selective carry-forward. Memory should help the system avoid rereading everything; it should not pretend to be the thread record. This distinction is the reason memory is cheap to re-query while thread history is the audit source of truth.

Known limits

• One engine per deployment. You can’t run Hindsight for some tenants and AgentCore Memory for others in the same deployment. The adapter is deployment-scoped.
• Adapter swaps are possible but not automatic. Exporting from one adapter and importing into another works via the export contract, but it’s a manual migration, not a hot swap.
• Compiled pages only run on Hindsight today. AgentCore Memory tenants can use ThinkWork’s core memory layer but do not get compiled Memory pages in v1.
• Recall quality depends on the engine. The contract guarantees the interface, not equivalent results. Queries that return great matches on Hindsight may return less-relevant results on AgentCore Memory; tune per adapter.

Related pages

• Memory — the umbrella
• Sources and Knowledge Bases — what memory isn’t
• Compiled Memory Pages — what’s built on top of the memory layer
• Source Routing — where memory sits in turn assembly
• Operating Compiled Memory Pages — recipes that depend on the memory contract

Under the hood

• Contract interface. packages/api/src/lib/memory/types.ts — the TypeScript interface every adapter implements.
• Hindsight adapter. packages/api/src/lib/memory/adapters/hindsight-adapter.ts — HTTP client against the ECS service.
• AgentCore Memory adapter. packages/api/src/lib/memory/adapters/agentcore-adapter.ts — Bedrock AgentCore Memory SDK wrappers.
• Adapter selection. packages/api/src/lib/memory/index.ts — picks the adapter based on deployment config (enable_hindsight flag + tenant memory_adapter column).
• Retention event. Emitted from the AgentCore runtime (packages/agentcore-strands/agent-container/) after every turn to whichever adapter is active.
• Tenant column. tenants.memory_adapter — set by the admin app; default matches the deployment’s enable_hindsight flag.