An execution boundary lets the application refuse an agent's proposed tool call

A write that landed and a write that failed look identical to the caller when no response comes back, so the agent's only move is to call publish_page again ^[1]. Between the two attempts the page may have been edited, the user's permissions may have changed, or the approval may have been revoked ^[2]. The second call is a new side effect evaluated against state that moved.

Two of the boundary's stages sound redundant until you separate those jobs. Idempotency collapses the duplicate write. Pre-execution validation asks whether the page is still in a publishable state, and both questions appear in the list of nine the post says a system may still need to answer before a page is actually published ^[8].

Collapsing the duplicate depends on the key. In the sample, operationId is required on both members of the action union, and it appears inside the proposal object the agent emits: op_8f219, next to resourceId page_284 ^[10][11]. The post leaves open which component fills that field ^[20]. executeIdempotently can only suppress the retry if the retry carries the same string, and a model re-reasoning from a changed context is free to produce a different one ^[19].

The control path in the sample runs validateSchema, then authorize, then enforcePolicy, branches to queueForApproval when approval is required, and otherwise calls executeIdempotently ^[13]. The published flow puts verification and an audit record after execution ^[9]. Both are missing from the function body ^[18]. The author wrote that the example "is illustrative rather than production-tested, but the design principle matters" ^[14].

Two conditions have to hold before this transfers to your stack. The action set has to be enumerable, because the post's claim for the union is that the agent "can select from known actions" and "cannot invent a privileged operation simply by describing one convincingly" ^[12]. The external system also has to offer either a dedup key or a read-back, since the verification stage after execution ^[9] needs some way to ask whether the first write landed.

The cheapest piece to adopt is the role split. The post separates capability from permission and gives three scopes: a research agent allowed to search and summarize, an editing agent allowed to create a draft, a publishing agent allowed to request publication, where "request publication" does not have to mean "publish immediately" ^[15]. Those are scopes on a credential, and the authorization call the post sketches already depends on the authenticated user, their role, ownership of page_284 and the page's workflow state ^[16].