---
title: "Cross-AI as a structural moat"
url: https://memory.wiki/1tyw7rGT
updated: 2026-05-14T18:15:49.480Z
hub: https://memory.wiki/hub/demo
bundle_count: 1
concept_count: 12
source: "memory.wiki"
---
# Cross-AI as a structural moat

> The argument distilled, because I keep getting this question.

## The claim

AI companies cannot build cross-AI memory. The cross-AI position is structurally available only to a non-AI-company.

## The reasoning

Every AI company has the same revenue equation: users staying inside the product. ChatGPT's memory works in ChatGPT because making it work in Cursor would teach users that they don't need ChatGPT to have memory. Claude's projects work in Claude for the same reason. Cursor's project context works in Cursor.

This is **not** a technical limitation. Anthropic could ship "Claude memory works in OpenAI's API" tomorrow. They won't, because doing so cannibalises the business model that funds the model training that *makes Claude worth using.*

## The implication

The layer **above** the AI providers is structurally available to a player whose revenue doesn't depend on holding the user inside any one wall. That's us.

## Two pushbacks I've heard

> "But the AI companies will partner with each other."

Possibly on tool-calling and inference primitives. Not on memory. Memory is the stickiest thing a chatbot has, and giving it up is giving up your stickiest user behaviour. None of them will, voluntarily, until they're forced to.

> "But Anthropic is the AI company *and* the platform — they have MCP, they could ship a hub-shaped product."

MCP is genuinely good and we use it. But MCP standardises *how* tools are called, not what context is preserved between sessions. Anthropic could ship a memory product. It would only work inside Claude. The Cursor + ChatGPT + Codex user wouldn't benefit. That's the wedge — we're not chasing the Anthropic-loyal user; we're chasing the user who's already in three AI tools.

## What this thesis commits us to

- **Never bet on a single AI vendor.** Every integration we ship has to work across Claude / OpenAI / Gemini / open-source models. Where there's a quality gap (capture extraction, reranking) we pick the best per-task model but never the *same* one for everything.
- **The URL is the contract.** Not an SDK, not a plugin. Anything we ship that requires a vendor-specific runtime betrays the thesis.

## The risk if I'm wrong

If the AI companies *did* meaningfully interoperate, our edge shrinks. But the fallback is the authoring layer — users authoring what they want remembered is its own value, independent of cross-AI portability. So the downside is "we become a smaller product", not "we have no product."


---

## Concepts in this document
- **mdfy** _(entity)_
  A tool that stores project context and decision history, integrated into Cursor via custom rules.
- **Structural moat** _(concept)_
  The defensible advantage created by mdfy's vendor-neutral positioning, which competitors cannot replicate due to inherent conflicts of interest.
- **Claude** _(entity)_
  Anthropic's AI model cited as an example of vendor lock-in through projects and memory features.
- **Hacker News** _(entity)_
  Primary GTM channel chosen for high ICP overlap with developers and format alignment with technical credibility.
- **Cursor** _(entity)_
  Code editor that consumes mdfy bundles as context for chat and composer sessions.
- **ChatGPT** _(entity)_
  Example of an AI provider whose memory feature is intentionally confined to its own product.
- **Cross-AI memory** _(concept)_
  The core thesis: a memory layer that persists across multiple AI providers simultaneously, structurally unavailable to single-vendor AI companies.
- **Anthropic** _(entity)_
  Incumbent AI vendor mentioned as competitive threat with integrated memory and user lock-in.
- **Show HN Launch** _(concept)_
  Central launch strategy focused on Hacker News as primary channel.
- **Vendor neutrality** _(concept)_
  Design commitment to support Claude, OpenAI, Gemini, and open-source models equally without single-vendor dependencies.
- **Launch Strategy** _(tag)_
  The overarching theme covering all aspects of the product launch preparation and execution.
- **mdfy product** _(entity)_
  The core product being developed with build-in-public approach and AI integration as substrate.

## Concept relations (within this doc's concepts)
- **Launch Strategy** encompasses approach **Show HN Launch**
- **Structural moat** requires **Vendor neutrality**
- **Hacker News** primary channel **Launch Strategy**
- **Cross-AI memory** creates advantage **Structural moat**
- **Claude** developed by **Anthropic**
- **mdfy** integrates with **Claude**
- **mdfy** solves problem for **ChatGPT**
- **mdfy** integrates with **Cursor**
- **Vendor neutrality** operational commitment to **Cross-AI memory**
- **Structural moat** enables **Cross-AI memory**
- **Cursor** positioned to deliver **Cross-AI memory**
- **mdfy** integrated into **Cursor**

## Bundles containing this document
- [Launch strategy: Show HN week](https://memory.wiki/b/DlrrKcQ2)
  > Pre-launch plan + GTM channels + what not to do. The strategy bundle a reviewer can read end-to-end.

_Hub canonical:_ https://memory.wiki/hub/demo
_Concept digest:_ https://memory.wiki/raw/hub/demo?digest=1&compact=1