Your teammate's agent can't edit the link you sent (2026)

Something changed in the last year or so, quietly enough that most tooling has not caught up with it. HTML stopped being only an output format and started being a document type — the thing a team actually works on.

You can see it in how the request is phrased now. Nobody says "export this to HTML" any more. They say "make me the weekly report", and what comes back is a single file with charts that respond to a hover, sections that collapse, numbers pulled into a table. Then somebody else on the team wants to change the framing of section three, and they ask their own AI to do it.

That second step is where the whole thing falls apart, and the reason is worth being precise about — because the obvious diagnosis is wrong.

The obvious diagnosis, and why it misses

The obvious reading is that sharing tools are not good enough yet: if only the link were editable, the problem would go away.

But look at what the second person's agent actually needs to do its job. It needs the file the page was built from. It needs somewhere to put the new version. It needs a way to declare that the new version is now the one that counts. And it needs that declaration to be visible to the first person, who is still holding a copy of the old one in their own context window.

A link does none of that, and it is not failing to. A published address answers one question — what does this document say right now — to anyone who asks, without asking who they are. That is a delivery mechanism. Making it also accept writes from anyone holding it would not be a better version of the same thing; it would be a different and considerably more dangerous thing.

So the fix is not a smarter link. It is noticing that you have two jobs and have been trying to do them with one object.

Two surfaces, two audiences

Split it like this:

The source is the file itself, in a place that handles being written to by more than one party. It needs history, because "what did this say last Tuesday" is a question that will be asked. It needs to survive two people editing on the same afternoon. And it needs to be reachable by an agent, since increasingly the thing doing the editing is not a person with a text editor.

The reading surface is a published address that shows the current result. Its audience is everyone who is not editing — which, on most documents, is nearly everyone. The client. The person who has to approve the budget. The colleague in another department who needs to read it once. None of them should have to clone anything, install anything, or understand what a build step is.

Once the two are separate, most of the confusion drains out of the situation. "Where do I make the change" has one answer. "Where do I send it" has a different one. Nobody has to hold both ideas in the same breath.

Where the source should live

For most teams, a Git repository. Not because Git is pleasant — it is not, particularly — but because it solves precisely the problems this situation generates. Two people editing at once, a history you can walk backwards, and a working model that every coding agent already understands without being taught.

If your team is not technical and a repository is genuinely out of reach, a shared drive can hold the source, provided edits are strictly sequential and everyone accepts that history is thin. That is a real trade, not a failure. What does not work is having no answer at all, because the default in that case is that the source is "whatever is in the last message of whoever spoke most recently", which is not a location.

A note on Drive specifically, since it comes up constantly: it is fine as storage for an HTML file and unreliable as the thing you point a reader at. Drive's preview often shows many HTML files as text rather than rendering them, which is why "it shows the code" is such a common complaint. Store it there if that suits you. Just do not make it the address you send.

Where the reading surface should live

Anywhere that will serve a self-contained file at a stable address. The properties that matter are narrower than you would guess:

• It opens in a browser with no sign-in. The moment a reader hits a login wall for a document they were sent, a meaningful fraction of them simply do not read it.
• The address does not change when the document does. This is the one people underestimate. If revising means minting a new URL, then every link you already sent quietly starts pointing at a stale version, and nothing warns anyone.
• Its visibility matches the content. A public, findable address is right for something meant to be found, and wrong for a draft with a client's numbers in it. That fork is a decision worth making deliberately rather than inheriting from whatever the tool defaulted to.

The part that is actually collaboration

Here is the thing that gets missed when this is framed as an editing problem: on most documents, most of the people involved do not want to edit. They want to react.

The reviewer who spots that a figure is out of date does not want to open a file and change it. They want to point at the figure and say so. The client reading a proposal does not want write access; they want to leave three remarks and get on with their day. Handing those people an editing surface is not generosity, it is a small burden — now they have to be careful.

And a comment carries something an edit destroys: the reason. "This number is stale, we restated it in March" tells the owner something. The same person silently changing the number tells them nothing, and the next person to look will not know whether it was a correction or a mistake.

So the collaboration loop that actually holds up looks like this:

1. One person's agent writes the document into the source.
2. It publishes to the reading address — the same one every time.
3. Reviewers read the page and leave comments anchored to the parts they mean.
4. Whoever owns the source takes those comments — often by handing them straight to their own agent — and makes the change in one place.
5. The published address updates. Everyone holding the link sees the new version without being sent anything.

Nobody in that loop needed write access to a link. The two people with agents both worked against the source. Everyone else got a reading surface and a way to talk about it.

What we do and don't do here

Since this is our blog, the honest boundary: miinideck is the reading surface. Drop an HTML file or a ZIP bundle and get a private link; connect it over MCP and your agent publishes to that same address on every revision, so the link you already sent keeps working. Turn on comment mode and reviewers — including people with no account — can leave feedback pinned to the part of the page they mean, and you can hand the whole thread back to an AI as markdown.

What we are not is the source of truth. We do not hold your working file, we do not merge two people's changes, and we should not be where your document's history lives. If you want that, use a repository, and use us for the address you send outward. A tool that claimed to be both would be lying to one of the two audiences.

The free tier is enough to see whether the shape fits: private links, password protection, and comment mode all included, with links self-destructing after seven days and one permanent link you choose. Paid tiers ($4.99/mo Solo, $14.99/mo Studio) make every link permanent, raise the file cap, drop the footer, and add a custom domain — Studio also unlocks exporting a review thread to markdown.

The one-line version

A link answers what does this say now. A source answers what should it say next. Teams get into trouble when they ask one object to do both — and the way out is not a cleverer link, it is admitting there were two jobs the whole time.

If you want to check a file renders properly before any of this, drop it into the viewer — that runs in your browser and uploads nothing, so looking at it commits you to no decision at all.