Retrieval and Context

A ThinkWork turn is assembled from multiple context sources, not just the latest user message.

This page is about that assembly step.

Context sources

Depending on configuration, a managed agent may receive:

the current thread message
recent thread history
retrieved document passages
recalled long-term memories
skill instructions and tool definitions
connector metadata from the source system

The clean model

ThinkWork separates these concerns on purpose:

Threads hold the canonical record of work
Memory provides useful retrieved context
Agents decide how to act on that context

That keeps the product model cleaner than treating every source as just another prompt blob.

Turn assembly

A typical turn looks like this:

Current message
  + recent thread history
  + retrieved document chunks
  + recalled long-term memories
  + tool and policy context
  = model input for this turn

The exact mix depends on the agent template, selected memory engine, retrieval configuration, and deployment settings.

What should stay stable

Even as backends change, these rules should stay true:

thread history is the short-term and session context source
document retrieval is one context input, not the whole product
long-term memory recall comes through ThinkWork’s memory contract
the harness decides how context is assembled for the turn

That is the real retrieval story. Not a backend hostname. Not a specific vector store. Not one vendor’s memory API.

Current implementation shape

Today, the main context inputs are:

thread history from the ThinkWork thread store
document retrieval through Bedrock Knowledge Bases when enabled
long-term recall through the selected memory engine adapter

ThinkWork may expand retrieval controls over time, but this is the durable mental model to build against.