# Add MMW to your product

> How to give your service, bot or internal tool long-term MMW memory. An adapter on your server, isolation between your users, retries without duplicates and a step-by-step rollout.

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

```text
  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.

```bash
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](/reference/search/), [remember](/reference/remember/), [forget](/reference/forget/).

## Keeping your users apart

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](/memory/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](/reference/limits/). If you need memory for many thousands of your users, write to [support@mmwhub.tech](mailto:support@mmwhub.tech) and we will pick a plan and limits.

## Next