Skip to main content

Use remembered preferences in a returning user’s conversation

Section: DOC-MA-memory-knowledge#remember-users-across-conversations.

Help a returning user continue with relevant preferences or context from earlier conversations. When memory is enabled, search for the records relevant to the new question, review their freshness and correct outdated information. Treat remembered statements as fallible records, since they can be stale or inaccurate.

Access limitation: complete ownership checks for by-ID reads and changes are not yet established for every deployment. Use isolated test data for those operations until your operator confirms they are safe for your intended users. Travila must enforce that boundary; an ID or memory setting cannot supply the missing protection.

Recipe: let a returning user review the preferences available to the assistant, correct an outdated record and continue the conversation with relevant context. Start with controlled records in one authorized user scope. This recipe cannot remove the by-ID access limitation above; use those operations only in an operator-qualified deployment or isolated test data.

You need the user's authenticated scope, enabled memory service and permission for the retrieval/extraction you select. Keep correction and deletion controls visible to the user instead of treating memory as unquestionable truth.

Choose a small recall-and-review flow​

Section: DOC-MA-memory-knowledge#get-started.

Use a small recall-and-review flow:

StepYour application doesThe user can check
RecallSearch for preferences relevant to the question.The returned statements and their freshness.
ReviewOffer correction or removal where by-ID access is qualified.Whether each remembered statement is still accurate.
ContinueRetrieve context only for the permitted audience.A reply grounded in relevant, reviewed context.
ExtractObtain permission for later memory extraction.What the application will remember next.

An empty search can mean no matches or a handled search-provider failure; it does not establish that no memories exist. It is not a reason to invent a preference. A relevant result is still a fallible statement, and a high relevance score is not proof that it is true.

Before the first lookup: select the authenticated user​

Section: DOC-MA-memory-knowledge#user-impersonation.

Derive the intended user from your authenticated application session. For the search request below, use a backend API key with users:impersonate and set X-On-Behalf-Of to that user. Keep the same authorized scope through the recipe.

A changed header or memory ID is not permission to access someone else’s records. This header does not remove the by-ID limitation stated above.

Step 1: Find the preferences relevant to the question​

Section: DOC-MA-memory-knowledge#searching-memories.

For a meal-planning follow-up, search for dietary preferences. Show the retrieved statements with their available timestamps so the user can recognize stale or incorrect information.

Choose a bounded number of relevant matches for the review screen, then inspect the returned memory records and their freshness.

curl -X POST https://api.travila.ai/api/v1/llm/search-memories \
  -H "X-API-Key: sk_your_key_here" \
  -H "X-On-Behalf-Of: user_123" \
  -H "Content-Type: application/json" \
  -d '{
  "query": "dietary preferences",
  "topK": 10
}'

Reference: Semantic search over memories · Request fields.

Response:

{
  "memories": [
    {
      "id": "mem_abc123",
      "memory": "User is vegetarian and avoids gluten",
      "score": 0.92,
      "createdAt": "2025-02-15T10:00:00Z",
      "updatedAt": "2025-02-15T10:00:00Z"
    },
    {
      "id": "mem_def456",
      "memory": "User prefers meals under 500 calories",
      "score": 0.85,
      "createdAt": "2025-02-20T14:30:00Z",
      "updatedAt": "2025-02-20T14:30:00Z"
    }
  ]
}

Reference: Semantic search over memories · Response fields.

ResultWhat to do next
Relevant recordsShow the statements and timestamps; let the user correct stale information.
Empty resultContinue with user-supplied context. Do not conclude that no memories exist: a handled provider failure can also return an empty result.
Request errorTell the user recall is unavailable and continue only with context they supply.

Step 2: Let the user review the stored records​

Section: DOC-MA-memory-knowledge#listing-memories.

A search returns relevant matches, not an inventory. For a review screen, list records in the authenticated user’s scope and let the user inspect the returned statements.

Explain that this capped list may not be the complete memory inventory before offering a review or deletion workflow.

curl -X POST https://api.travila.ai/api/v1/llm/list-memories \
  -H "X-API-Key: sk_your_key_here" \
  -H "X-On-Behalf-Of: user_123" \
  -H "Content-Type: application/json" \
  -d '{
  "limit": 100
}'

Reference: List user memories · Request fields.

Inspect the selected record before changing it​

Section: DOC-MA-memory-knowledge#getting-a-specific-memory.

Use the selected record ID only where by-ID ownership checks are qualified. Read the record the user wants to correct, confirm that it is the intended statement, then use the update or deletion step. On an unqualified deployment, keep this to isolated records and use the operator's supported correction route for real users.

curl -X POST https://api.travila.ai/api/v1/llm/get-memory \
  -H "X-API-Key: sk_your_key_here" \
  -H "X-On-Behalf-Of: user_123" \
  -H "Content-Type: application/json" \
  -d '{
  "memoryId": "mem_abc123"
}'

Reference: Get a specific memory · Request fields.

Step 3: Correct an outdated preference​

Section: DOC-MA-memory-knowledge#updating-a-memory.

After the user confirms the replacement wording, update that record. The example adds a preference to the existing statement; it is a user-declared record, not medical advice or a verified diagnosis.

curl -X POST https://api.travila.ai/api/v1/llm/update-memory \
  -H "X-API-Key: sk_your_key_here" \
  -H "X-On-Behalf-Of: user_123" \
  -H "Content-Type: application/json" \
  -d '{
  "memoryId": "mem_abc123",
  "text": "User is vegetarian, avoids gluten, and prefers organic produce"
}'

Reference: Update a memory · Request fields.

Read the record back in the qualified scope to confirm the stored text. If the write response is lost, inspect the existing record before repeating it; keep the correction unresolved until its outcome is known.

Alternative: remove a statement the user no longer wants​

Section: DOC-MA-memory-knowledge#deleting-memories.

Use single-record deletion for a selected memory. Treat account erasure as a separate request: deleting one match or one list page cannot establish that every retained or derived copy is gone.

Remove the selected record​

Section: DOC-MA-memory-knowledge#delete-a-single-memory.

curl -X POST https://api.travila.ai/api/v1/llm/delete-memory \
  -H "X-API-Key: sk_your_key_here" \
  -H "X-On-Behalf-Of: user_123" \
  -H "Content-Type: application/json" \
  -d '{
  "memoryId": "mem_abc123"
}'

Reference: Delete a memory · Request fields.

Keep the selected record and request context until its outcome is known. Do not report account erasure from this operation; the bulk-removal limitation below still applies.

Deleting every memory at once​

Section: DOC-MA-memory-knowledge#deleting-every-memory-at-once.

There is no public bulk-delete endpoint. Deleting the IDs returned by one search or list does not confirm account erasure: other memories or pending extraction can remain. For an account-erasure request, contact your account administrator or support using the privacy request guidance. Ask for the scope and completion status; Travila is responsible for coordinating its retained and derived copies.

Step 4: Include relevant memory in later replies​

Section: DOC-MA-memory-knowledge#configure-memory.

After the recall-and-review flow works for the authorized scope, apply the memory settings with update-default-generation-config for the selected conversation, then send a representative question through generation. Enable this only when retrieval and asynchronous extraction are permitted for the data and audience.

{
  "conversationKey": "conv_abc",
  "defaultGenerationConfig": {
    "mem0": {
      "enabled": true,
      "searchTopK": 5,
      "searchThreshold": 0.3,
      "injectAsSystemContext": true,
      "injectMemoryTimestamps": true
    }
  }
}

Reference: Update default generation config · Request fields.

Finished result: the user can inspect and correct the allowed records, and the selected conversation has a correlated reply using the configured retrieval path. Review the reply rather than assuming every returned memory influenced it. Generation success does not confirm that later extraction completed.

Understand missing or delayed memories after a reply​

Section: DOC-MA-memory-knowledge#how-memory-flows-through-a-turn.

When a preference is missing or delayed, first review the records returned by the lookup. Follow the original conversation to its outcome before checking whether new memories have appeared. Keep the user’s correction separate from confirmation that background extraction completed.

Retrieval and extraction lifecycle.

Variant: share only within an approved audience​

Section: DOC-MA-memory-knowledge#cross-conversation-memory-sharing.

agentIdOverride selects a memory namespace within an authorized scope. It must not grant access to another user or project. Share only within an audience the user has authorized, and confirm the deployment supports that audience before enabling it. Changing this setting cannot grant access to another user's memories.

Current limit: the exposure flag does not add a tool​

Section: DOC-MA-memory-knowledge#explicit-memory-search-tool.

Use the search endpoint from your application for a controlled lookup. Confirm an actual discovered tool exists before asking the model to use it.

Variant: show when a remembered statement was recorded​

Section: DOC-MA-memory-knowledge#memory-timestamp-injection.

Keep timestamps enabled for this meal-preference recipe so the assistant receives when a statement was remembered and, when applicable, updated. Show the available record dates on the user’s review screen too. The date explains the record’s age; it does not certify the preference is still true.

If a different flow does not need timestamps in the model context, set injectMemoryTimestamps: false in the mem0 block on the thread default or per-turn override. This changes the injected annotation, not the stored fact or its truth.

Choose automatic retrieval or application-controlled search​

Section: DOC-MA-memory-knowledge#memory-and-conversations.

Keep application-controlled search-memories when the user must review records before the reply. Use automatic retrieval with mem0.enabled once the audience and retrieval/extraction permissions are established.

If using discovered MCP memory tools, inspect what is actually enabled through tool discovery; setting exposeAsMcpTool does not add one. No choice here removes the by-ID isolation gap.

Upcoming recipe: move permitted memories to a local provider​

Status: Upcoming — not yet available.

Section: DOC-MA-memory-knowledge#memory-providers

For a coaching application moving recall to supported local infrastructure, first identify the permitted records, their audience and the target provider. Retrieval of existing records and extraction of new ones have separate permissions.

  1. Inspect the records, corrections and deletion state included in the move.
  2. Run the migration to the supported provider.
  3. Review whether migration, export and any cleanup completed before using the target for recall.
  4. Continue the user’s recall-and-correction flow on the selected provider.

Finished result: migrated records preserve permitted provenance, ownership, audience and correction history; erased facts stay erased. Inspection, export and erasure show incomplete work and cleanup outcomes.

Portable providers and these controls are not yet available through the current configuration block. The by-ID access and deletion limitations above still apply.

Status: Upcoming — not yet available.

Section: DOC-MA-memory-knowledge#model-directed-memory-search

For a returning user asking “What else have I tried?”, give the agent a finite memory-search budget within that user’s permitted audience.

  1. Retrieve records relevant to the follow-up.
  2. Inspect whether the evidence is complete, partial, empty or unavailable.
  3. Answer from the available evidence or explain what is missing. Do not repeatedly search or broaden the audience to force an answer.

Finished result: the user receives an evidence-based follow-up or an explicit missing-evidence outcome within the search budget. The same consent and spending limits apply as for automatic retrieval.

The current exposeAsMcpTool setting has no effect. This retrieval tool and its activation path are not yet available; use the search endpoint or automatic retrieval for current integrations.

Section: DOC-MA-memory-knowledge#related.

Document ID: DOC-MA-memory-knowledge. Section identities and revisions.