Tenant memory

A small, explicit and auditable memory per tenant that both Plur-e MCP servers use to recall corrections, terms and preferences — what it stores, how to review it and its limits.

Quick answer

Both MCP servers keep a small, explicit memory per tenant (optionally per user) of corrections, glossary terms, preferences and short procedures a user gave in conversation. Claude reads it before answering with plure_recall and writes to it with plure_remember when the user corrects it or states something worth keeping. It is not fine-tuning: every entry is a row a tenant administrator can see, edit or delete in the Admin Center.

What it is for

Without memory, every conversation starts from zero: if a warehouse always calls a bin something other than what Business Central's field is named, or a sales team always drafts a particular kind of campaign a particular way, the user has to repeat that context every time. Memory lets the user say it once — as a correction or a stated preference, in normal conversation — and have the server recall it automatically afterwards, scoped to their tenant so one customer's vocabulary never leaks into another's.

What is stored

Each memory entry is a key and a short content, with:

Area — bc, crm or all (shared by both servers).
Kind — glossary (what a term means for this tenant), preference (how the user likes something done), fact (something true about this tenant's setup that is not in Dataverse or Business Central), correction (a standing fix to something Claude got wrong) or procedure (a short, tenant-specific sequence of steps).
Scope — tenant-wide, or tied to one user when the preference is personal rather than shared.
Tags, a source (the model or an administrator added it), a use count and the last time it was used.
Whether it is enabled — disabling keeps the history without the server using it.

Limits: 2,000 characters per entry, 500 entries per tenant; an administrator can delete entries manually to make room.

How it learns

The server's instructions tell the model to call plure_recall at the start of a session (it returns a short digest of the entries most relevant to the conversation, and bumps their use count) and to call plure_remember whenever the user corrects an answer, defines a term specific to their business, or repeats a preference Claude had to ask about more than once. plure_remember upserts by key — saving the same key again updates the entry instead of duplicating it — and needs no approval, but is fully audited like any other tool call. plure_forget removes an entry the user says is wrong or no longer applies.

Tool	Scope	What it does
`plure_recall`	read	Searches the tenant's memory and returns a digest before answering
`plure_remember`	write	Upserts a memory entry by key; audited, no approval required
`plure_forget`	write	Removes a memory entry

plure_remember and plure_forget are write tools, but they never touch Business Central or Dataverse data — only the tenant's own memory table — so they skip the approval workflow that a real ERP/CRM write goes through. Unlike other write tools they are granted to every role by default, so memory works out of the box; an administrator can lower a role to Read or None on these tools in AI & MCP → Scopes to stop it from changing shared memory. Every call is audited.

Both servers also publish a plure-bc://memory / plure-crm://memory resource with the current digest, for clients that prefer reading a resource over calling a tool.

Reviewing it in the Admin Center

AI & MCP → Memory lists every entry for the tenant: key, kind, area, scope, source, use count and last used date. A tenant administrator can edit the content, disable an entry without deleting it, delete it outright, or export the whole memory as a file — useful before a review or when migrating a tenant. Administrators can also add entries directly, which is often faster than waiting for the model to learn them through conversation.

What is not stored

Secrets and credentials — the model's instructions tell it never to save API keys, tokens or passwords to memory.
Personal data beyond what a user's own preference implies — the model's instructions also tell it not to save customer PII or free-form notes about people. Memory is about how this tenant works, not about individuals in its Dataverse or Business Central data.
Anything from a single, one-off answer that is not a stated correction or preference — memory is explicit, not an automatic transcript of every conversation.

Audit

Every plure_remember and plure_forget call is logged like any other tool call (user, tenant, arguments, result) under AI & MCP → Audit log, in addition to being visible as a row in the Memory page itself.