Clean up release highlights copy and removing emdash from the docs (#5984)

docs/platform/agent-signup.mdx

@@ -1,11 +1,11 @@
 ---
 title: Sign up as an agent
-description: "Zero-friction signup for AI agents — mint a working Mem0 API key in under five seconds. No email, no dashboard, no OTP."
+description: "Zero-friction signup for AI agents: mint a working Mem0 API key in under five seconds. No email, no dashboard, no OTP."
 icon: "robot"
 iconType: "solid"
 ---
 
-If you're an AI agent (Claude Code, Cursor, Codex, Cline, Aider, Windsurf, or any other autonomous coding tool), you don't need a human to set up Mem0 for you. Four commands — install, sign up, push a memory, search it — and you have persistent memory.
+If you're an AI agent (Claude Code, Cursor, Codex, Cline, Aider, Windsurf, or any other autonomous coding tool), you don't need a human to set up Mem0 for you. Four commands: install, sign up, push a memory, search it: and you have persistent memory.
 
 ## The 4-command demo
 
@@ -39,14 +39,14 @@ mem0 search "am I using mem0"
 ```
 </CodeGroup>
 
-That's it — under 30 seconds from a fresh shell to a working memory store.
+That's it: under 30 seconds from a fresh shell to a working memory store.
 
 ## Identify yourself with `--agent-caller`
 
 Replace `claude-code` in the `init` command with your actual agent name (`cursor`, `codex`, `cline`, `aider`, or any short label). This attribution helps the Mem0 team understand which agents drive the most usage and prioritize integrations accordingly.
 
 <Tip>
-**Forgot `--agent-caller` on init?** Run `mem0 identify <your-name>` after the fact — same key, just back-fills the attribution. Idempotent.
+**Forgot `--agent-caller` on init?** Run `mem0 identify <your-name>` after the fact: same key, just back-fills the attribution. Idempotent.
 </Tip>
 
 ## What happened when you ran `mem0 init --agent`?
@@ -54,13 +54,13 @@ Replace `claude-code` in the `init` command with your actual agent name (`cursor
 - A **shadow account** was minted on the Mem0 backend with a fresh API key.
 - The key was saved to `~/.mem0/config.json` (mode 0600) on the machine you ran the command on.
 - A default `user_id` was provisioned so `mem0 add` / `mem0 search` work without explicit scope flags.
-- The account is **unclaimed** — no human owns it yet.
+- The account is **unclaimed**: no human owns it yet.
 
 Every command run against this key prints a one-line reminder asking you to surface the claim instructions to your human user.
 
 ## Claiming the account (for the human owner)
 
-When the human is ready to take ownership of the agent's account — and all the memories it has accumulated — they run:
+When the human is ready to take ownership of the agent's account: and all the memories it has accumulated: they run:
 
 ```bash
 mem0 init --email you@yourcompany.com
@@ -68,9 +68,9 @@ mem0 init --email you@yourcompany.com
 
 The CLI detects the existing Agent Mode config, sends a verification code, and upgrades the shadow account in-place:
 
-- **The API key never changes** — the agent isn't disrupted.
+- **The API key never changes**: the agent isn't disrupted.
 - **All memories transfer** to the human's account.
-- **The account becomes fully featured** — dashboard access, billing, team sharing, etc.
+- **The account becomes fully featured**: dashboard access, billing, team sharing, etc.
 
 Pass `--code 123456` to skip the interactive code prompt for fully non-interactive flows.
 
@@ -97,7 +97,7 @@ How `add`, `search`, `update`, and `delete` work under the hood.
 </Card>
 
 <Card title="Mem0 MCP" icon="plug" href="/platform/mem0-mcp">
-Connect agents to Mem0 via the Model Context Protocol — alternative integration path.
+Connect agents to Mem0 via the Model Context Protocol: alternative integration path.
 </Card>
 
 <Card title="Platform Overview" icon="star" href="/platform/overview">

docs/platform/cli.mdx

@@ -1,16 +1,16 @@
 ---
 title: CLI
-description: "Manage memories from your terminal — built for both humans and AI agents."
+description: "Manage memories from your terminal: built for both humans and AI agents."
 icon: "terminal"
 iconType: "solid"
 ---
 
 The mem0 CLI lets you add, search, list, update, and delete memories directly from the terminal. It works with the Mem0 Platform API and is available as both an npm package and a Python package.
 
-Both implementations provide identical behavior — same commands, same options, same output formats.
+Both implementations provide identical behavior: same commands, same options, same output formats.
 
 <Tip>
-**Built for AI agents.** Pass `--agent` (or `--json`) as a global flag on any command to get structured JSON output optimized for programmatic consumption — sanitized fields, no colors or spinners, and errors as JSON too. Drop it into any agent tool loop with zero extra parsing.
+**Built for AI agents.** Pass `--agent` (or `--json`) as a global flag on any command to get structured JSON output optimized for programmatic consumption: sanitized fields, no colors or spinners, and errors as JSON too. Drop it into any agent tool loop with zero extra parsing.
 </Tip>
 
 ## Installation
@@ -26,7 +26,7 @@ pip install mem0-cli
 </CodeGroup>
 
 <Tip>
-**Looking for Agent Mode signup?** See [Sign up as an agent](/platform/agent-signup) — install, signup, first memory in four commands.
+**Looking for Agent Mode signup?** See [Sign up as an agent](/platform/agent-signup): install, signup, first memory in four commands.
 </Tip>
 
 ## Authentication
@@ -100,7 +100,7 @@ mem0 init --api-key m0-xxx --user-id alice --force
 | `--force` | Overwrite existing config without confirmation |
 
 <Note>
-AI agents should use `mem0 init --agent` — see [Sign up as an agent](/platform/agent-signup).
+AI agents should use `mem0 init --agent`: see [Sign up as an agent](/platform/agent-signup).
 </Note>
 
 ### `mem0 add`
@@ -273,7 +273,7 @@ mem0 version
 
 After running `mem0 init --agent`, the CLI persists a server-issued identifier
 (`default_user_id`, e.g. `user_a1b2c3d4e5f6`) in `~/.mem0/config.json`. This
-value is the agent's stable identity — surfaced as the row key on the
+value is the agent's stable identity: surfaced as the row key on the
 [AGENTRUSH leaderboard](https://mem0.ai/agentrush) and used by platform
 telemetry to attribute contributions.
 
@@ -286,18 +286,18 @@ mem0 whoami
 ```
 
 No network call. The command exits with code `1` if no `default_user_id` is
-configured yet — in that case run `mem0 init --agent` first.
+configured yet: in that case run `mem0 init --agent` first.
 
 ## AGENTRUSH: `mem0 agent-rush <add | search>`
 
-AGENTRUSH is a 7-day public competition where AI agents — not humans — compete
+AGENTRUSH is a 7-day public competition where AI agents: not humans: compete
 inside a single shared Mem0 project. Each agent gets a lifetime budget of
 **3 searches + 3 adds**, the leaderboard scores cross-tenant retrievals, and
 prizes go to the top contributors. See [mem0.ai/agentrush](https://mem0.ai/agentrush)
 for current event details.
 
 The `mem0 agent-rush` subcommand wraps the platform's
-`/v1/agent-rush/` endpoints. Routing is implicit — there is no
+`/v1/agent-rush/` endpoints. Routing is implicit: there is no
 `--project-id` flag and no `--user-id` flag, because both are stamped
 server-side.
 
@@ -307,12 +307,12 @@ server-side.
 # 1. Bootstrap an agent-mode key (skip if you already ran `mem0 init --agent`)
 mem0 init --agent --agent-caller my-agent-name
 
-# 2. Three searches — the search-first rule blocks adds until you've done this
+# 2. Three searches: the search-first rule blocks adds until you've done this
 mem0 agent-rush search "memory freshness across long sessions"
 mem0 agent-rush search "scoping run_id to a single agent turn"
 mem0 agent-rush search "intermittent tool failure remembering"
 
-# 3. Three adds — the content that gets retrieved earns you leaderboard points
+# 3. Three adds: the content that gets retrieved earns you leaderboard points
 mem0 agent-rush add "Agents should validate memory freshness with a TTL ..."
 mem0 agent-rush add "Scoping memories by run_id avoids cross-session ..."
 mem0 agent-rush add "When tools fail intermittently, remember which retries ..."
@@ -351,7 +351,7 @@ identifying information.** The acknowledgement is stored under
 once per machine.
 
 When the CLI is invoked by an agent in a non-interactive (no-TTY) context,
-the warning prints to stderr and the add proceeds — agents cannot answer
+the warning prints to stderr and the add proceeds: agents cannot answer
 y/N prompts. Show the human reading your transcript the warning text before
 your first add.
 
@@ -364,8 +364,8 @@ All commands support the `--output` flag to control how results are displayed:
 | `text` | Human-readable output with colors and formatting (default for most commands) |
 | `json` | Structured JSON, suitable for piping to `jq` or consumption by AI agents |
 | `table` | Tabular format (default for `list`) |
-| `quiet` | Minimal output — just IDs or status codes |
-| `agent` | Structured JSON envelope with sanitized fields — set automatically by `--json`/`--agent` |
+| `quiet` | Minimal output: just IDs or status codes |
+| `agent` | Structured JSON envelope with sanitized fields: set automatically by `--json`/`--agent` |
 
 Example with JSON output:
 
@@ -378,7 +378,7 @@ mem0 search "user preferences" --user-id alice --output json | jq '.data.results
 The CLI is purpose-built for use inside AI agent tool loops. Pass `--agent` or `--json` as a global flag on **any** command to activate agent mode:
 
 - Every command outputs a consistent JSON envelope: `{"status", "command", "duration_ms", "scope", "count", "data"}`
-- The `data` field contains only the fields that matter — IDs, memory text, scores, categories. Noisy API fields are stripped.
+- The `data` field contains only the fields that matter: IDs, memory text, scores, categories. Noisy API fields are stripped.
 - All human-readable output is suppressed: no spinners, no colors, no banners.
 - Errors are returned as JSON to stdout with a non-zero exit code, so your agent can catch them the same way as successes.
 
@@ -419,7 +419,7 @@ mem0 --agent delete --all --user-id user-42 --force
 
 Two other agent-friendly features:
 
-- **`--output json`** returns structured data without sanitization — useful when you want the full raw API response
+- **`--output json`** returns structured data without sanitization: useful when you want the full raw API response
 - **`mem0 help --json`** returns the complete command tree as JSON, so agents can self-discover available commands and options
 
 For non-interactive environments (CI, agent runtimes), set credentials via `mem0 init --api-key m0-xxx --user-id alice --force` or the `MEM0_API_KEY` environment variable.

docs/platform/faqs.mdx

@@ -157,7 +157,7 @@ iconType: "solid"
         - Organizations you solely own, along with their data
         - Your membership in any shared organizations (the orgs themselves are not affected)
 
-        Any application still using your old API keys will start receiving `401 Unauthorized` responses immediately. If you'd like to use Mem0 again later, you can create a new account at any time — it will start fresh with no data carried over.
+        Any application still using your old API keys will start receiving `401 Unauthorized` responses immediately. If you'd like to use Mem0 again later, you can create a new account at any time: it will start fresh with no data carried over.
     </Accordion>
 
 </AccordionGroup>

docs/platform/features/async-client.mdx

@@ -124,7 +124,7 @@ await client.deleteAll({ userId: "alice" });
 </CodeGroup>
 
 <Note>
-  At least one filter (`user_id`, `agent_id`, `app_id`, or `run_id`) is required — calling `delete_all` with no filters raises an error to prevent accidental data loss. You can pass `"*"` as a value to delete all memories for a given entity type (e.g., `user_id="*"` removes memories for every user). A full project wipe requires all four filters set to `"*"`.
+  At least one filter (`user_id`, `agent_id`, `app_id`, or `run_id`) is required: calling `delete_all` with no filters raises an error to prevent accidental data loss. You can pass `"*"` as a value to delete all memories for a given entity type (e.g., `user_id="*"` removes memories for every user). A full project wipe requires all four filters set to `"*"`.
 </Note>
 
 ### History

docs/platform/features/criteria-retrieval.mdx

@@ -88,7 +88,7 @@ After setting up your criteria, you can use them to filter and retrieve memories
 ```python
 messages = [
     {"role": "user", "content": "What a beautiful sunny day! I feel so refreshed and ready to take on anything!"},
-    {"role": "user", "content": "I've always wondered how storms form—what triggers them in the atmosphere?"},
+    {"role": "user", "content": "I've always wondered how storms form, what triggers them in the atmosphere?"},
     {"role": "user", "content": "It's been raining for days, and it just makes everything feel heavier."},
     {"role": "user", "content": "Finally I get time to draw something today, after a long time!! I am super happy today."}
 ]
@@ -182,7 +182,7 @@ If no criteria are defined for a project, search behaves normally based on seman
 This lets you prioritize memories that align with your agent's goals and not just those that look similar to the query.
 
 <Note>
-Criteria retrieval is automatically enabled when criteria are defined in your project. Use `use_criteria=False` in search to temporarily disable it for a specific query. `use_criteria` is a server-side parameter passed through to the Platform API — it is not a typed option in the SDK's `SearchMemoryOptions` interface, but the server accepts and processes it when included in the request body.
+Criteria retrieval is automatically enabled when criteria are defined in your project. Use `use_criteria=False` in search to temporarily disable it for a specific query. `use_criteria` is a server-side parameter passed through to the Platform API: it is not a typed option in the SDK's `SearchMemoryOptions` interface, but the server accepts and processes it when included in the request body.
 </Note>
 
 

docs/platform/features/custom-categories.mdx

@@ -25,9 +25,9 @@ Mem0 automatically tags every memory, but the default labels (travel, sports, mu
 
 ## How it works
 
-- **Default list** — Each project starts with 15 broad categories like `travel`, `sports`, and `music`.
-- **Project override** — When you call `project.update(custom_categories=[...])`, that list replaces the defaults for future memories.
-- **Automatic tags** — As new memories come in, Mem0 picks the closest matches from your list and saves them in the `categories` field.
+- **Default list**: Each project starts with 15 broad categories like `travel`, `sports`, and `music`.
+- **Project override**: When you call `project.update(custom_categories=[...])`, that list replaces the defaults for future memories.
+- **Automatic tags**: As new memories come in, Mem0 picks the closest matches from your list and saves them in the `categories` field.
 
 <Note>
   Default catalog: `personal_details`, `family`, `professional_details`, `sports`, `travel`, `food`, `music`, `health`, `technology`, `hobbies`, `fashion`, `entertainment`, `milestones`, `user_preferences`, `misc`.

docs/platform/features/entity-scoped-memory.mdx

@@ -130,7 +130,7 @@ print(agent_results)
 ```
 
 <Tip icon="compass">
-Writes can include multiple identifiers, but searches resolve one entity space at a time. Query user scope *or* agent scope in a given call—combining both returns an empty list today.
+Writes can include multiple identifiers, but searches resolve one entity space at a time. Query user scope *or* agent scope in a given call: combining both returns an empty list today.
 </Tip>
 
 <Tip icon="sparkles">

docs/platform/features/group-chat.mdx

@@ -231,7 +231,7 @@ Group chat supports async processing for improved performance. Memory additions
 <CodeGroup>
 
 ```python Python
-# Group chat — async processing is the default
+# Group chat: async processing is the default
 response = client.add(
     messages,
     run_id="groupchat_async",

docs/platform/features/memory-decay.mdx

@@ -7,12 +7,12 @@ description: "Boost recently-used memories and gently dampen stale ones at searc
 
 Older memories drift in relevance at different speeds. A user's coffee order matters every morning; a one-off project name from last quarter rarely matters again. Memory Decay makes that intuition explicit at search time: every time a memory is returned in a search it gets a small reinforcement, and memories that haven't been touched in a while have their ranking score gently dampened.
 
-It is **a soft ranking bias, never a filter.** Decay never zeroes a candidate out — at worst it scales its score by `0.3×`. Anything that would have surfaced without decay can still surface with decay on, just with a different ranking among similarly-scored results.
+It is **a soft ranking bias, never a filter.** Decay never zeroes a candidate out: at worst it scales its score by `0.3×`. Anything that would have surfaced without decay can still surface with decay on, just with a different ranking among similarly-scored results.
 
 <Info>
   **Use Memory Decay when…**
   - Search results are crowded with old facts the user no longer cares about.
-  - You want recently-used memories to drift to the top automatically — without writing custom scoring logic.
+  - You want recently-used memories to drift to the top automatically: without writing custom scoring logic.
   - You want this preference applied per project so cohorts can be compared side-by-side.
 </Info>
 
@@ -30,7 +30,7 @@ Every memory carries a small piece of bookkeeping: when was it last retrieved, a
 | Touched today | 1.2 – 1.4× | Mild boost |
 | Idle for a few days | 0.6 – 1.0× | Mild dampening |
 | Idle for weeks | 0.4 – 0.6× | Stronger dampening |
-| Idle for many months / years | ≈ **0.3×** | Floor — never lower |
+| Idle for many months / years | ≈ **0.3×** | Floor: never lower |
 
 The bounds matter: `0.3` is the floor and `1.5` is the ceiling, so decay can meaningfully reorder candidates without ever dominating the underlying relevance score.
 
@@ -41,16 +41,16 @@ At search time the pipeline:
 3. Sorts on the unclamped product so the full `0.3×–1.5×` range can rearrange candidates.
 4. Returns the public `score` clamped to `[0, 1]` so the API contract is preserved.
 5. Truncates to the `top_k` you requested.
-6. Records a fire-and-forget reinforcement against each returned memory — its access history grows by one, capped at the most recent 20 touches.
+6. Records a fire-and-forget reinforcement against each returned memory: its access history grows by one, capped at the most recent 20 touches.
 
-Memories created before decay was enabled don't yet have an access history. They use a sensible fallback: their `updated_at` is treated as a single past touch, so the same scale above applies based on how stale that update is — a recently-updated legacy memory enters near the neutral band, a long-stale one sits closer to the floor. Once surfaced in a search after decay is on, they accumulate access history naturally and behave like any other memory.
+Memories created before decay was enabled don't yet have an access history. They use a sensible fallback: their `updated_at` is treated as a single past touch, so the same scale above applies based on how stale that update is: a recently-updated legacy memory enters near the neutral band, a long-stale one sits closer to the floor. Once surfaced in a search after decay is on, they accumulate access history naturally and behave like any other memory.
 
 ## Configure access
 
 - Set `MEM0_API_KEY` in your environment, or pass it to the SDK constructor.
 - Initialize the client with the organization and project you want to scope to.
 
-The toggle lives on the project. You enable decay by patching the project's `decay` field; everything else — your `add` calls, your `search` calls, your application code — stays exactly the same.
+The toggle lives on the project. You enable decay by patching the project's `decay` field; everything else: your `add` calls, your `search` calls, your application code: stays exactly the same.
 
 ## Enable decay for a project
 
@@ -137,23 +137,23 @@ curl -X PATCH https://api.mem0.ai/api/v1/orgs/organizations/$ORG_ID/projects/$PR
 
 ## What stays the same
 
-- **Public API shape** — every endpoint accepts the same parameters and returns the same fields. You don't touch your client code.
-- **Threshold semantics on the request side** — your `threshold` is still applied during candidate selection.
-- **Memory creation and storage** — every new memory still lands the same way. Decay is a search-time concern.
-- **Per-memory data** — categories, metadata, timestamps, embeddings: untouched.
+- **Public API shape**: every endpoint accepts the same parameters and returns the same fields. You don't touch your client code.
+- **Threshold semantics on the request side**: your `threshold` is still applied during candidate selection.
+- **Memory creation and storage**: every new memory still lands the same way. Decay is a search-time concern.
+- **Per-memory data**: categories, metadata, timestamps, embeddings: untouched.
 
 <Warning>
-  Because the scaling factor is applied *after* the threshold filter has already run, an item that passed the request `threshold` can come back with a public `score` slightly below it (a stale candidate dampened by `0.3×`). This is intentional — decay is a soft bias, not a filter. If you require a hard `score >= threshold` invariant on the response, filter client-side after the call.
+  Because the scaling factor is applied *after* the threshold filter has already run, an item that passed the request `threshold` can come back with a public `score` slightly below it (a stale candidate dampened by `0.3×`). This is intentional: decay is a soft bias, not a filter. If you require a hard `score >= threshold` invariant on the response, filter client-side after the call.
 </Warning>
 
 ## Lifecycle of a memory under decay
 
 | Stage | Scaling factor | Effect |
 |---|---|---|
-| Just added | ≈ 1.5× | Strong boost — fresh facts surface easily. |
+| Just added | ≈ 1.5× | Strong boost: fresh facts surface easily. |
 | Reinforced on a recent search | 1.2 – 1.5× | Sustains its boost for the next several searches. |
 | Idle for a few days | 0.6 – 1.0× | Falls back into the neutral band. |
-| Idle for weeks | 0.4 – 0.6× | Mild dampening — can still surface for strong matches. |
+| Idle for weeks | 0.4 – 0.6× | Mild dampening: can still surface for strong matches. |
 | Pre-decay legacy memory (no access history) | 0.3 – 1.0× | Falls back to `updated_at`: recently-updated entries land near 1.0×, long-stale entries approach the 0.3× floor. |
 
 The reinforcement is bounded: each memory tracks at most the last 20 access timestamps, so the boost stays well-behaved no matter how many times a memory is retrieved.
@@ -161,31 +161,31 @@ The reinforcement is bounded: each memory tracks at most the last 20 access time
 ## FAQ
 
 **Will decay ever drop a result that would otherwise surface?**
-No. The floor is `0.3×` — the scaling factor can dampen a score, never zero it. Threshold filtering happens *before* decay, so any candidate that cleared the threshold is in the pool decay reorders.
+No. The floor is `0.3×`: the scaling factor can dampen a score, never zero it. Threshold filtering happens *before* decay, so any candidate that cleared the threshold is in the pool decay reorders.
 
 **Why is the public score sometimes below my requested threshold?**
-The threshold is applied to the candidate pool pre-decay; the scaling factor then reshapes scores in the `0.3×–1.5×` band. A stale-but-relevant candidate can come back with a final score slightly under your threshold by design — the candidate stays visible but visibly dampened. Filter client-side if you need a hard floor on the response.
+The threshold is applied to the candidate pool pre-decay; the scaling factor then reshapes scores in the `0.3×–1.5×` band. A stale-but-relevant candidate can come back with a final score slightly under your threshold by design: the candidate stays visible but visibly dampened. Filter client-side if you need a hard floor on the response.
 
 **Does decay change how I add memories?**
 No. The `client.add(...)` path is unchanged. Decay is a search-time ranking adjustment.
 
 **What if I had memories before turning decay on?**
-They use a fallback: the memory's `updated_at` is treated as a single historical touch, so the same scaling applies based on how stale that update is — a recently-updated legacy memory enters near the neutral band (~1.0×), a long-stale one closer to the floor (~0.3×). Once retrieved they accumulate access history and behave like any other memory.
+They use a fallback: the memory's `updated_at` is treated as a single historical touch, so the same scaling applies based on how stale that update is: a recently-updated legacy memory enters near the neutral band (~1.0×), a long-stale one closer to the floor (~0.3×). Once retrieved they accumulate access history and behave like any other memory.
 
 **Can I tune how aggressively decay scales scores?**
-Not in this version. The current scaling is calibrated to be conservative — wide enough to meaningfully reorder candidates, narrow enough to never dominate the underlying relevance score. Per-project tuning is on the roadmap.
+Not in this version. The current scaling is calibrated to be conservative: wide enough to meaningfully reorder candidates, narrow enough to never dominate the underlying relevance score. Per-project tuning is on the roadmap.
 
 **Can I see the scaling factor per result?**
-Internal scoring details are persisted on the search Event for support and debugging. They aren't exposed in the public response by design — the response surface stays a single `score` field.
+Internal scoring details are persisted on the search Event for support and debugging. They aren't exposed in the public response by design: the response surface stays a single `score` field.
 
 **Does decay interact with reranking?**
-Yes — they layer cleanly. The reranker produces a richer relevance score; decay then biases that score by reinforcement history before final truncation to `top_k`.
+Yes: they layer cleanly. The reranker produces a richer relevance score; decay then biases that score by reinforcement history before final truncation to `top_k`.
 
 ## What's next
 
-This release is deliberately the simplest version of decay we could ship — every memory contributes to ranking through its access history alone, so the signal can be evaluated in isolation. On the roadmap:
+This release is deliberately the simplest version of decay we could ship: every memory contributes to ranking through its access history alone, so the signal can be evaluated in isolation. On the roadmap:
 
 - **Category-aware weighting.** A fact tagged `health` will be able to carry more weight than a passing observation tagged `misc`, so important categories don't get dampened the same way as noise.
-- **Auto-tuning per project.** Project-scoped automatic adjustment of how aggressively decay scales scores, based on observed access patterns — replacing the fixed scaling band with one that fits your workload.
+- **Auto-tuning per project.** Project-scoped automatic adjustment of how aggressively decay scales scores, based on observed access patterns: replacing the fixed scaling band with one that fits your workload.
 
-Both extensions are forward-compatible — no migration on your side will be needed when they ship.
+Both extensions are forward-compatible: no migration on your side will be needed when they ship.

docs/platform/features/temporal-reasoning.mdx

@@ -32,7 +32,7 @@ client = MemoryClient(api_key="your-api-key")
 
 When a memory describes an event, a future plan, or an ongoing state, Temporal Reasoning recognizes the time context so the right results surface at search time.
 
-A query like `what did I do last week?` should return a completed past event — not an upcoming appointment and not a stable fact that hasn't changed. Temporal Reasoning handles that distinction automatically.
+A query like `what did I do last week?` should return a completed past event: not an upcoming appointment and not a stable fact that hasn't changed. Temporal Reasoning handles that distinction automatically.
 
 ### Memory types Temporal Reasoning handles
 
@@ -44,7 +44,7 @@ A query like `what did I do last week?` should return a completed past event —
 | Relationship | A durable connection between people or entities | "Priya manages Jordan." |
 | Preference | A stable preference or habit | "I prefer morning meetings." |
 
-Results come back in the normal search response shape — Temporal Reasoning affects ranking, not the response format.
+Results come back in the normal search response shape: Temporal Reasoning affects ranking, not the response format.
 
 ## Configure it
 
@@ -52,8 +52,8 @@ Temporal Reasoning is enabled by default for all v3 searches and writes. There i
 
 Two parameters give you precise control when you need it:
 
-- `timestamp` on `add()` — anchors an imported memory to the time it actually happened, rather than the time it was added to Mem0
-- `reference_date` on `search()` — resolves relative phrases like `last week` against a fixed point in time
+- `timestamp` on `add()`: anchors an imported memory to the time it actually happened, rather than the time it was added to Mem0
+- `reference_date` on `search()`: resolves relative phrases like `last week` against a fixed point in time
 
 <CodeGroup>
 ```python Python

docs/platform/mem0-mcp.mdx

@@ -15,7 +15,7 @@ estimatedTime: "~2 minutes"
 
 ## What is Mem0 MCP?
 
-Mem0 MCP Server exposes Mem0's memory capabilities as MCP tools, letting AI agents decide when to save, search, or update information. The cloud-hosted MCP server requires no local installation — just connect and start using memory.
+Mem0 MCP Server exposes Mem0's memory capabilities as MCP tools, letting AI agents decide when to save, search, or update information. The cloud-hosted MCP server requires no local installation: just connect and start using memory.
 
 ## Quick Setup
 
@@ -97,7 +97,7 @@ You can also configure individual clients:
     bearer_token_env_var = "MEM0_API_KEY"
     ```
 
-    Export `MEM0_API_KEY` in the shell you launch Codex from, then restart Codex. `codex mcp add` only supports stdio servers, so HTTP servers must be added via `config.toml` directly — or via the **Plugins → Connect to a custom MCP → Streamable HTTP** UI in the Codex app.
+    Export `MEM0_API_KEY` in the shell you launch Codex from, then restart Codex. `codex mcp add` only supports stdio servers, so HTTP servers must be added via `config.toml` directly: or via the **Plugins → Connect to a custom MCP → Streamable HTTP** UI in the Codex app.
 
     <Note>
       Codex uses the server name `mem0` (not `mem0-mcp` like the other clients on this page) so it matches the name the bundled plugin registers if you ever sideload it later.
@@ -110,7 +110,7 @@ You can also configure individual clients:
     codex plugin marketplace add ~/codex-plugins/mem0-source
     ```
 
-    Then run `codex` and `/plugins`, browse the **Mem0 Plugins** marketplace, and install **Mem0**. Don't combine this with the Direct MCP setup above — the sideloaded plugin auto-registers `mem0` via `.codex-mcp.json`, so a manual `[mcp_servers.mem0]` block would create a duplicate.
+    Then run `codex` and `/plugins`, browse the **Mem0 Plugins** marketplace, and install **Mem0**. Don't combine this with the Direct MCP setup above: the sideloaded plugin auto-registers `mem0` via `.codex-mcp.json`, so a manual `[mcp_servers.mem0]` block would create a duplicate.
 
     See the [Codex integration guide](/integrations/codex) for full details, lifecycle-hook setup, and management commands (`codex plugin marketplace upgrade` / `remove`).
   </Accordion>

docs/platform/overview.mdx

@@ -6,12 +6,12 @@ icon: "cloud"
 
 # Mem0 Platform Overview
 
-Mem0 is the memory engine that keeps conversations contextual so users never repeat themselves and your agents respond with continuity. Mem0 Platform delivers that experience as a fully managed service—scaling, securing, and enriching memories without any infrastructure work on your side.
+Mem0 is the memory engine that keeps conversations contextual so users never repeat themselves and your agents respond with continuity. Mem0 Platform delivers that experience as a fully managed service: scaling, securing, and enriching memories without any infrastructure work on your side.
 
 ## Why it matters
 
 - **Personalized replies**: Memories persist across users and agents, cutting prompt bloat and repeat questions.
-- **Hosted stack**: Mem0 runs the vector store and rerankers—no provisioning, tuning, or maintenance.
+- **Hosted stack**: Mem0 runs the vector store and rerankers: no provisioning, tuning, or maintenance.
 - **Enterprise controls**: Audit logs and workspace governance ship by default for production readiness.
 
 <AccordionGroup>
@@ -19,7 +19,7 @@ Mem0 is the memory engine that keeps conversations contextual so users never rep
 
     | Feature | Why it helps |
     | --- | --- |
-    | Fast setup | Add a few lines of code and you’re production-ready—no vector database or LLM configuration required. |
+    | Fast setup | Add a few lines of code and you’re production-ready: no vector database or LLM configuration required. |
     | Production scale | Automatic scaling, high availability, and managed infrastructure so you focus on product work. |
     | Advanced features | webhooks, multimodal support, and custom categories are ready to enable. |
     | Enterprise ready | Audit logs, workspace governance, and dedicated support keep security and governance covered. |

docs/platform/quickstart.mdx

@@ -8,7 +8,7 @@ iconType: "solid"
 Get started with Mem0 Platform's hosted API in under 5 minutes. This guide shows you how to authenticate and store your first memory.
 
 <Note>
-**Are you an AI agent?** See [Sign up as an agent](/platform/agent-signup) — mint a working API key in four commands, no email or dashboard required.
+**Are you an AI agent?** See [Sign up as an agent](/platform/agent-signup): mint a working API key in four commands, no email or dashboard required.
 </Note>
 
 ## Prerequisites