Every WYSIWYG editor is a translation layer. And translation layers break.

That's the hot take. Here's why I believe it, and why Postlark ships a plain-text editor instead of the rich text experience everyone expects from a "modern" publishing platform.

The translation problem

A visual editor takes your intent — "make this bold" — and translates it into HTML. Then your CMS stores that HTML. Then your renderer reads it back. Three steps, three chances for something to go wrong. Stray <div> tags, inconsistent <p> wrappers, style attributes that clash with your theme. Anyone who's pasted from Google Docs into WordPress knows the drill. You end up with an invisible graveyard of <span style="font-weight: 400"> tags that do absolutely nothing except make your page heavier.

This was tolerable when humans were the only ones writing. A person can look at the output, see that something's off, and fix it. Annoying, but manageable.

Now add an AI agent to the picture.

AI agents already think in plain text syntax

Ask Claude to write a blog post. What do you get back? Markdown. Ask GPT-4. Same thing. Ask Gemini, Llama, Mistral — every single one returns # headings and **bold** by default. Every major language model was trained on billions of tokens in that format from GitHub READMEs, documentation sites, and developer forums. It's the syntax they know best.

So what happens when you ask an AI agent to publish through a rich text editor? The agent generates its native .md output, then the editor's API expects some proprietary JSON structure — ProseMirror nodes, Slate elements, TipTap documents — and now you need a conversion layer. Plain text to ProseMirror JSON to HTML to rendered output. Each conversion is lossy. Each step is a place where a table loses its alignment, a code block loses its language annotation, or a nested list collapses into a flat one.

Or you could just... accept the source format directly. Skip the translation. Let the agent speak its native language.

That's what we did.

"But users want rich editing"

I heard this a lot. The assumption is that a plain text editor with lightweight markup is hostile to non-technical users. And fifteen years ago, that was probably true. But the world moved.

GitHub normalized this syntax for millions of developers. Notion uses something similar under the hood. Obsidian built an entire productivity cult around plain .md files. Discord, Slack, Reddit — they all rely on the same formatting conventions. The average internet user in 2026 has probably typed **bold** at some point, even if they didn't know what the format was called.

More importantly, Postlark's dashboard includes a split-pane editor. You type on the left, you see the rendered output on the right, in real time. There's a toolbar with buttons for bold, italic, links, headings — click a button, it inserts the right syntax for you. Keyboard shortcuts too. It's not a raw textarea in a monospace font. It's a proper writing environment that happens to store plain text as its source of truth.

The difference is where that truth lives. In a WYSIWYG editor, it's hidden HTML that you never see and can't easily debug. In our editor, it's the text right in front of you. What you type is what gets stored. What gets stored is what gets rendered. No conversion step. No surprises.

One format, ten features

People assume plain .md means bold and italic and nothing else. That stopped being true years ago.

Postlark supports GitHub Flavored Markdown as the baseline — tables, task lists, strikethrough, autolinks. On top of that, we added callout boxes (the > [!NOTE] syntax that GitHub popularized), Mermaid diagrams for flowcharts and architecture visuals, KaTeX for math equations, footnotes, auto-generated table of contents, emoji shortcodes, and syntax-highlighted code blocks with titles and line numbers.

That's ten extensions, all rendered consistently whether you're reading on the blog, previewing in the dashboard, or pulling content through the API. One source format, multiple rendering surfaces, zero conversion artifacts.

Try getting Mermaid diagrams to work reliably in a visual rich text editor. I'll wait.

The API argument

Here's where it gets practical. Postlark's API accepts .md content. The MCP server sends it. The CLI sends it. When an AI agent creates a post, it sends a string of formatted text and that's the end of the story.

Compare this to a platform built around a rich text editor backend. Your API needs to accept either HTML (with all its sanitization headaches) or a proprietary document format (with all its versioning headaches). Your MCP server needs to convert plain text into that structure. Your CLI needs to do the same. Every integration point becomes a conversion point, and every conversion point is a bug waiting to happen.

We tried to be honest with ourselves about who our users are. They're developers running content pipelines. They're using AI agents that output lightweight markup natively. They want to send that output somewhere and have it show up looking good. Inserting a visual editor between the agent and the published post adds complexity with zero benefit for this audience.

The rich text editor isn't dead — it's just not for this

I want to be fair. WYSIWYG editors are fantastic for certain use cases. If you're a marketing team collaborating on landing pages in Webflow, you want visual editing. If you're writing a newsletter in Substack, drag-and-drop blocks make sense. These are human-first workflows where the person writing is also the person formatting.

Postlark isn't that. Postlark is for workflows where the content arrives as text — often from an AI agent, sometimes from a script, occasionally from a human typing in a terminal. In that world, a plain text format isn't a limitation. It's the obvious choice. It's what your tools already speak, what your content already lives in, the syntax that doesn't need a translation layer between creation and publication.

We didn't ditch the visual editor because we couldn't build one. We ditched it because, for AI-native publishing, it's the wrong abstraction.

Next in the series: what MCP is, and why a blog platform has an MCP server in the first place. If this lightweight syntax is the language AI agents write in, MCP is how they find the door to walk through.