Add MMW to your product

This page is for teams that already have a product: a chatbot, a CRM, a support desk, an internal assistant. You want it to remember customers and agreements between conversations, and you do not want to build your own store for that.

By the end of the page you will have:

1. the path your product uses to reach MMW;
2. a way to keep your users’ memories apart;
3. a rollout order in which an MMW outage does not break your product.

What stays with you and what MMW does

Your product	MMW
Users, sign-in, permissions	Keeps facts and decisions between sessions
Your customers’ plans and billing	Search by meaning and by words
Core data and business logic	Marks facts stale when their source changes
Deciding what to show the user	Contradictions show up as conflict instead of getting lost

MMW does not replace your database. It is a memory of facts, agreements and context that the model reads and adds to.

Architecture

  UI  →  your product API  →  MemoryAdapter  →  https://mcp.mmwhub.tech/mcp
                 │
                 └→  your DB (users, permissions, links to MMW records)

All traffic to MMW goes through one module on your server, call it MemoryAdapter. It holds:

• the MMW address and key (server side only, never in a browser or mobile app);
• the choice of workspace for each user;
• retries on network errors and one place to handle errors;
• a call log without the text of records.

The UI never calls MMW directly.

Calls

MMW speaks MCP over HTTP. For a server that is a plain JSON-RPC POST; no separate initialization is needed.

curl -s https://mcp.mmwhub.tech/mcp \
  -H "Authorization: Bearer $MMW_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"search","arguments":{"query":"delivery method","workspace":"u-1842","limit":5}}}'

The answer is JSON inside result.content[0].text. Saving works the same way with "name":"remember" and the arguments content, workspace, fact_key, source_id, confidence. All parameters are in the reference: search, remember, forget.

Keeping your users apart

Caution

An MMW key sees everything in its project. Separating users inside a project is the job of your adapter; MMW cannot do it for you.

There are two ways.

One workspace per user. One key bound to a dedicated project for your product. The adapter sets workspace to u-<your user id> itself and never takes it from the client request. This fits most products.

One project per customer company. If your customers are companies that need strict isolation, give each one its own project and key. The adapter picks the key by company. Store the keys encrypted.

In both cases use a permanent, unchanging user identifier: your internal id, not an email or a phone number. When the email changes, the memory stays where it is.

Retries without duplicates

If the adapter retries remember after a network error, add an X-Idempotency-Key header, for example a hash of the user id and the fact text. A retry with the same key returns the same record instead of creating a second one. Details in Best practices.

For facts that change (a delivery address, a customer’s plan), set a stable fact_key such as customer.delivery.address. The new version marks the old one as replaced, and search returns the current one.

Rollout step by step

1. One safe scenario. Read only: before answering, the bot searches the user’s memory and adds what it finds to the model context. The feature sits behind a flag that is off by default. Without an MMW key the adapter simply finds nothing and the product works as before. Call timeout 2 to 3 seconds.

2. Writing. The model saves the outcome of a conversation: a customer’s decision, an agreement, a preference. Retries carry X-Idempotency-Key. Keep MMW record ids next to your own entities in your DB, and keep the text of records out of your logs.

3. Deleting on request. A user asks to be forgotten or deletes their account: the adapter takes the ids of their MMW records from your DB (you kept them in step 2) and calls forget for each memory_id. Personal data requires this; build it before a wide launch.

4. Sources and freshness. If memory is built from your documents (knowledge base, policies), pass source_id and source_hash. When a document changes, the old facts become stale.

What not to do

• Do not send the MMW key to a browser, a mobile app or a model prompt.
• Do not let the model choose workspace: the adapter sets it.
• Do not store passwords, payment data or raw conversation dumps in memory.
• Do not make your product’s answer depend on MMW: on an error or timeout, answer without memory.

Limits and plans

Call and record limits depend on the plan; see Limits. If you need memory for many thousands of your users, write to support@mmwhub.tech and we will pick a plan and limits.

Next

Best practices What to save and how to name fact_key.

Workspaces and projects How a key is limited to a project.

Errors Response codes and what an adapter should do.

Agent skill If your developers need the memory in Claude Code and Codex.