Skip to content
ThinkWork ThinkWork

Memory

Memory is the context layer agents use before they act. It is not a single database, vector index, or chat-history trick. It is the ThinkWork-owned layer that decides what an agent should know for the current turn, where each fact came from, how fresh it is, and whether it is durable enough to carry forward.

The clean model is:

  • Threads keep the complete record of work.
  • Memory assembles the context that should matter now.
  • Agents reason and act using that assembled context.

That distinction matters. Threads answer “what happened?” Memory answers “what should the agent know before it responds or takes action?”

What It Contains

Section titled “What It Contains”

Memory is an umbrella over several source families. Operators see them together in Admin because they all affect what an agent can know, but each source keeps its own contract and provenance.

Retained Memory

Durable facts, preferences, and observations retained from prior work. Hindsight and AgentCore Memory are adapter implementations below the ThinkWork memory contract.

Pages

Compiled pages: entity, topic, and decision pages distilled from memory records and source citations.

Business Ontology

Tenant-governed business types, relationships, facet templates, and mappings that shape durable memory materialization.

Knowledge Bases

Operator-curated documents backed by Bedrock Knowledge Bases and Aurora pgvector. Best for policies, runbooks, product docs, and other authored source material.

Workspace Files

Permissioned files from an agent workspace, template workspace, or tenant defaults.

Approved MCP Tools

Read-only, search-safe external tools that an admin has explicitly allowed to participate in context lookup.

Source Routing

The internal query_context contract that fans out to eligible sources and returns normalized hits plus per-source status.

Why It Exists

Section titled “Why It Exists”

Most agent systems expose memory, RAG, workspace search, and external search as separate tools. That makes agents choose implementation details mid-turn and makes operators debug the wrong layer: was the answer bad because the memory engine missed, the KB was stale, or the agent never called the right tool?

Memory puts those sources behind one product boundary:

  • operators can inspect and test the sources together;
  • agents can ask for context without hard-coding every backend;
  • every hit carries provenance, source family, rank, freshness, and provider status;
  • backend choices can change without changing the product story.

How a Turn Uses Memory

Section titled “How a Turn Uses Memory”

At turn time, Memory can assemble context from recent thread history, memory recall, compiled pages, knowledge-base chunks, workspace files, and approved MCP tools. The router ranks and budgets those results before the model sees them.

User message arrives in a thread
        │
        ▼
  Memory source routing
        │
        ├─ Recent thread history
        ├─ Memory recall
        ├─ Compiled pages
        ├─ Knowledge-base chunks
        ├─ Workspace files
        └─ Approved MCP search tools
        │
        ▼
  Assembled context → model/runtime
        │
        ▼
  Response + tool calls → thread

Every source is optional. A focused support bot may only need a knowledge base. A long-running sales agent may use memory, compiled customer pages, workspace files, and approved operational search tools.

Trust and Provenance

Section titled “Trust and Provenance”

Memory treats source trust as a product concern, not a prompt afterthought.

  • Authored knowledge comes from operator-managed documents and keeps file/chunk citations.
  • Memory comes from prior work and keeps adapter/source references.
  • Ontology defines approved business meaning before it changes durable memory structure.
  • Compiled pages summarize many source facts and keep page-section provenance.
  • External MCP hits are transient unless a separate workflow promotes them.
  • Operational facets can be live and fresh, but should not be silently converted into durable narrative facts.

Admin Surface

Section titled “Admin Surface”

In Admin, Memory lives at /knowledge and has four tabs:

TabPurpose
MemoryBrowse, search, edit, and visualize retained memory records
PagesInspect compiled pages and graph/search output
Knowledge BasesManage Bedrock KBs, document uploads, and sync status
SourcesConfigure and verify the provider layer used by query_context

Ontology Studio lives under Manage → Ontology because it governs tenant-level business vocabulary rather than one source family. Operators use it to scan for suggestions, review change sets, approve definitions, and monitor reprocess jobs.

The route path still says /knowledge for compatibility, but the visible module name is Memory.

Section titled “Related Pages”