When an editor hits publish, from where they sit, just one thing happened. However underneath it’s seven or eight, and at least two can’t be taken back.
On a mature platform: purge the CDN, reindex search, fire a partner webhook, notify subscribers, push to social accounts, update a partner feed, emit an analytics event.
In Drupal a competent team can easily grep the hooks and event subscribers, read the ECA models etc, and have an inventory in a week as a wiki page. What an agent needs though is a declared catalogue: operations with typed inputs, known authorization, and a receipt on the way out.
As Scott Falconer puts it in the Outside AI roadmap: what’s missing is declaration, not governance. The permission system already works; authorization attaches to the operation, not the entry point. Operations beyond entity CRUD aren’t declared anywhere an agent can find them. For authorization that’s right but knowing an agent may run an operation doesn’t tell you which runs a human should look at.
Meta’s Agents Rule of Two, after Simon Willison‘s lethal trifecta says that an agent holding untrusted input, private data and the ability to change state within a session shouldn’t run autonomously. It needs human approval or another reliable means of validation. Because agents produce thousands of changes where a team produced a handful you need a second axis, not a substitute. The trifecta says which agents need supervision, something else has to say which of their calls do. Reversibility is the obvious candidate, however it’s not a clean yes or no. A reindex is re-runnable, yet while the rebuild happens the wrong results are served. The undo exists but the damage happened anyway. A usable class needs a mechanism, a window and the residue.
So placement is the real issue. Reversibility appears in the roadmap (stage four, where revisions make a change reversible), but that’s verification, after the fact. A gate needs it before, at dispatch. And it can’t be a static label, because deleting a node with revision retention on is a different class of action than the same call with it off. It depends on runtime config and the arguments of the call, which is why it isn’t a permission, and why declaring it is harder than declaring types.
Which also means the catalogue can’t enforce it. A field the agent reads is documentation, not a gate, and under injection the agent is the last actor you’d ask whether it should proceed. The check has to fire where entity access already fires — in the layer that runs the operation, evaluated against the arguments actually passed.
So a question for anyone working on this. If reversibility class belongs anywhere, does it belong in the Tool API declaration alongside typed inputs and authorization or somewhere else entirely?
Sources and further reading, for anyone who wants to dig in or get involved:
- Scott Falconer, “Outside AI — The State of Agent Experience in Drupal” https://www.drupal.org/about/ai/initiatives/blog/outside-ai-the-state-of-agent-experience-in-drupal
- Simon Willison on the lethal trifecta: https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
- Meta’s Agents Rule of Two: https://ai.meta.com/blog/practical-ai-agent-security/
- If you’re actually running agents against Drupal, the Outside AI workstream has asked for real workflows, see the meta issue or the #ai-initiative channel in Drupal Slack.
-M. García