Bilal

Worth adding a category the reversibility test handles neatly but people forget to put in it: actions visible to third parties.

Sending a message, opening a support ticket with a vendor, posting a comment, filing something. Technically reversible — you can delete it — and the other person has already seen it. Treat those as irreversible, because in the way that matters they are.

That single addition catches most of the embarrassing failures I have heard about.

There is a real difference and it comes down to what the automation is given to look at.

A script knows the page. Somebody wrote a selector, and if the selector still matches, the script works. The page representation the tool provides — a DOM tree, full markup — is enormous and that is fine, because code does not have a context limit.

An agent does not know the page and has to be told what is on it, in a form small enough to fit in context and stable enough to act on. That is the actual engineering problem, and existing automation tools were never built for it:

• Serialising a page into something a model can read without shipping half a megabyte of markup.
• Giving elements stable handles the model can refer to, since it cannot write a CSS selector for something it has not seen.
• Deciding when the page has settled, which a script solves by waiting for a specific element and an agent cannot.

So the wave is not imaginary. Everyone is rebuilding the same missing layer.

One practical note before you commit: check what your users' assistants actually support today, because the ecosystem is moving quickly and support for the less-used parts of the spec is uneven.

Tools are supported broadly. Resources, prompts and the more elaborate transports much less so. Building around a part of the protocol that most clients ignore is a real way to spend a week for nothing.

The cheap experiment: expose two tools, ship it, and see whether anybody connects to it before building the other eighteen.