--- title: "Memory.wiki Business Plan and Architecture" url: https://memory.wiki/pBEnMXSs updated: 2026-05-20T14:29:26.281Z hub: https://memory.wiki/hub/raymindai bundle_count: 1 concept_count: 12 source: "auto-synthesis" --- # Memory.wiki Business Plan and Architecture > These documents chronicle the evolution of memory.wiki from concept to finalized business plan, articulating a vision to solve AI knowledge delivery through URLs that serve as APIs for any AI system. The project underwent significant rebranding from "mdfy" to "memory.wiki" while maintaining its core architectural principle of URL-native knowledge sharing. ## Key claims - [EXTRACTED] "A memory.wiki URL is an API for any AI" - users can paste `memory.wiki/`, `memory.wiki/b/`, or `memory.wiki/hub/` into ChatGPT, Claude, Gemini, or Cursor [doc-1, doc-4] - [EXTRACTED] The system operates on a three-tier architecture: "수집/소화/활용" (capture/digestion/utilization) where users author content, AI organizes it into graphs, and any AI can consume it [doc-1, doc-4] - [EXTRACTED] The core problem is knowledge delivery, not AI memory: "매일 수백만 명이 ChatGPT, Claude, Gemini, Cursor에 자신의 사고를 쏟아붓니다... 그리고 탭을 닫습니다" [doc-5] - [INFERRED] The project underwent significant strategic pivoting between versions v6 and v7, including a complete rebrand from "mdfy.app" to "memory.wiki" while preserving the fundamental URL-as-API architecture [doc-3, doc-4] - [EXTRACTED] The business model positions memory.wiki as "LLM 서비스의 기본 지원 메모리 레이어" (fundamental memory layer for LLM services) [doc-1] - [AMBIGUOUS] The system involves four core components - markdown source, AI-generated graphs, concept index, and embeddings - but the exact automation boundaries between user authoring and AI organization vary across descriptions [doc-3, doc-4] ## Cross-references - **URL Architecture**: Both the original "mdfy" concept [doc-3] and final "memory.wiki" plan [doc-1, doc-4] emphasize the same three-tier URL pattern, showing consistency in technical vision despite branding changes - **AI Integration Philosophy**: Document 5's manifesto complements the business plans by framing the problem as knowledge delivery rather than memory, supporting the URL-native solution described in the technical documents - **Timeline Evolution**: The launch deadline shifted to "2026년 8월 말 (16주)" [doc-1, doc-4], indicating project acceleration from initial concept to full-time development ## Open questions / gaps - How will the platform handle authentication and privacy for sensitive knowledge graphs? - What specific competitive advantages exist over existing knowledge management tools that might add AI integration? - How will the semantic search and concept indexing perform at scale across diverse user knowledge domains? ## Provenance - [doc-1]: Business plan v7 providing executive summary and strategic positioning for memory.wiki - [doc-2]: Meta-document synthesizing the overall development journey and vision - [doc-3]: Technical architecture explanation for the original "mdfy" concept, detailing the four core system components - [doc-4]: Full business plan v7 with detailed roadmap, business model, and go-to-market strategy - [doc-5]: Founder's manifesto explaining the philosophical motivation and problem definition behind memory.wiki --- ## Summary Memory.wiki is a platform where users can share knowledge through URLs that function as APIs for any AI system, operating on a three-tier architecture of capture, digestion, and utilization to solve the problem of knowledge delivery across ChatGPT, Claude, Gemini, and similar AI tools. The project rebranded from "mdfy" to "memory.wiki" while maintaining its core principle of making URLs serve as universal APIs for AI knowledge consumption. ## Themes - URL-native knowledge APIs - AI-powered content organization - LLM memory infrastructure ## Key takeaways - A memory.wiki URL functions as an API that any AI system can consume by pasting it into ChatGPT, Claude, Gemini, or Cursor. - The system operates on three tiers where users author content, AI organizes it into graphs, and any AI can consume the result. - Memory.wiki positions itself as a fundamental memory layer for LLM services rather than as a consumer note-taking application. - The project rebranded from mdfy.app to memory.wiki while maintaining the same three-tier URL pattern architecture. - The core problem is that millions daily pour their thinking into AI systems then close the tab, losing that context for future interactions. ## Insights - The project's core innovation persists despite complete rebranding from mdfy to memory.wiki, suggesting the URL-as-API pattern is the durable competitive insight rather than any particular brand positioning. - The problem statement emphasizes knowledge delivery to AI systems rather than human memory augmentation, which reframes the value proposition from note-taking tool to AI infrastructure layer. - The three-tier architecture (capture/digestion/utilization) distributes responsibility between humans and AI in a way that could work across multiple AI platforms simultaneously. ## Open questions / gaps - How will the platform handle authentication and privacy for sensitive knowledge graphs? - What specific competitive advantages does memory.wiki have over existing knowledge management tools that might integrate AI? - How will semantic search and concept indexing scale across diverse user knowledge domains? ## Concepts in this document - **memory.wiki** _(entity)_ The primary product platform being developed and documented. - **Raymind.AI** _(entity)_ 조현상이 설립한 독립 프로덕트 스튜디오로, AI 제품 기획 및 개발을 수행함. - **Knowledge Management** _(tag)_ Overarching domain of personal and organizational information systems - **mdfy** _(entity)_ A memory infrastructure layer that provides a URL-based knowledge hub for AI tools. - **Claude** _(entity)_ Specified AI tool for prototyping and validation before moving to high-fidelity design. - **URL as API** _(concept)_ Core architectural principle where every Memory.Wiki URL serves as a fetchable API endpoint for AI consumption - **ChatGPT** _(entity)_ One of the AI platforms currently suffering from isolated memory silos. - **Knowledge Graph** _(tag)_ Graph-based representation of entities and relationships tied to memory.wiki concepts. - **AI memory** _(tag)_ Conceptual topic describing how memory is used by AI agents. - **Cross-AI Compatibility** _(concept)_ The ability for Memory.Wiki URLs to work across any AI tool without vendor lock-in - **Hyunsang** _(concept)_ The document owner responsible for the release audit and checklist. - **Markdown** _(tag)_ Lightweight markup format used as the universal content format across Memory.Wiki. ## Concept relations (within this doc's concepts) - **Raymind.AI** ships as **mdfy** - **Markdown** transport format **URL as API** - **Hyunsang** founded and builds **memory.wiki** - **mdfy** provides platform **Knowledge Management** - **AI memory** disrupts category **Knowledge Management** - **mdfy** evolved into **memory.wiki** - **mdfy** rebranded to **memory.wiki** - **memory.wiki** targets platform **Claude** - **memory.wiki** targets platform **ChatGPT** - **Raymind.AI** builds and operates **memory.wiki** - **URL as API** content format **Markdown** - **Hyunsang** built **memory.wiki** - **memory.wiki** builds and surfaces **Knowledge Graph** - **URL as API** integrates with **ChatGPT** - **URL as API** integrates with **Claude** - **Cross-AI Compatibility** enables through **URL as API** - **Hyunsang** works at **Raymind.AI** - **memory.wiki** implements **URL as API** - **Raymind.AI** develops and ships **memory.wiki** - **URL as API** implements pattern **Cross-AI Compatibility** ## Bundles containing this document - [memory.wiki: Knowledge Graph as AI-Native Infrastructure](https://memory.wiki/b/ggAzbcHr) > The vision, architecture, and business rationale behind memory.wiki — a personal knowledge wiki that serves as a URL-based memory layer for any AI. _Hub canonical:_ https://memory.wiki/hub/raymindai _Concept digest:_ https://memory.wiki/raw/hub/raymindai?digest=1&compact=1