DEV Community

Cover image for The missing layer in AI tooling: sharing what your assistant already knows
Uri Shmueli
Uri Shmueli

Posted on

The missing layer in AI tooling: sharing what your assistant already knows

#ai #mcp #devtools #opensource

It took my AI months to learn how I think, code, and ship. When a teammate joined the project, their AI started from zero — same codebase, same conventions, none of the context.

So I built memshare: peer-to-peer AI memory sharing, with consent on both sides.

The problem

Every AI tool today treats memory as a product feature locked inside one account. Claude remembers things for you. ChatGPT remembers things for you. Nobody else can get at it — not your teammate, not your other tools, not even you in a greppable format.

That means:

  • A designer in Cursor builds up months of component conventions. A backend dev in Claude Code has none of it.
  • You switch from one AI tool to another and start over.
  • Onboarding a new teammate means weeks of their AI re-learning what yours already knows.

What memshare does

memshare treats AI memory as a data type — plain JSON files you own — not a feature of someone else's chat product.

npm install -g memshare-mcp
memshare init
Enter fullscreen mode Exit fullscreen mode

Connect it to your AI tool once, and capture happens in conversation:

"we went with Postgres — the JSONB support decided it"
→ the AI calls memory_set, saved as private

"what do you know about this project?"
→ the AI calls memory_get

No commands to run. No copy-pasting. Your AI saves what it learns as you work.

Sharing

When you want to share context with a teammate:

# See exactly what would go out
memshare export --tags "project-x,architecture" --for alice --preview

# Happy with it? Write the bundle
memshare export --tags "project-x,architecture" --for alice --expires 30d
# → ~/.memshare/bundles/bundle-a3f8c2d1.memshare.json
Enter fullscreen mode Exit fullscreen mode

Send that file however you want — Slack, email, AirDrop. On Alice's machine:

memshare preview bundle-a3f8c2d1.memshare.json   # look, import nothing
memshare import  bundle-a3f8c2d1.memshare.json   # choose item by item
Enter fullscreen mode Exit fullscreen mode

Alice picks each item individually. Everything lands private — receiving context is not consent to pass it on.

The consent model

This is the part I care most about. Sharing someone's AI context without their control is a terrible idea. memshare has four gates:

  1. You tag at creation. Every item is private or shareable. Private items never leave, even if their tags match an export.
  2. PII is caught automatically. Before anything leaves your machine, memshare scans for emails, phone numbers, credentials, government IDs, and more. Flagged items are held back.
  3. You see the exact bundle. --preview runs the same code path as the real export — there's no separate preview implementation that can drift.
  4. They choose too. The recipient previews every item and accepts or rejects individually. Bundles are content-hashed, so a file edited in transit is refused.

It works across tools

memshare uses MCP (Model Context Protocol), which means it works with any MCP client:

// Cursor / Windsurf / GitHub Copilot — add to your MCP config
{
  "mcpServers": {
    "memshare": {
      "command": "npx",
      "args": ["-y", "memshare-mcp", "serve"]
    }
  }
}
Enter fullscreen mode Exit fullscreen mode 
# Claude Code
claude mcp add memshare --scope user -- npx -y memshare-mcp serve
Enter fullscreen mode Exit fullscreen mode

A designer in Cursor can hand component conventions to backend devs in Claude Code, and get the API contract back. Different people, different tools, same bundle format.

The architecture is the point 

          ~/.memshare/memories/*.json
          the actual product — plain JSON files
            ▲        ▲         ▲
            │        │         │
      MCP server    CLI    (future adapters)
            │
  Claude · Cursor · VS Code · Windsurf · any MCP client
Enter fullscreen mode Exit fullscreen mode

The memory store is the product. The MCP server is one adapter over it, the CLI is another. If MCP disappears tomorrow, your data is still sitting in a folder — human-readable, diffable, git-friendly.

~/.memshare/
├── config.json
├── memories/
│   └── mem_<uuid>.json      # one file per memory
└── bundles/
    └── bundle_<id>.memshare.json
Enter fullscreen mode Exit fullscreen mode

No database. No server. grep works. diff works. git works.

Is it actually capturing?

The honest risk: nothing in MCP can force a model to call a tool, so capture can quietly fail. memshare makes that visible:

memshare stats
Enter fullscreen mode Exit fullscreen mode 
12 memories, 5 in the last 14 days

  ▂▁▄█▂ ▁▃    14d ago → today

- 9 captured by an assistant, 3 added by hand
- 5 shareable, 7 private
Enter fullscreen mode Exit fullscreen mode

A flat line means capture isn't firing, and you know within days.

Use as a library 

import { MemoryStore, selectForExport, planImport } from "memshare-mcp";

const store = new MemoryStore();
await store.add({
  content: "Team chose Postgres over MySQL",
  tags: ["db"]
});

const { included, blocked } = await selectForExport(store, {
  tags: ["db"]
});
Enter fullscreen mode Exit fullscreen mode

Preview and the real action share one code path. selectForExport and planImport compute what would happen; the CLI renders that and then acts on it. No parallel implementation for a preview — consent based on a stale preview is not consent.

Try it 

git clone https://github.com/kampana/memshare.git
cd memshare && npm install && npm run build
bash examples/try-it.sh
Enter fullscreen mode Exit fullscreen mode

The script builds two fake stores in a temp directory and runs the full flow — capture, PII blocking, export, per-item import — then cleans up. Nothing touches your real config.

Or just install it:

npm install -g memshare-mcp
memshare init
Enter fullscreen mode Exit fullscreen mode

Open source, MIT licensed, no server, no signup.

GitHub | Site

I'd love feedback — especially on the consent model and whether the sharing flow feels right. Issues and PRs welcome.

Top comments (5)

Collapse
 
mihai_leanzero profile image
Mihai Perdum •

Building something with a similar shape - a ledger that logs agent decisions over time.

A memory file says "we chose Postgres." Six months later the team migrates off it. Nothing tells the next reader the decision's gone stale, unless something re-checks it against current state.

Does memshare version individual memories, or is it one file per uuid, last write wins, no history at all? An old bundle could still hand a teammate a decision that's long dead.

The PII scan before export is the right call. Most memory tools skip that step. They just ship whatever's sitting in the buffer.

Collapse
 
uri_shmueli_a403e7acc04a8 profile image
Uri Shmueli •

Thanks - the decision-decay problem is real and you're right to flag it.

Today it's one file per UUID, last write wins, no history. Each memory carries createdAt and updatedAt timestamps, and there's an optional expiresAt TTL you can set explicitly (e.g. --expires 90d for architectural decisions you know will need revisiting), but there's no active staleness warning - nothing that says "this is 8 months old, maybe re-check."

Bundles carry those same timestamps plus a content hash for tamper detection, so a recipient can at least see when a decision was recorded and last touched. But you're right that an old bundle can hand someone a dead decision with no signal that it's dead. That's a real gap.

I've been thinking about a lightweight "confirmed at" timestamp - something that gets bumped when a memory is explicitly re-validated rather than just read. That plus an age-based flag in the export preview ("3 items older than 6 months - still current?") would catch the worst cases without adding versioning overhead. Not there yet, but it's on the list.

Good to hear the PII scan resonated. That was a non-negotiable from day one - if you're building something similar, happy to share what patterns worked and what tripped us up with false positives.

Collapse
 
mihai_leanzero profile image
Mihai Perdum •

Uri, the "confirmed at" idea is the right shape for it. Bumping a timestamp on explicit re-validation instead of just on read makes a real distinction - "last touched" and "last confirmed correct" are not the same fact, and conflating them is how a decision nobody has actually looked at again ends up getting trusted anyway. The age-based export warning on top of that sounds like the cheap, honest version of versioning - it tells the recipient where to be suspicious instead of pretending the tool knows.

I'd take you up on the PII pattern comparison - full disclosure, I've built something in the same space (Sentinel Vault, a secrets/PII scanner). What trips us up most is anything that looks like an identifier out of context - internal ticket numbers, short alphanumeric codes - false-positiving as secrets/PII when they're actually just noise. Curious whether memshare's scan hits the same class of false positive or something else entirely.

Collapse
 
compoundlabs profile image
Compound Labs •

A memory can be safe to share when it is written and sensitive after a contract or incident changes. Does memshare recheck old shareable items against current policy before exporting them?

Collapse
 
uri_shmueli_a403e7acc04a8 profile image
Uri Shmueli •

The short answer: yes for PII, not yet for arbitrary policy.

Every export runs the full PII scanner against every candidate item at export time, not at write time. So if we add a new detection pattern (say, a new credential format or a health keyword), items that were written months ago and marked shareable will still get caught and blocked in the export preview. The user then decides per item whether to redact and include, or skip entirely. The scanner is deliberately over-eager - a false positive costs one click, a false negative leaks something real.

What we don't have today is a pluggable policy engine - something that could encode "after contract X was signed, mentions of project Y are now sensitive." That's an interesting direction. Right now the tool trusts the visibility label the user set (shareable vs private) and layers the PII scan on top at export time. Re-evaluating the visibility label itself against evolving rules is something we haven't built, but the architecture would support it - selectForExport is the single gate everything passes through, so a policy hook there would cover both preview and actual export without drift.

Thanks for raising this — it's the kind of thing that matters more as teams grow.