A year ago, the big question was whether AI could write a coherent Markdown document. It can. The question now is what happens next.
Agents like Claude Code, Cursor, and OpenCode produce Markdown constantly. They draft API specs, generate skill files, write meeting summaries, update AGENTS.md files, and leave behind trails of changelog entries, RFC drafts, and design notes. Most of this content is good. Some of it is subtly wrong. A small amount of it is confidently, dangerously incorrect.
And all of it needs a home before it enters the source of truth.
That’s the gap we want to talk about today. The industry spent 2025 building out pipelines that serve Markdown to agents, standards like Markdown for Agents and the Accept: text/markdown content negotiation pattern. The conversation now needs to turn around. When agents send Markdown back, where does it go? Who reads it? Who signs off? How do you know what changed?
We think HackMD is the answer to those questions, and this post walks through why.
The shift: agents as documentation authors
Markdown used to be a format humans wrote for other humans. README files, wikis, internal docs, blog posts. A person typed the words, another person read them, and the structure in between was mostly for rendering.
That stopped being true sometime in 2025. Today, a significant share of Markdown in active codebases is generated or heavily edited by AI. A recent arXiv paper titled “Who Writes the Docs in SE 3.0?” found that when coding agents submit documentation pull requests, an average of 86.8% of line edits made by agents in source code are accepted by human developers. The researchers also note that documentation has become a primary entry point for AI agent contributions, yet integrating agent-authored documentation introduces reliability risks that are not automatically mitigated by existing review practices.
Read that last part again. Agents are writing our docs. Our review practices were not designed for this.
The trend goes beyond pull requests. Three patterns have become common across engineering orgs:
- AGENTS.md files describe to coding agents how a project is built, tested, and structured. AGENTS.md is now stewarded by the Agentic AI Foundation under the Linux Foundation as an open format. These files are frequently drafted or updated by agents themselves.
- Skill files (often written as
skill.md) encode a reusable prompt workflow with instructions, constraints, and context for an agent to follow. GitBook describes them as “structured technical documentation written specifically for AI agents.” - Living specs and RFCs get drafted by agents as a first pass, with humans iterating from there rather than starting from a blank page.
Each of these artifacts is Markdown. Each one directly steers how an agent behaves on future work. And each one needs a place where a human can read it carefully, question specific claims, edit with confidence, and leave a trail of what changed.
The problem with reviewing agent output in a pull request
The default answer today is: put it in Git, open a pull request, review the diff.
That works for some things. For a lot of agent-generated Markdown, it doesn’t.
A pull request is a fine mechanism for reviewing code, where the syntax is strict, the diff is semantic, and the cost of a missed issue shows up as a failing test. Prose is different. When an agent writes a paragraph explaining an API change, the diff viewer shows you red-and-green lines, but it doesn’t help you notice that the paragraph has subtly changed the meaning of a security assumption. It doesn’t help a domain expert who isn’t in Git every day leave a targeted comment on a specific claim. It doesn’t preserve the conversation when the file gets merged.
There’s also a participation problem. A lot of the people best positioned to review agent-generated content, product managers, technical writers, subject matter experts, compliance reviewers, don’t live in Git. Forcing them through a pull request workflow either slows the review down or silently excludes them. Neither outcome is good.
This is the same argument we made in our post on choosing a CMS for technical teams in 2026: collaborative Markdown is the missing layer before content reaches a publishing system. Agent output makes that layer even more important, because the volume is higher and the error modes are stranger.
What a governance layer actually looks like
When we say “governance layer,” we don’t mean heavy process or approval gates. We mean the four things a team actually needs when machines are producing content that matters:
1. Review in the browser, not a terminal
Agent output needs to land somewhere a human can actually read it. Not pipe it into less, not stare at a raw diff, but open it, scan it, edit it inline, and see the rendered version as they work. HackMD renders Markdown the way a reader will eventually see it, with tables, diagrams, embedded media, and code blocks all formatted. That makes it possible to catch the things that a plain-text diff hides, like a broken link, a malformed table, or a claim that sounded authoritative in raw Markdown but clearly needs a citation when you see the whole document.
2. Discussion that stays attached to the document
Once a reviewer spots something, they need a way to flag it without derailing the whole doc. HackMD’s paragraph citations and guided comments let someone ask “what’s the source for this?” or “this contradicts the v1 spec” directly against a specific sentence. The thread lives alongside the content, where anyone else reviewing later can see what’s already been raised. This matters specifically for agent output because agents hallucinate at the sentence level, not the document level. Your review tooling needs to work at that resolution too.
3. Versioning that shows what the agent changed
When an agent rewrites a doc, the most important question is often the simplest: what did it change? HackMD keeps a full revision history for every note. You can compare any two revisions, roll back a change you don’t like, or pin a specific version as a stable snapshot with version links. If an agent rewrote your onboarding guide and broke three sections in the process, you don’t have to reconstruct the old version from memory. You just revert.
4. Access control for a staging area
The last piece is permission. Agent drafts probably shouldn’t be world-readable the moment they land. HackMD’s team roles, folder permissions, and tag management let you create a staging area where agent output lives until a human has signed off. Once reviewed, the content can move to a published location or get exported to wherever it ultimately belongs, which is often a Git repo or a public docs site.
Together, these four capabilities are what we mean when we say governance. Not bureaucracy. Just the minimum a team needs to trust what they ship.
What the workflow looks like in practice
Here’s a concrete pattern we’ve seen teams adopt. It works for specs, RFCs, skill files, meeting notes, release notes, and most other structured prose an agent might produce.
Step 1. An agent generates a Markdown artifact, whether that’s a spec rewrite, a skill file update, a draft changelog, or a summary of a long design discussion.
Step 2. The artifact lands in a HackMD note, either via the HackMD API, the HackMD CLI, or a direct integration the agent is wired into. Because HackMD is Markdown-native, there is no format conversion or lossy import. What the agent wrote is what lands in the editor.
Step 3. Reviewers open the note in the browser. They read, comment, edit, and @-mention the right people. The document is already rendered, already shareable, already discoverable via tags and folders.
Step 4. Every edit is captured in version history automatically. If a reviewer catches an agent hallucination and fixes it, the fix is attributed and timestamped. If someone decides the whole draft is unsalvageable and reverts to a prior version, that’s recorded too.
Step 5. Once the doc is approved, it moves on. Maybe that’s a commit back to a Git repo as an updated AGENTS.md file. Maybe it’s an export to a published docs site. Maybe it just stays in HackMD as the living team knowledge base. The important part is that the review happened before the content crossed into a system where mistakes are expensive.
That flow is what governance looks like when it’s working. The agent did the fast part. The humans did the judgment part. Nothing got lost in between.
Why this matters more in 2026
The case for a governance layer has quietly gotten stronger over the last year.
Agents are getting more autonomous, which means they’re producing more content between human check-ins. Tools like CompanyOS have shown that an entire company can be operated out of a dozen Markdown skill files, with agents reading and updating them as they work. Visual Studio Magazine noted in February 2026 that Microsoft and GitHub are treating Markdown as “a stable, auditable control surface for AI behavior inside developer tools.” The direction is clear: Markdown is no longer just documentation. It’s the instruction set.
That makes the review step non-optional. A typo in a blog post is embarrassing. A wrong fact in an AGENTS.md file silently propagates to every future task the agent runs. A hallucinated guardrail in a skill file weakens every future output.
Most teams do not have a deliberate workflow for reviewing this content yet. Some are trying to retrofit pull requests. Some are skipping the review step entirely and hoping for the best. Neither approach scales.
Where HackMD fits
HackMD is already built for this. We didn’t design the editor around agents specifically, we designed it around the reality that good documentation comes from collaboration, iteration, and an honest record of what changed. Those are exactly the properties agent-generated content needs, too.
If your team is shipping AGENTS.md files, maintaining skill libraries, drafting specs with AI assistance, or just dealing with a growing pile of Markdown that someone (or something) needs to sign off on, we’d love to show you what the workflow can look like.
Read more: HackMD is built for agents — the companion post on how HackMD serves raw Markdown to agents via content negotiation, plus how the CLI and API fit into agent workflows.
