GNOSEM
Launch

The Memory Layer Belongs to the User, Not the Vendor

Introducing Gnosem: a hosted MCP server for cross-vendor AI memory.

By CUETV LLC · · 9-minute read

If you use more than one AI assistant, you have already noticed the problem. Claude remembers the shape of your work — the project you're on, the tone you prefer, the technical choices you made last week. Then you open ChatGPT because it's better for a certain kind of question, and you are once again a stranger. You paste the same context. You explain the project. You re-teach the assistant who you are. And when you go back to Claude an hour later, the fresh insight you got from ChatGPT is trapped there. Nothing crosses over.

This is not a small inconvenience. It's a structural problem in how AI memory is being built, and it exists because every major vendor has independently decided that memory is a moat. Anthropic's memory feature lives in Anthropic products. OpenAI's memory feature lives in OpenAI products. Neither talks to the other, neither talks to Cursor or Windsurf or Zed, and none of them will ever help you when the vendor you're locked into inevitably falls behind on some capability.

Gnosem, a new product from CUETV LLC, is a hosted memory service built on the Model Context Protocol (MCP). It solves the vendor-lock-in problem the way protocol problems are supposed to be solved: by moving memory out of the vendor and into a portable layer that every client can share.

The vendor memory silo problem, concretely

Consider a realistic week for someone who works in AI-assisted software:

Every context switch is a re-onboarding. Every insight you gain in one tool is stranded there. The compounding effect that memory is supposed to give you — where the assistant gets smarter about you over time — is being taxed to zero because you have four silos instead of one memory.

There are three shapes this problem takes:

  1. Migration cost. If you decide to switch primary assistants, years of accumulated memory is unrecoverable.
  2. Cross-tool inefficiency. Every context switch inside a day costs you re-explanation time.
  3. Vendor leverage. The vendor who owns your memory owns your switching costs. Memory is a moat by design, not by accident.

The right fix isn't for each vendor to build a bigger memory feature. It's for memory to stop being a vendor feature at all.

Why MCP is the right protocol layer

The Model Context Protocol is the missing piece. Introduced by Anthropic in late 2024 and now co-stewarded by Anthropic, Microsoft, GitHub, and PulseMCP with an official registry, MCP is the standard interface between AI clients and external tools/data. Every major desktop AI client — Claude Desktop, Cursor, Windsurf, Zed — speaks MCP natively. ChatGPT can be pointed at an MCP server through a Custom GPT Action, which is how Gnosem bridges that gap.

The critical property MCP gives us: a memory service can be built once and consumed by every MCP client without per-client integration work. The client hears "there's a memory_write tool, a memory_search tool" and knows how to call them, because that's the whole point of MCP.

That means "cross-vendor memory" is not a moonshot feature that requires convincing every vendor to build the same thing. It's a straightforward MCP server exposing five tools:

Point Claude Desktop at the Gnosem MCP endpoint. Point Cursor at the same endpoint with the same Bearer token. Point ChatGPT (via a Custom GPT Action) at the same endpoint. Now they share the same memory. Write in one, read in another. That's the whole product.

How Gnosem is built

The stack is intentionally simple and intentionally all-edge. Everything runs on Cloudflare.

Cloudflare Workers hosts the MCP server itself. Streamable HTTP transport at https://gnosem.dev/mcp. The Worker handles the MCP handshake, authenticates the Bearer token, routes the tool call, and returns a response. No cold starts. Global edge deployment. Sub-100ms typical latency for a memory_search.

Cloudflare D1 (SQLite at the edge) stores the structured side of memories: the memory ID, user ID, content, timestamps, supersede pointers, tags. D1 is the source of truth for what a memory is. It's fast for point lookups and range scans and gives us relational integrity for foreign keys between memories and their supersede chain.

Cloudflare Vectorize stores the 768-dimension embedding for each memory. When you call memory_search, the query is embedded, then submitted to Vectorize with cosine similarity, and the top-N nearest neighbors are returned. Crucially, the query includes a metadata filter for user_id — this is what enforces per-user isolation at the query engine, not the application layer.

Cloudflare Workers AI hosts both the embedding model (BGE-base-en-v1.5, 768 dimensions) and the content-optimization model (llama-3.1-8b-instruct-fast). Choosing open-weights models means Gnosem doesn't have a hidden OpenAI dependency, doesn't pay OpenAI's embedding fees on every write, and doesn't leak content to a third-party API. Workers AI runs on the same edge as the Worker, so an embedding call adds a few milliseconds, not a network round trip.

The full flow for a memory_search("stripe webhook setup") call looks like this:

  1. Client sends MCP tool call to https://gnosem.dev/mcp with Bearer token in the Authorization header.
  2. Worker validates the token against D1 (SELECT user_id FROM api_keys WHERE key_hash = ?).
  3. Worker sends the query text to Workers AI for embedding (BGE-base-en-v1.5 → 768-dim float array).
  4. Worker calls VECTORIZE.query() with the embedding, topK: 10, and filter: { user_id: <user_id> }.
  5. Vectorize returns the top-K matching memory IDs with similarity scores.
  6. Worker hydrates the full memory records from D1 in a single SELECT ... WHERE id IN (?, ?, ?, ...).
  7. Worker returns the results as an MCP tool response.

Total round-trip: typically 50–150ms depending on region. All inside a single Worker invocation, no cross-cloud hops.

AI-optimized storage: memories the reading model can eat in fewer tokens

A memory saved as prose is fine for a human to re-read, but it's expensive for the next LLM that has to ingest it into its context window. So Gnosem also compresses long memories on write.

When you save a memory over ~400 characters, Gnosem runs it through a small instruction-tuned model (llama-3.1-8b-instruct-fast on Workers AI) with a system prompt that produces one line of structured key–value pairs: TOPIC=..., PROJECT=..., DECISION=..., STACK=..., PROBLEM=..., SOLUTION=.... The raw prose is preserved as content_raw; the compressed form is returned by default as content. If the compression doesn't actually win on bytes, Gnosem falls back to the raw. This is fail-open — any AI error on the optimization path still saves the memory.

The result: a 475-character memory about a Rust web scraper — architecture, stack, rate-limiting constraint, cost per gigabyte — compresses to a 189-character structured line without losing any of the facts. The client's reading LLM can absorb it in a fraction of the token budget. Pass raw: true on search or list to get the original prose instead. Pass no_optimize: true on write to skip compression entirely (useful for content where phrasing matters).

Per-user isolation: why it's enforced at two layers

Security in a multi-tenant memory service is not a "we'll get to it" concern. If tenant A can read tenant B's memories, the product is broken and probably illegal. Gnosem enforces isolation at two independent layers, which means a bug in one layer does not create a leak.

Layer 1: Application. Every Bearer token maps to exactly one user_id in the D1 api_keys table. Every SQL query that touches memory data includes WHERE user_id = ? with the token's user_id. Even a broken tool implementation that tried to fetch memories by ID without a user_id filter would fail because the query wrapper requires it.

Layer 2: Query engine. Every Vectorize query includes a metadata filter for user_id. Vectorize applies this filter inside the vector search itself — the engine does not consider vectors from other users as candidates. Even if the application layer were bypassed entirely, the vector store would not return cross-tenant results.

This design means Gnosem can lose one layer of defense without losing the whole isolation guarantee. That's the standard people building serious multi-tenant systems on top of vector databases should aim for.

Auth and account model

Auth is Bearer tokens. Creating an account with an email hits POST /signup and returns a one-time API key. Paste it into your MCP client's config. Sign up costs nothing and doesn't require a credit card.

There is no email/password auth for the MCP endpoint itself — MCP tool calls are stateless and Bearer-authenticated per call. Session-level auth would be the wrong abstraction for a protocol that expects short-lived tool calls from many clients.

Pricing rationale

Two tiers, deliberately simple:

The free tier is real. 200 memories is enough to genuinely try Gnosem in one client for a few weeks and see if the value shows up in your actual workflow.

The Pro price is $9 for two specific reasons:

  1. Under the personal-approval threshold. Most individuals don't need a manager's approval to spend $9/mo on a tool. This matters — a lot of good developer tools die at the "requires expense report" price ceiling.
  2. Enough to fund development without ads. Gnosem's business model is subscription revenue, not surveillance. Refusing the ad-supported / data-reselling model requires being priced high enough to actually pay for the infrastructure and engineering. $9/mo covers the Cloudflare bill, support, and continued development.

Annual pricing at $90 gives two months free — enough of a discount to reward commitment without so much discounting that the annual number becomes the anchor.

What's live today

What's next

Try it

Sign up at gnosem.dev. Free tier requires no credit card.

Once you have an API key, paste one of these into your client:

Claude Desktop — edit ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "gnosem": {
      "url": "https://gnosem.dev/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_API_KEY_HERE"
      }
    }
  }
}

Cursor — Cursor Settings → MCP → New MCP Server, same JSON as above.

Windsurf — edit ~/.codeium/windsurf/mcp_config.json with the same block (Windsurf uses serverUrl rather than url in some versions; the client will accept either).

Restart the client. Gnosem's five tools should appear in the tool list. Ask the assistant to remember something. Ask it to recall it later. Switch to another client and ask the same question. That's the product.

See pricing →

The bigger picture

Memory is where the real leverage in AI assistants is going to come from. Not smarter base models (that's Anthropic's and OpenAI's job), and not fancier UIs (that's Cursor's and Zed's job), but a memory layer that gets richer over time and comes with you wherever you work. That layer only delivers its full value if it lives outside the vendor.

MCP made that architecture possible. Gnosem is what it looks like when someone actually builds it. If you use more than one AI assistant, try it — it will feel like a bug being fixed rather than a feature being added.

gnosem.dev · pricing · more posts · source
Built and operated by CUETV LLC. MIT licensed.