Skip to content

Brain Sources and Legacy Knowledge Bases

Brain Sources are the authored-source facet inside Memory. A policy document, a product FAQ, a runbook, an API reference — something authoritative that should be a source of truth when the agent answers a question, not a hallucinated guess. The Reliability operating guarantee lives here in a specific form: grounding the agent on a corpus you control means responses are reproducible against a known source, not synthesized from training-set memory the operator can’t audit.

Hosted ThinkWork retains authored Space documents into Hindsight as Brain Sources. Agents recall or reflect over the current Space’s Hindsight bank, so the source document, tags, observation scopes, and evidence travel with the memory record. Legacy Bedrock Knowledge Bases remain available when an operator explicitly attaches them as an external retrieval source.

Document knowledge is the right fit when:

  • The canonical answer lives in a document. Product documentation, standard operating procedures, compliance policies — places where “what does the document say?” is the right question.
  • You want citations. Every retrieved chunk is traceable back to a specific source file, so agents can cite what they used.
  • The content changes occasionally, not continuously. A runbook updated monthly is a good fit. A feed of live events is not.
  • You don’t want the agent inventing facts. Grounding reduces hallucination on questions where ground truth exists.

And it’s the wrong fit when:

  • The useful context is what this agent has learned across work — that’s Memory and compiled pages, not authored source documents.
  • The content is massive and sparsely relevant — a million-line codebase isn’t a knowledge base; it’s a search target for a different tool.
  • The question needs reasoning over a graph of entities — document chunks won’t reliably answer “which engineers owned which services in Q3.”

For the hosted Brain path, a Space document is retained into Hindsight with a stable document id, source context, tags, and observation scopes. When an agent works in that Space, its memory pass recalls or reflects over the Space bank:

User message -> Hindsight recall/reflect over Space bank -> source evidence -> model call

Concretely:

  1. The user or operator uploads an authored source into the Space’s Sources tab.
  2. ThinkWork retains the full source into the Space’s Hindsight bank with source metadata.
  3. The agent recalls relevant facts or asks Hindsight to reflect over the Space bank.
  4. Returned memories include evidence and source facts when requested.
  5. The model generates a response grounded in source-backed Space memory.

Legacy Bedrock KB retrieval still runs per-turn when a KB is explicitly attached, but it is no longer the default document-memory path.

Brain Sources are populated through ThinkWork document ingest, which calls Hindsight retain with the original source content. The retain request preserves the source context, stable document id, tags, and observation scopes so future recall/reflect calls can filter by Space, source type, and document identity.

A legacy Bedrock knowledge base is populated by syncing from an S3 bucket. You upload source documents (or point to an existing bucket the agent should read), and Bedrock’s ingestion pipeline:

  1. Chunks each document (configurable: fixed-size, semantic, hierarchical).
  2. Embeds each chunk using the KB’s configured embedding model.
  3. Writes the chunks + embeddings into the vector index.

ThinkWork configures the vector index to live in the same Aurora Postgres cluster as the rest of the system, via the pgvector extension. That means:

  • No separate vector database to run.
  • An Aurora snapshot restores both your agents’ state and their KB vector index in one shot.
  • Query latency is low because the KB index is colocated with everything else the turn needs.

Brain Sources are assigned by Space: add the source to the Space that should remember it. Agents operating in that Space can recall or reflect over the Space’s Hindsight bank without a per-agent KB attachment.

Legacy knowledge bases are assigned to the relevant runtime scope in the admin app or via the GraphQL API. In current Space-aware flows, attach focused KBs only to the Space or template that still needs Bedrock retrieval. Tenant-level inspection and upload flows live in Memory → Knowledge Bases.

The agent template can specify a default KB assignment — new agents created from that template inherit it. That makes fleet-wide KB rotation a single update to the template.

  • Hindsight retain is async in user flows. Large document ingest should report progress rather than blocking the operator on retention.
  • Use stable document ids. Re-uploading the same source with a new id weakens source continuity and deduplication.
  • Legacy KB sync is not real-time. Uploading a new document and immediately asking the agent about it will return “I don’t know” until the next sync runs.
  • Retrieval is not graph-aware by itself. Source recall can’t answer “which documents cite this one” — that’s a graph question, better served by compiled pages over authored content.
  • Memory — where authored sources sit relative to memory and compiled pages
  • Retained Memory — for agent-learned context, distinct from authored documents
  • Source Routing — how retrieved chunks combine with thread history and recalled memories at turn time
  • Admin: Memory — the operator surface for Hindsight memory, Brain Sources, pages, and legacy sources
  • Admin: Knowledge Bases — the legacy Bedrock KB compatibility surface
  • Architecture — where KBs fit in the data tier
  • Default backing service. Hindsight retain/recall/reflect, scoped by user and Space banks.
  • Source storage. Full source content is retained with stable document ids, tags, context, observation scopes, and source facts.
  • Runtime API. Agents use direct Hindsight recall/reflect for durable Brain memory; query_context is reserved for explicit lazy-loaded external context.
  • Legacy backing service. Amazon Bedrock Knowledge Bases, Aurora Postgres + pgvector, and bedrock-agent-runtime:Retrieve when explicitly attached.
  • Code path. ThinkWork-side orchestration lives under packages/api/src/; runtime memory and legacy retrieval integration live in packages/agentcore-pi/.