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.