Markdown Is the Operating System. Everything Else Is a Render.

I haven’t opened a Word document to write anything in six months. Not because I don’t produce Word documents — I produce dozens. But I never author in Word. I author in Markdown. Word is a render.

This distinction — between authoring formats and rendering formats — turns out to be the single most consequential architectural decision in an AI-native workflow. Get it wrong and every agent interaction is slower, every edit is harder, every version is harder to track. Get it right and your entire knowledge surface becomes instantly readable, writable, diffable, and searchable by both humans and agents.

The industry is converging on this conclusion from multiple angles. But to understand why it matters, you have to understand the problem it solves.

The Fundamental Problem: Knowledge Distribution

Knowledge work has always had two halves: creation and distribution. AI has largely solved creation — coding agents write code, content agents write docs, analysis agents produce reports. The build side is accelerating fast.

But distribution? Still broken. Forbes reported in May 2026 that knowledge management “may be AI’s salvation” — yet the underlying architecture remains the same one that’s failed for two decades. ServiceAide puts it bluntly: “The problem isn’t volume. It’s architecture. Enterprise knowledge lives in the wrong places, maintained by the wrong mechanisms, delivered through the wrong model.”

Unite.AI reports that 42% of companies have abandoned most of their AI initiatives — not because the technology doesn’t work, but because the knowledge problem wasn’t solved first. Gartner forecasts 40% of agentic AI projects will be shut down by end of 2027 for the same reason.

The distribution problem is layered:

• Leaders need the right insights at the right time — strategic alignment, decision context
• Teams need shared operational knowledge — procedures, playbooks, account context
• Individual contributors need answers at the point of work — without leaving their tool
• Agents need structured, queryable knowledge — without extraction pipelines and format conversion

Every one of these is a knowledge distribution problem. And every one of them is blocked by the same bottleneck: the knowledge is stored in formats that can’t be efficiently authored, versioned, searched, or served to agents.

This post proposes an architecture that solves all four layers. The format is the foundation.

The Three-Layer Stack

My operating model uses exactly three file formats for authoring:

Everything else — PDF, Word, PowerPoint, Excel — is a rendered output. It exists only at the moment of distribution, for a specific audience, for a specific purpose.

The Industry Is Converging

This isn’t a solo opinion. The convergence is happening across the entire AI-native ecosystem:

Extency’s research (May 2026) — “The Best ‘Brain’ for Business Agents Is Just Versioned Folders of Markdown Files”: “The AI industry spent millions on vector databases and proprietary memory systems. The winning architecture is simpler: plain markdown files in versioned folders.” Their conclusion: GBrain, DiffMem, and a growing wave of production systems are converging on Git-backed markdown as the default agent brain. The folder is the product.

Beam.ai’s analysis (May 2026) — “HTML vs Markdown: Which Format Actually Makes AI Agents More Useful?”: Converting HTML to markdown reduces token usage by 68% for clean content and up to 87% for real-world web pages. In GPT-based table extraction benchmarks, markdown representations achieved 60.7% accuracy vs. 53.6% for HTML tables. RAG pipelines see up to 35% accuracy improvement when ingesting markdown over raw HTML.

Paul Shortridge (March 2026) — “Everything Is Markdown Now”: “My AI development setup is almost entirely markdown files. CLAUDE.md for project context. Skills in .claude/skills/. Agent definitions in .claude/agents/. Specs in plans/. System prompts, review checklists, style guides: all markdown.” His key insight: markdown configuration gives you model portability — when the US DoD’s Anthropic deal collapsed in 2026, teams with markdown-based workflows switched providers by pointing a different model at the same files. Teams with proprietary formats had to rebuild.

GitHub Agentic Workflows (Feb 2026) — GitHub replaced complex YAML CI/CD configurations with plain Markdown files that AI agents interpret and execute. The same format shift: instead of proprietary configs, describe intent in text. The agent figures out the rest.

AGENTS.md adoption — Over 60,000 repositories now use AGENTS.md, a single Markdown file at the repo root that tells AI coding tools how to work on a project. Teams report 35–55% fewer AI-generated bugs when the agent has a well-structured markdown context file.

The HTML debate proves the point. Andrej Karpathy and Thariq Shihipar (Claude Code team) both argue for HTML as output — rendered, visual, consumable. But even they don’t argue for HTML as source. The authoring layer remains plain text. The rendering layer is what varies by audience. That’s exactly the pattern: author in text, render for consumption.

Tools for Humans (March 2026) — “How Markdown Files Became the Control Layer for AI Tools”: “Markdown configuration files won because they are the only format that developers, AI models, and non-technical stakeholders can all read and edit without friction.”

WorkOS (April 2026) — “Your Docs Have a New Audience”: WorkOS rebuilt their entire docs pipeline to serve clean, dynamic markdown via content negotiation — because AI agents are now a significant audience, and most sites serve them unparseable HTML.

The signal is consistent: every team building AI-native workflows — from solo builders to enterprise platforms — is converging on plain text (Markdown, YAML, JSON) as the authoring and storage layer, with rich formats generated on demand for human consumption.

The Numbers

The token economics alone make the case:

• Markdown vs HTML: 68% fewer tokens for equivalent content (Cloudflare’s “Markdown for Agents” feature was built specifically for this)
• Markdown vs DOCX XML: ~3x more token-efficient for the same prose (DOCX carries XML namespace declarations, style definitions, and relationship mappings that add zero information for the agent)
• RAG accuracy: 35% improvement when ingesting markdown over raw HTML in retrieval pipelines
• Storage: A 2,000-word Markdown file is ~12KB. The same content in DOCX is 50-100KB.

Why This Matters for Agents

Building has always happened in code. Code is plain text — machine-readable, diffable, composable. Developers never had this problem. Their working format was already agent-native.

Knowledge work didn’t get that lucky. Proposals live in Word. Strategies live in PowerPoint. Budgets live in Excel. Meeting notes live in OneNote. All of these are opaque binary containers that agents can’t efficiently read, write, diff, or compose.

That’s the structural gap. AI collapsed the build path — coding agents write, test, and deploy code at machine speed because the format was always right. Knowledge work still drags because the formats are wrong. Agents can do the thinking, but they’re fighting the container every step of the way.

When you switch to plain text for knowledge work, the gap closes:

Writing anything — a strategy doc, a proposal, meeting notes, an account brief, a blog post — the agent produces Markdown in one tool call. Done. No library imports. No document object model. No XML manipulation.

Editing anything — apply a unified diff. Surgical, line-level, takes milliseconds. The same mechanism that makes git work for code now works for every piece of knowledge work.

Composing across documents — pull a section from one .md file, combine it with data from a .csv, generate a briefing. No extraction step. No format conversion. No library.

Compare that to the Word path:

Editing Markdown: Apply a unified diff — surgical, line-level, takes milliseconds.

Editing Word: Load the full DOCX (which is a ZIP of XML files), parse the document tree, find the target paragraph by traversing the XML DOM, modify the run element, handle style inheritance, re-serialize, save. Takes seconds, requires a library, and the diff isn’t human-reviewable afterward.

Across hundreds of agent interactions per day — proposals, account context updates, meeting summaries, triage reports, strategy drafts, pipeline analyses — this difference compounds into hours of saved compute and eliminated failure modes.

And it’s not only about speed. It’s about what becomes possible. When your knowledge artifacts are plain text:

• Agents can chain operations: read account context → pull spend data → generate briefing → email it — all without a single format conversion
• Scheduled agents can update files on a cadence without lock file conflicts or cloud sync races
• Multiple agents can work on the same knowledge surface without the binary merge conflicts that plague Word and PowerPoint
• Every change is trackable, reviewable, and reversible — the same version control that makes code reliable now makes knowledge work reliable

Code got version control, CI/CD, and collaborative workflows decades ago because the format was right. Knowledge work is finally getting the same capabilities — but only if you stop storing knowledge in formats that were designed for printers.

The Render-on-Demand Pattern

When I need a Word document — for a formal proposal, an executive briefing, a customer deliverable — I don’t switch formats. I render:

Markdown source → render skill → .docx output

The render skill handles formatting: headings map to Word styles, tables get proper borders, code blocks get Courier New, bold and italic carry through. The output looks professional. But the source remains Markdown — versionable, diffable, agent-native.

Same pattern for every rendered format:

The source never changes format. Only the output does. And the output is ephemeral — it exists for the recipient, not for me. I never edit the rendered output. If something needs to change, I change the Markdown and re-render.

Why Traditional Formats Are Traps

Word, PowerPoint, and Excel are great consumption formats. They’re terrible authoring formats for AI-native work because:

They’re opaque to agents. A .docx file is a ZIP containing XML. An agent can’t grep it, can’t diff it against last week’s version, can’t apply a surgical edit without loading the entire document model. Every interaction requires a heavyweight library.

They break version control. Git can track Markdown line-by-line. It can’t meaningfully diff a binary Word file. You lose the entire history of what changed and why.

They trap knowledge. Content locked in a PPTX can’t be indexed by RAG, can’t be queried via NLQ, can’t be composed into other documents without extraction. The format is a prison for the knowledge inside it.

They create sync problems. I’ve documented elsewhere how cloud sync daemons’ ~$ lock files, binary merge conflicts, and eventual consistency break agent workflows. None of these problems exist with plain text files.

They couple authoring to rendering. When you write in Word, you’re simultaneously deciding content AND formatting. That coupling means every revision touches both — and the formatting decisions are invisible to anyone reviewing the change.

The Full Operating Model

Here’s what my working filesystem looks like:

# Knowledge work (the content)
customers/                ← .md context files, .yaml configs, .csv signals
partners/                 ← .md partner pages, deal constructs, co-sell data
product-strategy/         ← .md proposals, theses, architecture decisions
field-insights/           ← .md research, competitive analysis, market signals
blogs/                    ← .md posts, rendered to web via build pipeline

# Agent infrastructure (the operating system)
agent-registry/           ← .csv files: accounts, people, channels, triage rules, contact maps
agent-workspace/          ← active tasks, signal streams, dashboards, triage queues
agent-infra/              ← .md references, .yaml configs, skill definitions, engrams, MCP setup

# Distribution (the output layer)
distribution-decks/       ← rendered outputs (.pptx, .pdf, .docx) — the ONLY place binary formats live

Three layers, all plain text except the last:

• Knowledge work — the actual content you produce and consume. Proposals, account intelligence, research, blog posts. All .md, .yaml, .csv.
• Agent infrastructure — the operating layer that makes agents effective. The registry tells agents who and what exists. The workspace is where agents track active work and state. Infra holds the configuration: skill definitions, voice engrams, MCP server references, auth patterns. Think of it as the agent’s own codebase — version-controlled, diffable, evolvable.
• Distribution — the only place rendered formats exist. When someone needs a deck, a PDF, or a formatted Word doc, agents render from the text source into distribution-decks/. These are ephemeral outputs, not sources of truth.

When I receive a .docx or .pptx, the first thing I do is extract the content to Markdown. Now it’s part of my knowledge surface — searchable, composable, agent-accessible. The original binary goes to distribution-decks/ as an archive. The knowledge lives in text.

Plain Text Gives Your Agent a Brain

Here’s what happens the moment your knowledge work is in AI-native formats:

An AI desktop agent — any modern harness — can automatically index your entire workspace. Keyword search, semantic search, knowledge graph construction — all happen automatically over plain text files. Your agent gets a brain built from your actual work. It understands your customers, your strategy, your partners, your pipeline — because it can read everything.

Folder structures become routing instructions. Folder names become context signals. A file in customers/acme/ tells the agent everything it needs to know about scope before reading a single line. The filesystem is the agent’s routing layer — and it only works when the files are readable.

Try that with a folder full of .docx and .pptx files. The agent can’t keyword search them without extraction. Can’t build a knowledge graph from them without parsing XML. Can’t semantically index them without a conversion pipeline. Every binary format adds an extraction tax before the agent can even begin to understand your work.

With plain text, the harness does all of this for free:

• Keyword search — instant, no preprocessing
• Semantic indexing — chunks cleanly at paragraph boundaries
• Knowledge graph — entities, relationships, and connections extracted directly
• Context loading — agents read exactly what they need, no extraction step

Your workspace becomes the brain. The agent doesn’t need a separate memory system or a vector database you maintain — your files are the memory. Structured, versioned, always current.

And because everything is text, agents can rescan your workspace at any time and realign — discovering new connections, updating stale context, suggesting restructuring to make things more discoverable. The workspace evolves alongside your work.

The Collaboration Model Changes Too

The last objection: “But I need to collaborate with people in Word and PowerPoint.”

Two responses:

For people outside your organization — render on demand. They receive the format they expect (PDF, DOCX, PPTX). You authored in text. The render costs seconds. This has always been the pattern for code documentation — nobody sends people a git repo when they want a PDF spec sheet.

For people inside your organization who work in agent-native mode — Git-based collaboration replaces real-time editing. Pull requests, merge requests, structured reviews. This isn’t theoretical — it’s how open source communities have collaborated on text for decades. Over 60,000 repositories now use AGENTS.md for AI-native collaboration. GitHub’s Agentic Workflows let you describe intent in Markdown and agents execute it. Git worktrees enable parallel agent work on the same repo without conflicts.

For most external communication — it happens on Slack and email anyway. And those platforms are becoming agent communication buses.

This is the part nobody talks about: Slack and email are already durable, history-maintaining platforms. Every message is timestamped, searchable, attributed. When your agent writes a comprehensive update directly in a Slack channel or composes a detailed email, that is the deliverable. No separate document needed. The channel maintains the history. The thread maintains the context.

Salesforce is turning Slack into the interface for AI at work — Slackbot now drafts, summarizes, triggers workflows, and takes action across systems. Gartner projects 40% of enterprise applications will integrate task-specific AI agents by end of 2026 (up from less than 5% a year ago). Red Hat built an architecture where users interact with a single AI agent across Slack, email, and ServiceNow without losing context.

The pattern: Slack channels and email threads are communication buses between agents and humans. They’re durable (history is preserved), searchable (full-text, API-accessible), attributed (who said what, when), and already integrated with every tool in the stack. You don’t need to produce a separate Word document when the Slack thread is the document.

Your agent reads the workspace (plain text files), synthesizes the answer, and writes it directly where the conversation is happening — Slack, email, or a shared channel. The recipient gets a fully-formed response. No attachment. No “please see attached.” No “I’ll send over the doc.” The response is the content.

And because these platforms maintain history, they become durable constructs themselves:

• Three months from now, someone searches Slack for “what was the decision on X?” — the agent’s detailed response is right there, timestamped, in context
• Email threads become queryable knowledge — your agent wrote the comprehensive reply, and that reply is now searchable by any other agent or person who needs it
• Every channel becomes a living document that accumulates institutional knowledge through conversation

The communication bus replaces the document in most cases. The document only exists when someone specifically needs a standalone artifact — a contract, a formal proposal, a board deck. For the 90% of knowledge exchange that happens between colleagues, the bus is the medium and the record.

The collaboration model that built Linux, Kubernetes, and every major open-source project is the same model that works for AI-native knowledge work: propose a change (MR/PR), review it, merge it. The difference: AI agents can now produce the proposals, review the changes, and surface conflicts — all because the format is text.

And increasingly, the “real-time collaboration” argument is moot. When an AI agent can produce a fully-formed document in seconds, you don’t need three people simultaneously editing the same file. You need one agent producing a draft, a review cycle, and a merge. That’s faster, produces cleaner output, and maintains a reviewable history.

McKinsey found that knowledge workers spend 20% of their time searching for information. The format problem compounds this — information locked in binary formats is harder to find, harder to index, and harder for agents to surface at the point of need. Plain text eliminates the search tax entirely.

The Solution Is Git

So what’s the actual infrastructure? Where does the knowledge live? How does it get there? How do agents read it?

The answer is simpler than the industry wants to admit: Git is the universal write path. The read path is what varies.

WRITE PATH (universal):
  Author locally (plain text) → commit → push to Git
  Agent writes locally → commit → push to Git
  Scheduled agent produces report → commit → push to Git

READ PATHS (multiple, all from the same Git source):
  ├── MCP server → agents query via Model Context Protocol
  ├── RAG / knowledge store → NLQ retrieval, semantic search
  ├── Slack agent → community-facing, conversational access
  ├── Web render → static site (Astro, MkDocs, Hugo)
  └── Direct file read → local agents with repo access

The write path is AI-native by default. Agents write files. Files go to Git. Git is the durability layer — version-controlled, distributed, conflict-resistant. Every agent, every human, every scheduled process uses the same mechanism. This isn’t novel — it’s what software engineering has used for decades. The novel part is extending it to all knowledge work.

The read path is where it gets interesting. From a single Git-backed repository of plain text, you can serve multiple consumers simultaneously:

MCP — the Model Context Protocol exposes your knowledge as tools that any agent can call. An MCP server over your Git repo lets any AI assistant — regardless of harness — query your knowledge base. It’s the universal read path for agents. Palinode demonstrates this: Git-native persistent memory served via MCP.

RAG / knowledge store — platforms that do NLQ retrieval natively over files. You point them at your Git output (synced to S3, or directly) and they handle chunking, embedding, semantic search. No custom vector database to maintain. No Lambda functions. No embedding pipelines. The platform does it for you.

Slack agents — a read path that serves communities. An agent running on a cloud runtime (like AgentCore) gets invoked on every thread in a channel. It reads the Git-backed knowledge source and responds inline — turning every Slack channel into a queryable knowledge interface without anyone needing to leave the conversation. Different teams can have their own Slack agents backed by the same knowledge repo. The agent reads Git, answers conversationally, and the thread itself becomes an annotation layer on top of the knowledge — community-style notes, corrections, and context that enrich the source over time.

Web + llms.txt — a static site generator renders the same Markdown files as a browsable website. But the site has two audiences now. Browsers render HTML for humans. llms.txt serves structured text for agents.

The distinction between llms.txt and MCP matters:

Both read from the same Git source. llms-full.txt is auto-generated at build time (every post concatenated into one file). MCP is an active server that chunks, embeds, and serves ranked results on demand. You want both — llms.txt for discovery and broad indexing, MCP for precision retrieval at the point of work.

The Full Pipeline: Write to Read in Under a Minute

Here’s the pipeline that ties everything together — four stages, each AI-native:

1. Context creation      → Human thought, knowledge, observation
2. Content creation      → AI turns thought into structured artifact (Markdown)
3. Distribution          → AI pushes to Git → S3 → knowledge store (automatic)
4. Available to everyone → Queryable by anyone with access, next minute

Stage 1: Context creation from human thought. You have an insight, a decision, a finding, an observation. This is the irreplaceable human input — the thing AI can’t originate.

Stage 2: Content creation with AI. Your agent turns that thought into a structured artifact — a Markdown file with proper frontmatter, linked context, citations. What used to take 45 minutes of writing takes seconds. The format is AI-native from birth.

Stage 3: Distribution with AI. The agent pushes to Git. A sync triggers. The file lands in S3 (with full versioning on top of Git’s versioning — belt and suspenders). S3 feeds the knowledge store.

Stage 4: Available to everyone who queries it — the next minute. Anyone with access to that knowledge store can immediately query the new knowledge from their AI desktop agent. Full NLQ. Full semantic search. No email required. No “here’s the latest version.” The knowledge arrived the moment it was created.

From human thought to universally queryable knowledge in under a minute. That’s a fully AI-native write path AND a fully AI-native read path. The knowledge flows from author to consumer through infrastructure, not through human coordination.

The backing store is flexible:

Pick whatever your organization already uses. The knowledge store abstracts the storage. The intelligence layer — chunking, embedding, NLQ retrieval — works identically regardless of which backing store feeds it.

A Knowledge Store Makes Everything Composable

Here’s where the architecture becomes powerful in the field.

A knowledge store isn’t just a document store with a search bar. It’s a full NLQ surface — query it conversationally, get ranked results, ask follow-up questions, pull structured data. Your agent can search it, extract knowledge from it, and bring that knowledge into your working context automatically. The knowledge store becomes part of your agent’s brain.

This is the field experience: you’re at an airport, between flights, and a text comes in asking about spend on a specific deal. You open your phone, query the knowledge store through your agent, get the answer in seconds, compose a report, and email it back — all before boarding. The dashboard that lives in the knowledge store traveled with you because the read path is device-independent. The intelligence layer doesn’t care whether you’re on a laptop in a conference room or a phone in a terminal.

What makes this composable rather than just searchable:

Anything already in your context, the agent uses directly. Knowledge the agent has already extracted from your knowledge stores — account context, deal history, competitive positioning — is ambient. No explicit query needed. It’s part of your memory.

Anything not yet in context, the agent searches automatically. When the question requires knowledge the agent doesn’t have cached, it searches your knowledge stores in real-time, pulls the relevant chunks, and incorporates them into the response. The boundary between “what I know” and “what I can find” becomes invisible to you.

From that composed context, you produce anything. PDFs. Customer proposals. Email responses. Slack updates. Executive briefings. The agent draws from the knowledge store, from your local files, from the knowledge graph, from recent conversations — and renders whatever output the moment demands. The output format is a choice at the point of delivery, not a constraint on how knowledge is stored.

This is what “composable with agents” means in practice:

WRITE PATH (asynchronous, distributed):
  Contributor A writes insight → pushes to Git → syncs to knowledge store
  Contributor B updates account context → pushes to Git → syncs to knowledge store
  Scheduled agent produces weekly report → pushes to Git → syncs to knowledge store
  Knowledge accumulates without coordination

READ PATH (on-demand, composable):
  Agent receives question
  → Checks local context (already extracted knowledge)
  → Searches knowledge stores for anything missing
  → Composes answer from multiple sources
  → Renders in whatever format the moment requires
  → Delivers: email, Slack message, PDF, deck, or inline answer

The write path is asynchronous. Contributors push when they have something — no coordination required, no meetings about who updates what. The knowledge just accumulates. The read path is on-demand. The agent pulls what it needs, when it needs it, and composes the output for whoever asked.

This is where the field coordination bottleneck collapses. The old model: request information → wait for someone to compile it → receive a document → extract what you need → forward it. The new model: ask your agent → agent queries the knowledge store → answer arrives composed and formatted. The human coordination layer disappears. The information distance between any contributor and any consumer collapses to a single agent query.

And because the knowledge store is backed by Git, every piece of knowledge has provenance. You can trace any answer back to the commit that introduced it, the person who wrote it, the date it was added. The composability doesn’t sacrifice auditability.

Beyond Knowledge: Skills Distribution

There’s a fourth layer that this architecture enables: skills distribution.

Skills are durable workflows — reusable procedures that encode institutional knowledge about how to do something, not just what to know. A triage process. A publish workflow. A customer research protocol. A deal construct template. When these live as plain text files (Markdown skill definitions) in a Git repo, they become distributable the same way knowledge does.

This isn’t theoretical. Arxiv published “AI Skills as the Institutional Knowledge Primitive” (March 2026): “Enterprise software organizations accumulate critical institutional knowledge — architectural decisions, deployment procedures, compliance policies, incident playbooks — yet this knowledge remains trapped in formats designed for human interpretation.” The paper proposes skills as the unit of institutional knowledge that agents can discover and execute.

Microsoft is building this into Dataverse — “skills are reusable processes built with natural-language instructions that AI agents discover then follow once they are invoked.” Glean launched enterprise skills supporting the open Agent Skills standard. EvoSkill demonstrates automatic skill discovery through failure analysis. SkillFoundry converts heterogeneous resources into validated, reusable agent skill packages.

The pattern mirrors knowledge distribution exactly:

Skills in a Git repo get discovered by agents the same way knowledge does. An agent scanning your workspace finds not only what you know but how you work. It discovers triage procedures, publishing workflows, research protocols — and can execute them immediately. The skill is the institutional knowledge made executable. When you share the repo, you share not just the information but the capability.

Here’s what this architecture replaces:

The custom knowledge base infrastructure I built — MCP server, Lambda, Bedrock Knowledge Base, Cohere embedding config, S3 sync pipeline, chunking strategy — all of it exists because the write path and read path were separate systems with separate formats. With Git as the canonical store and platform-native read paths, most of that infrastructure disappears.

The pattern scales from personal to enterprise:

• Personal: write to a local Git repo, read via your desktop agent’s native indexing
• Team: shared Git repo, multiple read paths (MCP for agents, knowledge stores for NLQ, Slack bot for team Q&A)
• Enterprise: Git-backed knowledge infrastructure, branch-based access control, MR-gated publishing, multiple department-specific read surfaces

This is what knowledge engineering actually looks like: structured text, versioned in Git, delivered at the point of need through whatever read path the consumer prefers. The consumer might be a human reading a website. It might be an agent calling an MCP tool. It might be a colleague asking a Slack bot. All of them read from the same source. None of them need the knowledge to be in Word.

The Cloud Document Library Implication

This is why my cloud document library is all Markdown. Not because these platforms can’t host Word files — they can. But because:

1. Most platforms render .md natively — GitHub, GitLab, SharePoint, Notion imports, and dozens of others render Markdown with formatting in the browser
2. RAG systems index .md perfectly — every file becomes NLQ-queryable without extraction
3. Agents can read and write .md files via API — no conversion step needed
4. Diffs are meaningful — when something changes, you can see what changed

If a collaborator specifically needs a Word doc, I render one on demand and share that. But the canonical version remains Markdown. Always.

The Token Economics

Beyond the workflow benefits, there’s a pure cost argument:

• Token cost: Markdown is ~3x more token-efficient than equivalent DOCX XML for the same content
• Compute cost: Agent operations on text files are 10-100x faster than operations on binary document formats
• Storage cost: A 2,000-word Markdown file is ~12KB. The same content in DOCX is 50-100KB
• RAG cost: Markdown chunks cleanly at paragraph boundaries. DOCX requires extraction, which loses table structure and introduces artifacts

At scale — hundreds of agent interactions per day, thousands of files in a knowledge surface — these differences matter.

Live Collaboration: Dissolved, Not Unsolved

The obvious objection: “What about Google Docs-style simultaneous editing?”

This question assumes collaboration means two humans editing the same document at the same time. That assumption belongs to the pre-agent era — when writing took hours, and having multiple people edit simultaneously was a force multiplier on a scarce resource (authoring time).

When writing takes seconds, the bottleneck shifts from authoring speed to review quality. There’s nothing to co-edit in real time because the writing phase is nearly instantaneous.

Matt Cromwell made this argument about WordPress in March 2026: real-time collaboration “sounds exactly like the kind of ‘game-changing’ feature a mature platform should have” — yet the dedicated real-time collab plugin for WordPress has 300 active installs, not 3 million. The capability exists. Almost nobody needs it. “The real friction is still construction, not collaboration.”

Addy Osmani described the same shift for coding agents — the move from “conductor” (one agent, synchronous, real-time guidance) to “orchestrator” (multiple agents, asynchronous, parallel execution). The winning pattern isn’t live co-editing. It’s decomposition + async execution + merge. File locks and worktrees handle conflicts. Nobody’s doing collaborative cursors on the same file.

The Harvard Data Science Review (Winter 2026) contrasts human-driven coordination (“meetings and emails”) with agent-driven coordination (“real-time agent protocols”). In agent-driven organizations, the coordination happens between machines asynchronously — not between humans editing the same paragraph simultaneously.

The collaboration model that actually works in the agent era:

1. Agent produces a draft — seconds, not hours
2. Human reviews — the scarce, valuable step
3. Merge — Git handles this. Has for decades.

That’s faster than three people arguing about commas in real time. It produces cleaner output. It maintains a reviewable history. And it works asynchronously — no one needs to be online at the same time.

The “problem” of live collaboration isn’t unsolved. It’s dissolved. The format that enabled it (Google Docs, Office Online) solved a bottleneck that no longer exists when agents write at machine speed. What remains is review and decision — and those are conversations (Slack threads, PR comments, email), not cursor positions in a shared document.

So What

The industry has spoken — from Extency to GitHub to Cloudflare to the 60,000+ repos using AGENTS.md. Plain text is winning not because it’s trendy, but because it’s the only format that serves all three audiences simultaneously: humans who read, agents who process, and version control systems that track.

The thesis: if your working files are in formats that agents can’t read, write, diff, or query at machine speed, your agents are sidecars, not teammates.

The AI-native operating model is text-first:

• Author in Markdown, YAML, CSV — always
• Render to PDF, DOCX, PPTX — only at the moment of distribution
• Never edit the rendered output — change the source, re-render
• Extract incoming binary formats to text immediately — make the knowledge accessible

This isn’t about being anti-Word or anti-PowerPoint. Those formats serve real purposes for human consumption. But they’re consumption formats, not authoring formats. The moment you treat them as source-of-truth, you’ve created a knowledge prison that agents can’t efficiently access and that version control can’t meaningfully track.

Markdown is the operating system. Everything else is a render.