Skip to content
ThinkWork ThinkWork

Admin — Memory

The Memory page is the operator hub for the context an agent can use. It combines memory records, compiled pages, Bedrock Knowledge Bases, workspace/source routing, and provider verification under one tabbed module.

Route: /knowledge
Tabs: Memory, Pages, Knowledge Bases, Sources

The route path still uses /knowledge for compatibility. The visible product/module name is Memory.

Why It Exists

Section titled “Why It Exists”

Agents draw context from several places:

  • durable memory, including Hindsight-backed memory when enabled;
  • compiled pages from the page compile pipeline;
  • Bedrock Knowledge Bases attached to the tenant, template, or agent;
  • workspace files scoped to an agent or template;
  • approved MCP context tools.

Memory keeps source inspection and source routing close together. Operators can look at the raw source, then run the same backend query path agents use through query_context.

Tabs

Section titled “Tabs”
TabPurpose
MemoryBrowse and search retained memory records; view the Hindsight graph when available
PagesInspect compiled pages and graph/search output
Knowledge BasesManage Bedrock KBs, document uploads, and sync status
SourcesConfigure and verify the source layer used by query_context

The old standalone routes redirect into the matching tab:

Old routeCurrent route
/memory/knowledge/memory
/wiki/knowledge/wiki
/knowledge-bases/knowledge/knowledge-bases

Sources Query Test

Section titled “Sources Query Test”

The Sources tab includes a safe query harness for operator verification. It is intended for dogfooding source behavior before testing through a full agent chat.

The harness controls are:

  • Sources — multi-select dropdown for provider families such as Hindsight Memory, compiled pages, workspace files, Bedrock Knowledge Bases, and approved MCP tools.
  • Agent target — optional agent picker used when workspace files or agent-scoped attachments should participate in the test.
  • Hindsight strategy — recall for direct memory-record retrieval or reflect for synthesized memory output.
  • Search — natural-language query field.

Results show provider statuses and top hits side by side. Clicking a hit opens a formatted markdown preview plus the raw structured hit. Clicking View full result opens the complete query_context response. Provider failures should be local: a skipped Bedrock KB or slow Hindsight call should not hide successful page or workspace hits.

Template Configuration

Section titled “Template Configuration”

Agent Templates expose Memory as a built-in tool alongside Code Sandbox, Browser Automation, Web Search, and Send Email. Enabling it injects the platform-owned query_context tool into supported runtimes.

Template configuration can choose which tenant-approved sources participate by default and can expose source-specific options such as Hindsight strategy. Normal agent configuration should show Hindsight as a Memory source, not as a separate peer tool. Raw Hindsight tools may still exist for diagnostics, but the operator-facing path is Memory.

Operational Guidance

Section titled “Operational Guidance”
  • Use the Sources tab first when debugging provider behavior. It gives provider-level latency, hit counts, skipped states, and partial failures without model/tool-selection noise.
  • Select an agent target when testing workspace files. Workspace search needs the agent workspace scope to find files such as USER.md.
  • Use reflect for answer-like memory verification and recall when debugging raw memory retrieval.
  • Use Pages when you want the durable compiled view of what an agent has learned; use Memory when you need the raw retained records.
  • Use Knowledge Bases for authored, operator-curated documents that should remain distinct from learned memory.
Section titled “Related Pages”