What changed
FACT: A founder on HN describes two cofounders running local Claude Code agents whose accumulated context (strategy, customer notes, decisions) is trapped per-machine and drifting, with only a Google Drive folder as a workaround (https://news.ycombinator.com/item?id=48848840). FACT: Anthropic-API-compatible tooling now lets Claude Code point at alternate backends, proving the client layer is interceptable/proxyable (https://ollama.com/blog/claude).
Why now
Claude Code adoption by 2-10 person teams is growing fast, and each seat accumulates non-shareable agent memory; the pain compounds with every week of drift. HYPOTHESIS: this is early enough that no dominant team-memory standard exists yet — but that window also means Anthropic itself is likely to close it.
Converging signals
(1) Concrete, well-specified team pain: per-machine agent context with no shared/private boundary, no history, sync conflicts. (2) Technical capability: Anthropic-API compatibility and MCP make it feasible to insert a memory layer without forking the client.
Customer pain
Two 'company brains' drifting apart: cofounder B re-derives from zero what cofounder A already worked out with his agent. No versioning, no shared/private separation, hacky file-drop workarounds. Source: the HN post (FACT for one team; HYPOTHESIS that it generalizes widely).
Who pays
HYPOTHESIS: 2-20 person AI-native startups where multiple people run Claude Code daily; the buyer is the technical founder. WTP is plausible ($10-30/user/mo, dev-tool norms) but UNPROVEN — the evidence set contains one complaint and zero spend/hiring signals.
Solved today
Google Drive folders (per the HN post), or committing CLAUDE.md / notes into the git repo, or open-source memory layers (mem0, Zep, Letta/MemGPT, OpenMemory MCP servers) — the OSS competitor set is HYPOTHESIS from general knowledge, not in the provided sources.
Why current solutions are bad
File-drop sync has no merge semantics, no shared-vs-private boundary, no history. Git-committed context works for repo-scoped conventions but is awkward for customer notes/strategy and requires manual curation. OSS memory servers are single-user-oriented and self-hosted-fiddly.
Proposed product
A hosted (or self-hostable) MCP memory server for Claude Code teams: each dev's agent reads/writes memories tagged shared|private; shared memories sync via a small backend with versioned history and conflict resolution; private stays local. One-line install into .mcp.json; team admin sees an audit log of the shared brain.
MVP version
MCP server (Python/TS) with store/retrieve/tag tools + Postgres backend + simple embedding search + shared/private scoping + append-only history. 2-4 weeks solo with AI-assisted coding. No proxy interception needed for v1 — MCP alone suffices.
30-day build
Build MVP; answer the HN thread and DM the OP as design partner; ship a free self-host tier to the MCP directories/awesome lists; get 5 teams using it.
60-day build
Add hosted tier with team billing ($15/user/mo), Slack digest of new shared memories, conflict/merge UX. Convert 2-3 design partners to paid.
90-day revenue plan
Target 10-20 paying teams (~$300-1,000 MRR) via HN Show, X dev-tool circles, MCP server directories. HYPOTHESIS: realistic ceiling is low four figures MRR by day 180 given free alternatives.
Distribution path
Show HN, the original Ask HN thread, MCP server directories, X/Twitter Claude Code community, awesome-mcp lists. Developer channels — reachable without ad spend, but conversion from free OSS users to paid is historically poor.
Pricing hypothesis
Free self-host core (required for dev-tool credibility) + hosted team sync at $10-20/user/mo. Per-seat, credit-card, no procurement.
Technical difficulty
Moderate-low: MCP server, sync backend, embeddings, auth. Well within solo AI-assisted range. Hard part is merge semantics and not becoming a junk drawer of stale memories (memory quality/decay).
Legal / regulatory risk
Low. Customer strategy/notes stored on your servers imposes ordinary data-security duty; offer self-host to sidestep.
Platform dependency
SEVERE. This lives entirely inside Anthropic's ecosystem. Anthropic already ships CLAUDE.md, projects, and memory features and is visibly moving toward team context sharing; a native 'team memory' release could obsolete the product overnight. This is the dominant risk.
Founder fit
Weak-to-moderate. Charles's proven edge is government-portal/forced-filer compliance automation with per-transaction pricing; this is a crowded, fast-moving developer tool sold to DIY-inclined buyers with no forced-buyer dynamic. He can build it, but it plays away from his differentiation and toward Anthropic's roadmap. Per the accumulated lesson (confidence 0.80), mandate-shaped opportunities score 8-9 founder-fit; this is not one.
Breakout potential
If it became the standard team-memory layer across agent runtimes (Claude Code, Cursor, etc.) it could matter — but that outcome requires winning a land-grab against funded players (mem0 raised VC; HYPOTHESIS) and platform vendors, which is exactly the game this founder avoids.
Final recommendation
PASS / revisit later. Real, vivid pain — but one anecdote of it, no spend evidence, a crowded OSS field, trivial substitutes, and existential Anthropic-roadmap risk, all in a domain orthogonal to this founder's proven government-portal edge. Watch the space; do not build now. Re-examine only if (a) Anthropic ships team plans WITHOUT shared memory and (b) multiple additional PAIN/SPEND signals accumulate.
Next action
Log a watch trigger: re-score this cluster if ≥3 more independent PAIN signals or any HIRING/SPEND signal for 'agent context sharing' appears, or after Anthropic's next Claude Code team-features release clarifies the native-memory roadmap. Spend zero build effort now.