Moxn: Git-like version control for documents, built for AI agents

The problem

Four pain points keep showing up when working with agents on documents:

Parallel agents, no coordination. Two agents edit the same doc; the second clobbers the first and now you're at risk of deadlock. No diff, no history, no merge path, no option for human review. Last-write-wins.

Markdown in git works for agents, less so for humans. Agents and solo authors at a terminal are well served. Collaborators lose real-time cursors, the rich editor, and comments. Any other tool in your stack that wants this context has to go through your git provider to get it.

MCP bolted onto Notion or Google Docs. Agents call an API that wasn't designed for them. Writes burn tokens on format translation and cursor bookkeeping, and are often rate-limited. Search is flat. The Onyx team recently compared file search vs. hybrid retrieval and found that on complex multi-document questions at roughly 160k documents, agents using filesystem-style exploration beat agents using hybrid retrieval on document recall, 76% to 57%. Hybrid still wins on narrow single-doc lookups, speed, cost, and larger-scale robustness.

Permissions. There are times we want to protect certain chunks of content from agent updates or agent reads.

Filesystems are a shared primitive.

• They are the most common interface humans have used for organizing files on machines.
• Agents have already demonstrated success with navigating local codebases and disks.

The hierarchy gives agents the same advantage a well-organized folder system gives a human: you can navigate to the right neighborhood before you read the document. Add in tags and databases for cross-cutting dimensions and you can flexibly organize and find heterogeneous topics. The result is that the agent controls retrieval instead of delegating relevance entirely to an embedding. Hybrid search can layer on where it helps. The goal is the most token-efficient mechanism for agents to manage context, without sacrificing humans' ability to inject taste.

What we built

For humans: a collaborative editor. Headings, code blocks, mermaid diagrams, LaTeX, tables, images, PDFs, backlink references, inline comment threads. Real-time multiplayer. Optionally separate permissions for humans and agents, enforced at the section grain.

For agents: a filesystem. find, search, read operations over paths and content. Lightly wrapped markdown roundtrips. Organizational features for structure and discoverability. Accessible via MCP or CLI.

Version control: Git-like branching with common-ancestor merges. Content conflicts are resolved at the section grain and metadata like tags and properties at the document grain. The architecture is layered: immutable commit snapshots are the source of truth, and CRDTs (Yjs + TipTap) handle real-time multiplayer on the current working state within a branch. Edits flow into the CRDT, get flushed to mutable draft rows, and on commit those drafts are frozen into immutable versions. Merges operate on the committed snapshots.

For humans: the editor

The editor is where taste lives. An agent can produce ten drafts in a minute, but deciding which sentences to keep and finalizing the finishing touches is still a human job. It's a job that needs multimodal content support, multiplayer editing, comments, and the ability to react to structure visually. Humans and agents can both add comments. Leaving feedback and asking questions through comments is a collaboration method we now can't live without.

In Moxn each document is a collection of sections, which manage their own content, references, and optional permission overrides.

The Moxn editor — section-based, multiplayer.

Commits are branch-scoped and a commit history UI allows you to walk through the diffs to see what changed, not just in plain text but with content rendered. Merges default to carrying forward commit messages from the source branch so log and show tools can provide agents more context about the evolution of the doc in the future.

Commit history diff UI with rich content rendering.

For agents: a filesystem

Agents connect via MCP or a dedicated CLI. Both expose the same set of operations: glob-like find to discover files by path or name, search for full-text queries, read to get content, and sections to create and update content blocks. Agents have feature parity with humans in the browser across tags, databases, and filesystems. That unlocks knowledge bases that can be self-organizing when you want agent autonomy, or human-steered when taste and control matter.

Filesystem-like navigation that agents traverse via MCP or CLI.

filesystems provide a strict isolation mechanism. Within a filesystem, a user can have read, comment, edit, or none access per document. Even with none, they can see that the document exists. Users without access to the filesystem at all cannot see the filesystem, its documents, or its structure.

Version control: branching

Before AI reshaped how we work, I wanted branch-based version control in documents because:

1. With multiple editors in the same doc, when someone's in the middle of a rewrite, someone else nudges content above, and now cursors are negotiating over a live wire. Branches fix that for code. There's no good reason they shouldn't fix it for prose.
2. I'm naturally iterative, but I don't want the full audience of the doc to see my WIP edits as it evolves. Having the edits isolated on a branch allows me to build my way on my timeline without having to choose between privacy and overhead.

Agents make an even stronger third case.

3. Agents can fan out multiple drafts on parallel branches. I read the diffs in merge requests or hop onto the branch and cherry-pick by committing and editing. Then iterate with that loop. This post was written this way.

Merge requests from parallel agent branches used to write this post.

In Moxn each document has its own branches. Humans and agents can write directly to main for quick updates. When you want isolation or review you create a branch, edit and open a merge request. Merging uses a common ancestor to identify conflicts. Diffs are shown at the section grain, whether a section applies cleanly or requires conflict resolution.

Side-by-side merge conflict resolution with rich content rendering.

Branching solves the concurrency problem: multiple agents work in parallel without deadlocking, and a human (or another agent) reviews and merges when ready. For more advanced organizational structure, documents can carry hierarchical tags and live in spreadsheet-like databases with typed columns.

Where we are, honestly

We're using this daily. Here's what it's actually being used for, in addition to helping write this launch post, and where the gaps are.

Real use cases:

• CI/CD auto-docs with previews. Agents create branches named from PRs, update and create documentation as part of the same workflow that changes code. Reviewers see the doc update alongside the diff in a Vercel-style preview environment tied to the branch and coordinated by a changeset.
• Team knowledge base. Agents navigate documentation to pull in context. Push complex plans with mermaid or agent bug reports with browser-mcp screenshots to a doc for human review and collaboration. Context flows across the team without anyone having to forward it.
• Structured data beyond docs.
  • Trip planning: agents scrape property listings and populate typed columns for drive time, amenities, images, reviews, and personalized details. If you care about mattress firmness, drive time to different places, and whether there's a hot tub, having an agent do that research with a skill turns a messy comparison into a structured one.
    
  • A personal CRM: a database with contacts and prospects as pages, dated sections for history, tags for organization, with reads and writes accessible from any AI interface that supports MCP.

What's rough:

• Editor cold start & polish. No local-first sync yet. Noticeable lag opening a document. We're actively redesigning for document-open performance. Notion is truly an incredible experience for humans on the web and we're fans of Obsidian. Moxn's editor is improving daily and we know we have a journey in front of us.
• Search scope. Full-text search only covers the default branch — expanding to all branches and enabling search hits on history and metadata directly is on the roadmap.
• Enterprise features like audit logging are on the roadmap but not currently prioritized.

Try it

moxn.dev—There is a free plan, no credit card required. Individual and Team paid plans come with a 60-day free trial. Use code LAUNCH for 50% off your first year.

Import your existing content from Notion or markdown to get started. If you later want out, the CLI exports everything. If you hit any issues migrating in or out, reach out—we'll prioritize it.

We'd love feedback, especially if you've pointed AI agents at your team's docs and hit the same walls we did. Join our Slack and let us know what you think.