Supermemory Profiles vs Query Recall

A user tells your assistant to write short status updates. Next week they ask, "Draft the update." They do not mention length. Should the preference appear because every request loads a profile, or because retrieval finds it relevant?

Supermemory has a dedicated profile endpoint. MemoryRouter's prepare endpoint searches using the conversation you send it.

Supermemory removed the question from profiles

Supermemory's current user profile guide describes a maintained profile. profile.static holds long-lived facts, such as a user's profession or communication preferences. profile.dynamic holds recent context, such as an active project. Topical categories live in profile.buckets. Profile entries are { id, memory } objects, not strings.

An application requests that profile at POST /ns/{namespace}/profile, with the user or project identifier in the path. It can load the result before each model call without needing a search query. That is useful when the assistant should start with a maintained picture of the person, even on a loosely worded request.

The v5 migration guide makes the separation explicit. The older POST /v4/profile accepted q for query-based search. The namespace-scoped v5 profile call removes that search behavior. For question-specific retrieval, the application makes a separate search request to POST /ns/{namespace}/search.

This is not a loss of search from Supermemory. It is a split into two operations. If your integration previously expected one response to contain both, changing the endpoint without changing the prompt assembly leaves out part of the context.

MemoryRouter prepares context from this conversation

I built MemoryRouter for conversational context that remains available after a session ends or its context gets compacted. In an application that owns the model call, POST /v1/memory/prepare takes the conversation's messages. It builds a retrieval query from recent non-system turns and returns a context string for your prompt.

You do not supply a separate query to prepare. But the call is still retrieval driven by a conversation, not a request for a standing user profile. The local inference documentation describes this contract, including context: null when retrieval finds nothing relevant.

That difference should affect your implementation. Do not assume a brief instruction about writing will retrieve every saved style preference. Inspect the returned context with your actual requests. If your product requires a fixed preference on every turn, keep an explicit application-controlled copy in the prompt rather than treating relevance ranking as a guarantee.

MemoryRouter also exposes /v1/memory/search when you want to specify the query yourself. Neither documented call is a drop-in replacement for Supermemory's maintained static and dynamic profile arrays.

Compare the prompt inputs, not endpoint names

Prompt input you need	Supermemory	MemoryRouter
A standing picture of the user	`/ns/{namespace}/profile` returns static, dynamic and bucketed entries	Prepare does not document that profile shape
Context relevant to this request	Separate `/ns/{namespace}/search` call	Prepare derives retrieval from supplied messages; search accepts an explicit query
New conversation available later	Add memories through Supermemory's ingestion flow	Ingest the completed exchange after the model responds

Choose Supermemory when a maintained profile is a requirement of the product you are building. Give its profile and its search results separate places in your prompt assembly. A metadata filter narrows which memories a profile uses; it does not restore the removed query parameter.

Choose MemoryRouter when you want to carry the substance of earlier conversations into the work your assistant is doing now. Your application can retrieve that context while keeping its existing model-provider integration. It sends completed exchanges to ingest so later conversations have something to retrieve. The Supermemory comparison page covers the broader product choice.

Evaluate a preference and an explanation separately

Before choosing, seed a disposable user's memory with two synthetic records. Allow background ingestion to finish, then start a new conversation without the seeded text in its messages. One record is the short-status-update preference. The other explains why a particular supplier was rejected: its replacement parts require an unavailable adapter.

First ask for a status update without mentioning style. With Supermemory, inspect the profile response for the preference. With MemoryRouter, inspect prepare's context. Score whether the preference actually reached the model, separately from whether the generated update happened to be short.

Then ask why that supplier was rejected. Inspect the query-specific retrieval for the adapter explanation. A useful profile is not proof that an old decision's rationale will reach the prompt. Record which call supplied each piece, and check that your application really injected both responses where intended.

Create a MemoryRouter vault and inspect the context returned for one question about an earlier conversation.