Skip to main content
End-User Memory lets your Guru tailor its answers to the person asking. You can pass an end-user profile (name, plan, region, history, anything else useful) into Gurubase via the Upsert Profiles API, and, on the web channel, memory can also be built automatically from a logged-in user’s own questions. When that same user asks a question on a supported channel where they can be identified, the Guru uses the stored memory as context, so answers stay consistent across sessions and devices. This is the Memory-Powered Personalization feature surfaced as a first-class product capability.

​
Turning Memory On

End-User Memory is opt-in and off by default. Turn it on per Guru:
  1. Open the Guru’s Edit page.
  2. Expand Advanced Settings.
  3. Toggle End-User Memory on and click Update Guru.
Once enabled, memory is used everywhere the caller can be identified:
  • Web (logged-in users only): the authenticated user is identified automatically. Their memory is loaded on every question and updated from each new question (respecting PII masking, so masked questions are stored). Anonymous web visitors have no memory.
  • API, widget, MCP: memory is used whenever you pass an external_user_id in the Ask Question call. Without external_user_id, no memory is loaded or written. Profiles you supply via Upsert Profiles always take priority.
Slack, Discord, Microsoft Teams, Jira, and GitHub bots do not pass an external_user_id yet, so they do not use memory. Web, widget, MCP, and the direct API do.

​
Viewing and Deleting Your Own Memory

Logged-in web users get a View your memory modal that lists what the Guru remembers about them. From the modal they can:
  • Delete a single memory with the row’s delete button.
  • Clear all memories with a single action.
The modal is scoped to the signed-in user only; a user can never see or delete another user’s memory.

​
What Memory Unlocks

Plan-Aware Answers

A Pro-plan customer asking about quotas sees Pro-plan limits; a Free user sees Free limits, automatically.

Cross-Session Continuity

The Guru remembers what was asked yesterday, last week, and last quarter without re-asking the user every time.

Per-User Refusals

Combine memory with source-level RBAC so the Guru only cites what each user is entitled to see.

​
How It Works

1

Identify the user

Generate or reuse a stable external_user_id for each end user in your application. This is the key Gurubase will use to look up the user’s memory.
2

Upsert the profile

Call POST /{guru_slug}/profiles/ with a JSON memory object. The structure is up to you - name, plan, region, account tier, recent activity, anything that helps the Guru answer better.
3

Pass the user into questions

When the user asks a question, include the same external_user_id in your Ask Question call. The Guru pulls the stored profile and grounds its answer with both the knowledge base and the user context.
4

Update over time

Re-upsert the profile whenever something changes (plan change, new permission, new context). The Upsert endpoint is idempotent, so you can safely call it on every relevant event.

​
Example Profile Payload

The memory object structure is fully open. Pass whatever your application knows about the user that the Guru should use as context.

​
Pairs Well With

Smart Triage

Triage uses memory to skip clarifying questions the Guru already knows the answer to.

Actions

Actions can use memory fields (e.g. customer_email, plan) as parameters when calling your APIs.

PII Masking

Mask personal data in answers and logs even while the Guru uses it as context internally.

Audit Logs

Every memory-informed answer is logged with the external_user_id that drove it.

​
API Reference