Separate the jobs
Conversation history preserves the exchange. Retrieval finds relevant passages. A structured memory layer maintains facts or beliefs. An agent runtime decides when to use those capabilities. Products combine these jobs in different ways.
Start by identifying the failure you need to fix: forgotten instructions, stale customer facts, exact historical lookups or knowledge moving between tools.
Run the same difficult examples
Give each candidate the same earlier decision, a later correction and a question in a fresh session. Ask for an exact identifier and its source. Introduce contradictory information. Test what a second user can see.
Measure whether the required evidence reaches the answer, how errors can be corrected and what the whole workflow costs. Include maintenance, state building and review time, not only the final model request.
Check ownership and exit
Ask whose memory it is, what stays tied to one application, what can be exported and what the exported representation preserves. A readable file is useful, but it may not include every relationship or operational behavior.
Check deletion and changed permissions on both original evidence and derived material. An export button does not answer those questions.
When to choose another approach
A native memory feature can be the simplest choice if you work mainly in one assistant. A notebook may be sufficient for a small, carefully maintained context. A retrieval service may be the right building block when your application already owns identity and workflow.
Evaluate thinqOS when a persistent, inspectable Mind across connected tools is valuable. Apply the same tests to it. This guide replaces a dated vendor scorecard with a repeatable evaluation; it does not claim a current ranking of named competitors.