Markdown Eats the Office

The Signal Nobody Saw Coming

For fifteen years, markdown was a developer thing. README files, GitHub comments, static site generators, the occasional note-taking app. Civilians used Word. Lawyers used Word. Managers used Word. Markdown lived in text editors and terminal windows and nowhere else.

Then, quietly, two things happened in the last eighteen months that together mark the end of that era.

First, Microsoft shipped a markdown adapter for Word — a plugin that lets you edit markdown inside the familiar Word chrome and round-trip between the two formats without losing your mind. The company that made .docx the default document format of the planet now treats markdown as a first-class citizen inside its flagship product.

Second, Microsoft’s MarkItDown — a Python tool that converts anything (PDFs, Word docs, PowerPoints, Excel sheets, HTML, images) into markdown — crossed 91,000 GitHub stars since its late-2024 launch. It is one of the most popular Python repositories Microsoft has ever published. The reason isn’t that developers suddenly discovered markdown. The reason is that markdown has become the format AI systems read best, and every team building a RAG pipeline or an agent workflow needs to get their messy document archive into markdown as fast as possible.

Put those two together and the picture is clear. Markdown stopped being the format developers prefer. It became the format that humans, machines, and AI agents all speak fluently — the first format in computing history where that’s true.

Why AI Made Markdown Win

There’s a good reason markdown is winning, and it has nothing to do with aesthetics.

Large language models tokenize markdown efficiently. Headings, lists, tables, code blocks, links — all of it maps to structure the model can use without being hidden behind binary encoding, XML bloat, or proprietary schemas. A .docx file is a zip archive of XML. A PDF is a postscript descendant optimized for fixed-layout printing. An .xlsx is a ZIP archive of XML. Getting an AI to reason about any of these involves first converting them to… markdown. That’s what MarkItDown does. That’s why it has 91,000 stars.

Markdown also round-trips with plain text. You can grep it. You can diff it in git. You can view it in any editor on any operating system for the next fifty years without worrying about whether the format will still open. It’s the longest-lived document format that anyone is actively improving, because it’s so simple there’s almost nothing to improve.

For the first time since the personal computer existed, there’s a document format that is equally good for a human reader, a version control system, a full-text search index, and an AI agent. That has never been true before. Every other format optimized for exactly one of those four constituencies at the expense of the other three.

The Problem Nobody Talks About

If markdown is winning, you’d expect the tools around it to be great. They aren’t. The reading experience especially is stuck in 2012.

• VS Code’s built-in preview hardcodes double-click-to-edit. There is no setting to turn it off. Open a markdown file to read it, misclick by a pixel, congratulations — you’re editing your documentation by accident.
• Obsidian is a great tool for notes, but it’s opinionated about vaults, plugins, and graph views. It’s an app. Your markdown lives inside its world.
• Typora is elegant but is a WYSIWYG editor, not a reader. It also had a controversial licensing transition and lost trust.
• iA Writer is beautiful but minimalist to a fault — no integrated search across your codebase, no live connection to your operational docs, no awareness that the markdown file you’re reading is part of a larger system.
• Browser-based markdown previews (GitHub, GitLab, etc.) are great for looking at one file on a remote server. They are not reading tools for the markdown on your disk.

Meanwhile, the volume of markdown on the average developer’s laptop just exploded. Every project now has a CLAUDE.md and an AGENTS.md and a README and a CONTRIBUTING and architecture notes and migration guides. Every team that adopted Shape Up has pitches and cycles and retrospectives. Every AI-era developer has prompt libraries, design docs, and captured conversations. The markdown surface area on a typical machine has grown ten-fold in two years.

And the tool everyone uses to read it is… an accidentally-editable preview pane that came with their code editor.

Gloss: Reading as a First-Class Operation

Gloss was built to fix exactly this. It started with one opinion — reading and editing are different modes, and they should not share a single accidental click — and grew from there.

What Gloss is today:

• A true read-only markdown viewer inside VS Code. No editor buffer. No hidden edit state. No double-click surprise. When you open a markdown file with Gloss, you are reading it. When you want to edit, you press Cmd+Shift+E and explicitly switch modes. The separation is intentional, the way a library is different from a printing press.
• Syntax-highlighted code blocks with copy buttons. Because 40% of a modern markdown file is code, and reading code inside prose is how you actually learn what a system does.
• Clean light and dark themes. Because you stare at markdown for hours.
• Live file watching. Because the files you’re reading are the same files AI agents and your teammates are editing.
• Zero telemetry. No analytics. No usage tracking. No “we promise we don’t collect personal data.” No network calls at all, except optionally to your own Merrily instance.

That’s what exists now. What Gloss is becoming is more interesting.

Editing Without Leaving the Reader

The next step is a proper markdown editor mode inside Gloss itself. Not a new window, not a different app — the same viewer, with the ability to switch into a focused editing experience that respects the file’s structure.

The design principle is intentional mode switching. Reading is the default because reading is what you do most. Editing is one keystroke away but never accidental. When you do edit, you get:

• Live preview that matches the reading mode exactly, so there’s no cognitive jump between the two
• Frontmatter-aware editing, so YAML headers don’t fight you
• Code block editing with the language’s own syntax highlighting
• Table editing that doesn’t require counting pipes by hand
• Outline navigation for long documents, because a 5,000-word design doc needs more than scroll

This isn’t trying to be Obsidian. It isn’t trying to be Notion. It’s trying to be the best possible way to read and edit the markdown files already on your disk, inside the editor where you already spend your day.

The Knowledgebase Nobody Realized They Had

Here’s the bigger shift. If every project has dozens of markdown files, and every team has hundreds, and the organization has thousands — that’s a knowledgebase. You just don’t have a tool that treats it like one.

Gloss is going to be that tool. The roadmap:

• Full-text search across your entire markdown surface. Every README, every design doc, every meeting note, every PROJECT_PLAN, every Shape Up pitch — searchable in milliseconds from inside VS Code. No indexing service to run. No separate app to switch to.
• Semantic search when you want it. Local embeddings, no data leaving your machine, find documents by meaning instead of exact word match. The same privacy-first architecture that the rest of the MCG portfolio uses — you control the index, it lives on your disk, nothing ships to a server.
• Cross-project linking. Your CLAUDE.md references a strategy doc in another repo. Gloss resolves the link, shows you a preview, and lets you jump to it without leaving the reading mode.
• Activity tracking. Which docs did you read this week? Which did your AI agents read? Which haven’t been touched in six months and might be stale? The kind of insight a knowledgebase tool should give you by default.
• Merrily integration, deepened. Your pitches, cycles, hill charts, and retrospectives already live as markdown in Merrily. Gloss becomes the reading surface for all of it — the operational knowledgebase for the work your tiny team is doing, browsable from inside the editor where the work actually happens.

The goal is not a new app. The goal is to take the markdown you already have — the markdown AI agents and VS Code and git and your teammates and Microsoft Word are all now editing in parallel — and make it navigable, searchable, and understandable as the living knowledgebase it already is.

Why This Fits the Bet

This story sits downstream of two bets the rest of the MCG portfolio has already made.

The first is the bet that the individual builder and the tiny team are the dominant economic unit of the next decade. Those builders don’t have a Confluence license or a Notion admin. They have a folder of markdown files and a VS Code window. The tool that helps them treat that folder as a real knowledgebase wins their attention, because there is no competing tool aimed squarely at them.

The second is the bet that AI-native coordination replaces the 60% overhead tax of traditional project management. AI agents are already reading and writing your markdown files — CLAUDE.md instructions, shaped pitches, status updates, retrospective notes. The human side of that loop needs a reading environment that keeps up. Gloss is that environment.

And underneath both bets is the privacy-first architecture that the rest of the portfolio is built on. Your markdown is yours. Your knowledgebase lives on your disk. No cloud sync you didn’t opt into, no telemetry, no vendor that can see what you’re working on. The same principles that make first-party data a competitive advantage for MCG products make a local-first markdown knowledgebase the only sensible design for the tool that reads them.

The Punchline

Microsoft blessing markdown inside Word and shipping MarkItDown to 91,000 GitHub stars isn’t a small story. It’s the moment markdown stopped being a format and became an ecosystem — the first document ecosystem where humans, AI, and version control are all equally at home.

Every ecosystem needs a reading environment. VS Code’s accidentally-editable preview pane is not it. Obsidian is an app, not a reader. Typora and iA Writer are editors that forgot the reading use case. The browser-based previews don’t touch your local files.

Gloss is the reading environment. And the next version is the editor, and the search engine, and the knowledgebase view — for the markdown you already have, the markdown your team is writing, the markdown your AI agents are producing, and the markdown the rest of the industry is finally catching up to.

Install it from the VS Code Marketplace. Read the markdown on your disk like it was meant to be read. The knowledgebase has been there all along.