A team I know kept their documentation in three places. An internal wiki — for their own people. READMEs and scraps of markdown in the repositories — for developers. A separate static-site-generator website — for external users. Three copies of the same knowledge. Guess how many of them were current at any given moment. Right: at best one, and nobody knew which.
It’s not laziness. Documentation genuinely has three kinds of readers, and they arrive differently: your own team lives in a browser with search, an AI agent needs an API, and someone outside the company just wants a public page that doesn’t ask them to log in. The classic answer is to give each audience its own tool — which is exactly where the three copies come from. In Meldoc we kept the three entrances and dropped the copies: one base, and three doors into it.
Door one: the team
People read and write through the UI: an editor with live preview and autosave, Ctrl+K search — across titles, full text, aliases and even code blocks. Terms from the workspace glossary are highlighted right in the text — hover, get the definition, skip the trip to the chat to ask again. And the connection graph shows how documents relate to each other; I wrote about it in detail in Graphs in Meldoc.
But behind the UI are plain .meldoc.md files — in the same repository as the code. Edits travel through the same PR, and after the merge fly to the server — with meldoc push or automatically if CI is hooked up. The UI and the files look at the same base: edit in the editor — the agent sees the edit immediately; edit the files — the team sees them after sync. And since these are ordinary files in the repository, the CLI works with them locally and offline, with no dependency on a SaaS: the server adds search, the graph and agent access on top.
And “the team” isn’t just developers. QA can check the spec is current before writing test cases. The PM reads architecture docs without asking anyone for GitHub access, and support pulls up the runbook on their own instead of paging whoever’s on call that night.
Door two: AI agents
The same content reaches an agent through MCP: document lists, the tree, full-text and semantic search, reading and editing by sections — the agent doesn’t need the whole document, only the section that solves its task. After a search, the agent checks similar and related documents in a single request, and when it opens the one it needs — receives the glossary terms along with it: it doesn’t just search, it orients itself in the base and learns the project’s terminology. That’s how Claude Code or Cursor get context across several repositories at once. Details — in MCP in Meldoc.
Important: this is not an export and not a synchronized copy. The agent reads exactly the documents the team edits. Fix the docs in the UI — the agent sees the new version.
Door three: external readers
Publishing doesn’t force you to turn Meldoc into a documentation site for your whole product — it’s a way to open a specific contour to the outside: engineering docs for a partner, an API reference, a single project. The access level — Private, Unlisted or Public — is set on a project or on a document. Drafts are never shown to public readers, even in a public project — you can calmly write a draft right next to a published page. For external AI assistants there’s llms.txt at the workspace, project or document level — they find the public content without crawling HTML.
And when “external” isn’t the whole internet but a specific contractor or a neighboring team, there’s the Integration Token: one token type for CLI, CI and MCP, scoped by projects, with Read / Write / Write+Delete levels. A read token can be handed out as limited access without creating a full account. And a token can never do more than its creator — by granting access, you’re not granting anything extra.
Why this is one base, not three
I built Meldoc around a simple idea: the docs live next to the code, and people and agents read the same document. The UI, the MCP server and the public site all open one source — you write a page once, and each audience reads it through its own door. There’s no “internal version” to reconcile with the “external version”. There’s a document, and there are its access settings.
This doesn’t make documentation magically eternal — it can still go stale here. But when it does, there’s one place to fix, not a hunt through three tools for whichever copy is still alive. And once the same text is read by your team, your agents and people outside, it stops being notes “for yourself” — which changes how you write it. That shift deserved its own article: Developers don’t write documentation for themselves.