One state machine or two: the transaction fork hiding inside your MCP server

The tell that you have forked the model is not a design document. It is the failure the essay names last: when something goes wrong, neither interface can explain the same outcome ^[4]. That is a reconciliation job, and reconciliation gets done late, under time pressure, with money already committed.

The proposed test is behavioral rather than visual: both interfaces should agree on the entity being acted on, its current state, the allowed transition, and the evidence produced by that transition ^[5]. The fourth item carries the weight. Evidence is what lets an agent resume from a confirmed result instead of guessing whether its write landed ^[13]. Without an artifact that says so, a retry has to infer success by re-reading state, and inference is not a transition.

The post's ladder is read, prepare, commit, settle ^[8], and the deployment pattern it recommends is to start with a narrow read surface, check the outputs against the human-visible record, then add preparation, then commitment once identity, permission and recovery are defined ^[12]. Worth noticing where the shipped example sits on that ladder. According to the author, WebAZ's reviewed shopping-v1 surface exposes one search tool over reviewed active listings and cannot create orders or move funds ^[11]. So the evidence on offer covers the lower half of the ladder; commit and settle are described as design rules, not as something running ^[16].

That matters because the vocabulary is where the discipline holds or slips. The illustrative agent declaration lists two allowed actions, search and place_order ^[15], with nothing between them, even though the same piece requires preparation and commitment to be separate transitions ^[17]. Scopes named after user stories will collapse that gap by default, and a capability matrix built from user stories reproduces the fork it was meant to prevent. The rule the post actually leans on is narrower: a search capability does not imply permission to place an order, and permission to prepare does not imply permission to approve something irreversible ^[14].

The other structural choice is where human presence is enforced. In the described protocol, risk actions return an approval URL, the person completes a Passkey ceremony on a browser surface, and the agent continues from the reported result without impersonating anyone ^[9]. The claim that no declared scope overrides live human presence is framed as a property of the protocol rather than a preference of each agent client ^[10]. Put that check in the client and every client becomes a place it can be forgotten; put it in the protocol and the agent has nothing to negotiate with.

None of this requires the two interfaces to look alike. The division of labour in the essay is asymmetric on purpose: the human surface inspects terms, manages identity, reviews a proposed action and handles exceptions, while the agent surface reads structured facts, searches, prepares requests and continues from explicit outcomes ^[6]. One state machine underneath, two operators with different jobs. The useful question to ask of any agent tool list is which of the four levels each tool sits on, and whether anybody wrote that down before the first write shipped.