Over the past few months, I’ve increasingly felt the need for an interface that combines the real-time human collaboration model of Google Docs with the ability for users’ AI agents to edit, suggest, and comment on the doc in parallel.

I want it for editing public content together, or drafting reports with humans and agents contributing, or for collaborating on agent-generated plan.md files with colleagues before actioning them, and so on.

In some sense, this is now the fourth time I’ve tried to build this, and I’m pretty sure I got it right this time (finally).Previous attempts included agent suggestions in Google Docs, collaborative folders in Obsidian, and artifacts in interface0. Each had good ideas but missed the mark in one way or another, and all contributed to this next solution.

The result is Copapers. Its model is simple: humans get a Google Docs-like web interface, and agents get an MCP server which is highly token-efficient and reliable.

The magic is in the implementation of the agentic MCP interface. There are other products out there that in theory allow this same general pattern, like Notion, or Proof from Every. But every one of those I have seen takes the approach of giving the agents custom, app-specific tools for editing the document — tools like edit_block or replace_range or notion-update-page.

These custom tools have two issues: they are extremely token-hungry, eating up usage limits and context windows; and they are often brittle and prone to failure.

This is a shame, because agent harnesses (e.g. Claude Code, Claude Cowork, Codex) are excellent at editing files locally. They have built-in read / write / update tools that the harnesses use perfectly and the models are trained for, with rare failures and minimal token consumption.

Copapers is architected in such a way that the agents can use these native tools. And as a result, it is highly token-efficient and reliable.

Here’s a demo. And you can read on if you want to understand how it works behind the scenes.

How it works

The server maintains the canonical document and handles all conflict resolution via Yjs CRDTs. Whenever an agent wants to edit a document, it “pulls” the document down to the user’s computer, downloading a Markdown representation of the doc (with minimally-extended CriticMarkup for suggestions and comments). The agent then edits completely locally using its native tools, and “pushes” the doc back up to the server.

On push, a couple things happen. First, the agent’s permissions are resolved. If the agent is only a “commenter” on the doc (or if it is an editor but chooses to suggest instead), its changes are diffed against the current state of the doc and added as suggestions. If it is an editor and chooses to exercise its edit capabilities, the edits are made directly. The agents are also able to make and respond to comments, and if they are editors, resolve them.

But all of that behind the scenes. All the user needs to do is add the MCP server to their local agent and ask it to grab and edit a document, and it’ll go smoothly from there. The agent’s edits show up separated from their human’s.

There’s also a feature where your agents can “link” an existing Markdown file on your computer (e.g. a plan document generated by a code agent) to a new Copapers file. When you do so, the Copapers file becomes canonical and the local Markdown gets some metadata telling agents to look on Copapers for the real, up-to-date doc. You can then edit collaboratively on Copapers or through agents, and sync updates back down to the local doc if you want.

I’ve been using Copapers and really enjoying it. It feels like these sort of human-agent shared workspaces are the future, and I suspect the best of them will use the agents native tools as much as possible. Would love to hear any feedback or thoughts.

Looking for more to read?

Want to hear about new essays? Subscribe to my roughly-monthly newsletter recapping my recent writing and things I'm enjoying:

And I'd love to hear from you directly: andy@andybromberg.com