Governance That Falls Out of the Architecture

A music app has a transpose button. Click it and the app calls transpose(2). Ask the agent to move the song up a whole step and the agent calls transpose(2). Same function, same validation, same log line. Sunil Pai states the constraint plainly in one document, two hands: “there isn’t a normal implementation and an AI implementation.”

That sentence is a governance decision wearing the clothes of a refactoring note.

Once the agent’s only route to the document is the named operation the interface already calls, a set of properties that teams normally buy separately arrive as a side effect. Arguments get validated, because one place validates them. Permissions get enforced, because one place checks them. Changes get recorded and reversed, because one place writes the log. Pai lists exactly those consequences: “arguments can be validated, permissions enforced, changes recorded and undone.”

We argued in permissions must live where the data lives that a bolt-on policy layer is a copy of the truth, and copies drift. That essay named the destination without naming the vehicle. Here is the vehicle. Permissions live in the operation, and the operation is shared with the human interface.

Why a Shared Operation Cannot Quietly Drift

A policy wrapper around an agent has one structural weakness: nothing else depends on it. When a developer adds a capability and forgets to gate it, the ungated path works fine, ships fine, and stays broken until an incident or an audit surfaces it.

A shared operations object removes that hiding place. If a new capability skips the validation, the button skips it too, and the button has users. If the permission check on deleteTrack is wrong, a human hits the wrong behavior on a Tuesday afternoon and files a bug. The agent’s authorization surface is kept honest by ordinary product pressure on the human surface, which is a much more reliable maintainer than a quarterly review of a policy file.

This is the part worth stealing even if you never build an agent. The division of labor Pai describes (“the model decides which control to reach for; ordinary software applies the change”) means the risky, non-deterministic component never holds the write path. It selects from a menu. The menu is code you already test, already review, already own.

Audit and Undo Are Not Retrofittable

Consider the architecture on the other side. The agent talks. The user talks back. Somewhere in that exchange the document changes, through generated code, through a blob of JSON, through a re-render of the whole file. State is now smeared across a conversation.

Ask that system for an audit trail and you get a transcript. A transcript records what was said. An audit trail has to answer a harder set of questions: what changed, under whose authority, at which moment, and can it be reversed cleanly. Those questions have no answer in prose. You can bolt logging onto a chat-driven agent, and many teams have. What you get is a longer transcript.

Undo is worse. In the shared-operations design, undo is the inverse of a recorded operation, the same machinery the interface’s own undo stack uses. In the transcript design, undo means rewinding a conversation and hoping the resulting state matches, which is a guess dressed as a feature.

Pai’s line about the music app carries the whole argument: “the chat should not own the song. the song should own the song.” The document holds the state. The document holds the history. The conversation is one of two hands reaching for the same controls.

The Harness Is the App

The second idea in the piece is where it stops being a code-organization argument. Pai points out that coding agents already ship a complete operating environment: workspace, tools, memory, sandbox, permissions and an execution loop. Then he asks the obvious question about everyone else. “maybe we built agents a proper workshop where developers work, then handed everyone else a text box.”

Read that list of six again with a governance eye. Sandbox is blast radius. Permissions is authorization. Memory is retention policy. The execution loop is the thing you pause, inspect and resume. Workspace is scope. A coding harness is already a control plane, built by accident, because developers would not tolerate an agent without one.

The move Pai proposes is to wrap that same harness around the user’s document instead of around a codebase. His reference implementation, Pizzo, holds state in a Durable Object and started life as a Local-First Conf talk. The interesting claim is not the demo. It is that the governance apparatus for non-developer agents already exists, fully specified, in the tools engineers use daily, and nobody has ported it.

That connects directly to the orchestration layer argument and to what we called the intent layer. The controls do not have to be visible to the user to be real. They have to be the only path.

Which Products This Applies To

Pai names the shape of work this generalizes to: spreadsheets, canvases and drawings, itineraries, maps, video timelines, CAD. What those have in common is a document with structure and an interface built from named operations. Insert row. Move layer. Reorder stop. Trim clip. Every one of those products already has an operations vocabulary. Most of them have it scattered across event handlers rather than collected into an object an agent could call.

That scattering is the real work, and it is unglamorous. Extracting the operations is a refactor with no user-visible outcome, proposed in a quarter where someone wants a chat box shipped. The refactor is what makes the chat box safe to ship.

One caution on scope. Pai’s essay includes rough numbers about how many software developers exist versus how many people work with documents, and he explicitly disclaims them as illustration rather than forecast. Treat them the same way. The architectural claim stands without them.

Do This Now

Pick the one product surface where someone has already asked you for an agent. Open the code and answer a single question before you write a prompt: is there an operations object the interface calls, or does each button handler mutate state inline?

If the operations exist, your agent work is mostly wiring, and your governance work is mostly done. Enumerate the operations, confirm each one validates its arguments and checks permissions, and give the agent access to that list and nothing else.

If the operations do not exist, you have found the actual project. Extract them from the handlers before anything model-shaped touches the document. Then apply one rule with no exceptions: when the agent needs something no operation provides, add the operation to the shared object so both hands get it. The moment you write a code path only the agent can reach, you have rebuilt the policy wrapper, and you have inherited the drift that comes with it.

---

This analysis draws on one document, two hands (Sunil Pai, July 2026).

Victorino Group helps product teams extract the shared operations layer that makes agent authorization, audit and rollback structural. Let’s talk.