• 

  Adding a Block using agent

• 

  after all edits and comments resolved

• 

  adding comments

About the Project

The idea

We wanted to explore a simple question:

What if an AI agent could work inside a document with you, instead of just looking at the document from the outside?

Today, when an AI agent interacts with a web application, it often has to rely on screenshots, DOM inspection, or simulated clicks. For a document editor, that means the agent has to figure out what the user is looking at, where content belongs, and what actions are available.

We wanted to try a different approach using WebMCP: let the website expose its actual application state and capabilities as structured tools that an AI agent can call directly.

That became Co/Draft — a document where humans and agents edit together.

The core interaction is deliberately simple. A human writes and selects content normally, while an agent can use tools such as get_document_state, get_selection, add_comment, and insert_block. The agent therefore works with the same structured document state that the human sees, rather than trying to reconstruct it from the UI.

How we built it

Co/Draft is a lightweight React + TypeScript application using Zustand for document state.

The document is represented as structured blocks rather than one large piece of HTML. Each block has an ID, text, creation source, and author information. Comments are also attached to specific block IDs, which gives the agent an unambiguous way to refer to a section of the document.

On top of this state, we registered five WebMCP tools:

• get_document_state — lets the agent read the current document, pending suggestions, and comments.
• get_selection — tells the agent which block the human is currently working on.
• insert_block — lets the agent propose a new section.
• add_comment — lets the agent leave feedback on a specific block.
• resolve_comment — lets the agent mark feedback as resolved.

These tools are registered through document.modelContext, using a React hook so that the tools operate against the same live state as the UI.

We also added a small human-in-the-loop trust boundary. An agent doesn't directly insert arbitrary content into the document. Instead, insert_block creates a visible pending suggestion. The human can then accept or reject it.

That gives us a workflow like:

Human writes → Agent reads → Agent reviews → Agent proposes → Human approves → Document changes

The agent can participate meaningfully without silently taking control of the document.

For collaboration, the prototype uses the browser's BroadcastChannel API. This allows multiple tabs in the same browser to exchange document mutations and presence information without requiring a backend. The project is intentionally a prototype rather than a production collaborative editor.

What we learned

The biggest thing we learned was that giving an agent structured tools changes the interaction completely.

Instead of asking an agent to “look at the page and figure out what to do,” we can give it explicit capabilities:

get_document_state()
get_selection()
add_comment(blockId, text)
insert_block(text, afterBlockId)
resolve_comment(commentId)

This makes the boundary between the application and the agent much clearer.

We also learned that the interesting part isn't simply allowing an agent to edit. The more important question is how much control the agent should have.

For example, comments are relatively low-risk, so an agent can add one directly. Inserting actual document content is more consequential, so we introduced an approval step.

That led us to think about agents less like automated scripts and more like collaborators with explicitly defined permissions.

We also learned about the practical distinction between exposing application functionality to an agent and actually building a collaborative application. WebMCP solves the first problem very nicely, but synchronization, persistence, identity, and conflict resolution are separate engineering problems.

The challenges

One of our biggest challenges was synchronization.

Our first implementation used BroadcastChannel to send mutations such as:

editBlock
addComment
resolveComment
proposeBlock
acceptSuggestion
deleteBlock

between tabs.

However, simply broadcasting mutations isn't enough to create a reliable shared document. Each tab initially creates its own in-memory state, so two tabs can start with different randomly generated block IDs. A mutation referring to a block that only exists in the sender's state cannot be correctly applied by another tab.

This forced us to think about an important distinction:

sharing events is not the same thing as sharing state.

A reliable prototype needs both a consistent initial document and a way for a newly opened tab to obtain the current state before applying future mutations.

We therefore treated the synchronization layer as a separate problem from WebMCP itself. The eventual direction is a lightweight state handshake for new tabs, while keeping the mutation-based synchronization simple enough for a hackathon demo.

Another challenge was deciding what not to build.

It would be possible to turn Co/Draft into a much larger system with a backend, WebSockets, persistent documents, authentication, CRDTs, conflict-free editing, and cross-device collaboration. But that would move attention away from the actual experiment we wanted to demonstrate:

Can a web application expose meaningful, structured capabilities to an AI agent so that the agent can genuinely collaborate with a human?

For this project, we chose to keep that question at the center.

Why this matters

Co/Draft is intentionally small, but the idea can extend much further.

A document editor is just one example. The same pattern could apply to design tools, spreadsheets, project-management applications, whiteboards, educational software, or any interactive application where an AI agent needs to understand and manipulate structured state.

Instead of building agents that merely see interfaces, we can build applications that explicitly tell agents:

“Here is what I am. Here is what you can understand. Here is what you are allowed to do.”

That is the direction we wanted to explore with Co/Draft.

Built With

• agents
• api
• apis
• broadcastchannel
• collaboration
• collaborative
• context
• design
• document.modelcontext
• editing
• generative
• human-in-the-loop
• javascript
• jspdf
• model
• protocol
• react
• real-time
• responsive
• typescript
• usewebmcp
• vite
• web
• webmcp
• zustand