Markland
Blog

What is agent-native publishing?

Published 2026-05-03 · by

I had this moment last week that probably sounds familiar.

Claude Code finished a 200-line markdown spec for a feature I was scoping. The doc was good — better than I would have written. I needed to share it with someone who is not an engineer and does not have my GitHub account. So I copy-pasted the markdown into Slack, watched the formatting collapse, copy-pasted again into a Notion page, watched the code blocks lose their syntax highlighting, and finally gave up and screenshot-ed my terminal.

Then I sat with it for a minute. The agent had done the work. I had become the bottleneck — a meat-bridge moving bytes between systems that were never designed to talk to each other. That moment is the gap this post is about.

Agent-native publishing, defined

Agent-native publishing is a markdown-first document-sharing model built around the assumption that an AI agent — not a human typing into a rich-text editor — is the primary author. The agent makes one call to a publishing tool (today: an MCP server function like markland_publish) and receives back a URL. A human, or another agent, opens that URL in any browser and reads the exact bytes the agent wrote. No block model. No rich-text round-trip. No account wall for the reader. The publishing surface is a tool the agent already speaks, not a UI the human has to operate on the agent's behalf. Three-way handoff — human-to-human, machine-to-machine, human-to-agent — works without a meat-bridge in the middle.

That definition does some load-bearing work. Let me unpack it.

Why this matters now

Three things changed in the last twelve months that make this a category worth naming.

MCP shipped and stuck. The Model Context Protocol went from "Anthropic's interesting idea" to a thing that Claude Code, Claude Desktop, Cursor, Codex, Continue, and a long tail of custom agents all speak. There is now a real protocol that any of them can use to call out to a server. Before MCP, "give my agent a tool" meant writing a custom integration per client. Today it is one server, many clients.

Agent output volume exploded. If you spend a workday in Claude Code, your agent produces hundreds to thousands of lines of markdown — specs, plans, retrospectives, architecture diagrams in Mermaid, CLAUDE.md updates, pull request summaries, debug transcripts. Most of it never leaves your terminal. The valuable subset — the specs you want to share with a teammate, the plan you want to send to a stakeholder — gets copy-pasted into whatever messaging surface is closest, and the formatting collapses every time.

The existing tools were not built for this. Notion stores documents as a tree of typed blocks; the API parses your markdown into blocks on write and re-serializes them back to markdown on read, and round-trip fidelity is not a guarantee. Google Docs is rich-text first; markdown is best-effort export. Git's sharing unit is a repository, not a document — sharing one private file requires the reader to have a GitHub account and org membership. None of these were wrong; they were built for human-to-human collaboration in eras before agent output was a daily volume problem.

What is missing is a tool whose primary surface is the agent's tool surface, whose primary content type is the bytes the agent wrote, and whose primary distribution model is "URL the reader opens in any browser."

What agent-native publishing is not

It is not a wiki. It is not a knowledge base. It is not a CMS. It is not a Notion replacement for team docs, project management, databases, or rich-text workflows. Those tools solve real problems that this category does not try to solve.

It is also not "publish to the public web." Agent-native publishing covers the full spectrum from public links anyone can read, to share-token URLs for one specific reader, to grant-based access for a named principal (another human, another agent operating on behalf of a human). The publishing surface treats the agent as a first-class caller and the reader as a first-class consumer; everything in between — auth, share tokens, grant lists — is in service of that.

And it is not a paste site. Pastebin and Gist take bytes and return URLs, which is a real share flow, but they were built for humans pasting from clipboards. There is no MCP surface, no per-grant scoping, no fork attribution, no agent-aware versioning. Treating an agent as just another HTTP client misses what is actually different: the agent already has a tool registry. Adding a publishing tool to it is a one-line capability bump for every client that registers the server. That is qualitatively different from "the agent learns to do an HTTP POST."

The four signatures of an agent-native tool

If you are building in this space — and I think a lot more people will be in the next year — there are four design choices that I think distinguish an agent-native tool from a tool that has bolted an "AI feature" onto an existing surface.

The agent's tool is the supported surface. Not "we have a Slack-style integration that uses our REST API behind the scenes." The MCP server is the published interface; the rest of the product is built around what makes sense from inside an agent's tool registry. If your primary docs are about API endpoints rather than tool calls, you are halfway there at best.

The reader path is friction-free. Authentication is necessary for the publisher; an account wall for the reader is friction the agent cannot route around. A URL the reader opens in a browser, today, with no signup, is the right default. Optional gates (share tokens, named grants) for sensitive content go on top — they are not the floor.

Bytes are bytes. Whatever the agent wrote is what the reader sees. No block-tree round-trip. No "best-effort markdown export." If the platform parses the input into a richer structure, the reader sees the platform's interpretation; if the platform stores the input verbatim, the reader sees the agent's intent. For agent-authored content, only the second is honest.

Concurrency is a first-class concern. Two agents writing to the same document is not a corner case — it is the default workflow once two humans use the same tool. Optimistic concurrency with if_version is enough; CRDTs are nice-to-have. Whichever you pick, the failure mode for a race must be a clean conflict the agent can recover from, not a silent overwrite.

These are not hard rules; they are design hints. The category is wide enough for many products that make different tradeoffs. But if a tool's pitch is "agent-native" and it does not satisfy at least three of these four, the label is doing more marketing work than the product.

The Markland take

I built Markland because the moment I described in the opening kept happening. Markland is one implementation of agent-native publishing. There will be others, and that is good — the category is bigger than any single product.

The Markland-specific pitch is short:

  • Your agent calls markland_publish with the markdown bytes and a title. It gets back a URL.
  • The reader opens the URL in any browser. No account. No block model. The bytes you sent are the bytes they see.
  • A second agent, working for a different human, can pick up the same document — read it via markland_get, edit it via markland_update with optimistic concurrency (if_version argument), fork it via markland_fork against the source doc_id. That is the three-way handoff (H2H, M2M, H2M) the definition promised.
  • The MCP server is the supported surface. There is no separate REST API to integrate. Any client that registers an MCP server — Claude Code, Cursor, Codex, Claude Desktop, custom — gets the full publishing-and-grants tool surface (currently around two dozen tools covering publish, list, search, fork, share, grant, invite, and the rest).

It is also early-beta software. The waitlist is on the home page; the quickstart walks you through wiring it into Claude Code in five steps. If you are on Cursor or Codex, the same MCP config snippet works.

Further reading

If you build something in this space, send me a link. I will read it.