Earendil’s Pi Durable post (header date 01 Oct 2026) contains a sentence that every approval flow should be able to say: “After a restart, the hook finds the stored answer instead of asking again.” The human said yes once. The crash did not erase it.
Then you read the example code. The approval memo is typed as a boolean. The code stores no approver identity and no timestamp. The decision survives the restart. The decision-maker does not appear anywhere.
This essay is about that one object, the approval, and what it should carry once agents run continuously. Three products published at the end of September and the start of October 2026 treat approval differently, and what each page describes differs.
What Pi Durable stores
The mechanism is simple. Per the post, “a hook can run again after a crash, so a hook that makes a decision stores it in a memo: a small value stored with the task, where the first write wins.” A hook that throws is reported and the chain continues, “except in beforeTool, where a throw blocks the call.” So a human answer, stored in a memo, can gate a tool call and stay put after a crash.
Replay follows the same logic. “A tool call that was cut off reruns if it is safe to; otherwise the model is told it was interrupted.” A deploy tool declares no replay, so it is reported to the model and never repeated. This is careful engineering around a hard problem: what to do with a half-finished action.
Two limits matter for how we read it. The approval is a user-written example hook with a stub helper, not a built-in feature. And the page says plainly: “Pi Durable is experimental, and the API might still change.” We treat it as a design pattern worth examining, not as a recommendation to adopt it.
As a pattern, it is strong on one axis and silent on three. It persists the answer. It does not persist who gave it, when, or what exactly was approved.
Who can steer
The identity question is not abstract on this page. It says “Any client can steer a running conversation or queue a follow-up,” and “any number of clients can attach to any conversation in the harness.” Neither the page text nor the code describes authentication, authorization or identity for steering.
Put the two facts side by side. Many clients can attach to a conversation. The approval memo records a yes. Nothing described there ties that yes to one of those clients. An auditor reading the memo after an incident finds a true value and no name.
The page also says “Installing an extension under a name that is already installed replaces it in one step,” and that a tool with the same name in a later extension replaces the earlier one. It describes no signing or integrity check on installed code. That is a statement about the page, not about the product’s roadmap. The page describes hooks and extensions separately. If an approval hook ships as an extension, the same replacement rule would apply to it.
For the persistence-surface side of hooks, see our earlier piece on agent hooks as a persistence surface. We do not retell it here.
What the other two pages describe
OpenAI’s Introducing dots (page dated September 29, 2026) describes more approval machinery. “Dots start with built-in rules for when to act independently and when to ask for approval. Custom Rules let you allow specific actions, require approval, or block them. Built-in safety requirements always apply.” The contents of the built-in rules are not shown.
The page adds that “dots use auto-review to check actions that could affect your accounts or share information against your instructions, Custom Rules, and safety requirements,” and that “if our monitoring system detects a safety concern, it can pause or stop the dot’s work.” It also warns: “Dots can still make mistakes, so always review consequential work.” The page describes an Activity View. It does not say whether that view records the approver. We read no further than the page, so we make no claim about how auto-review decides, and none about what the Activity View holds.
One identity item does appear. Specialist dots have “their own identity for access management, IT-provisioned hardware,” and the page calls them “a preview of specialist dots,” starting with “focused enterprise pilots.” That is identity for the agent. The question this essay asks is identity for the human who approved.
Cloudflare’s managed OS page (Phillip Jones, metadata date 2026-10-01) lists three controls: “what custom domain you want to use, what Cloudflare Access policies apply, and which AI Gateway to connect,” plus per-service Gatekeepers. The same page says the OS can “send emails” and “push them to GitHub.” The page describes no approval step, no audit log and no tenancy isolation. Managed deployment is a waitlist. We read a page, so what we can say is what the page describes. For how connectors define the reach of an agent, see the connector as blast radius.
Why a boolean is a weak record
A crash-proof yes answers one question: did a human approve this? Three questions follow it in any review, and a boolean answers none of them.
Who approved? Without a name, an approval cannot be attributed, challenged or revoked. When did they approve? Without a time, a yes given before a policy changed looks identical to a yes given after. What did they approve? Without the arguments, a stored yes for “deploy” can be read as covering a deploy the human never saw.
The last one deserves a concrete reading. In the Pi Durable example, the memo is stored with the task, and the first write wins. The page text we read does not settle how the memo key relates to the specific call. If the key were not tied to the call, a bare true would come back for whatever call the hook is evaluating. That is our hypothetical, not a documented behavior. We are describing a possible risk in the pattern as shown, not a defect in a shipped product, because the code is an example and the helper is a stub. A team copying it would need to check how the key is scoped.
For the provider-side version, see the provider-owned session audit gap.
Our proposal: an approval record with three fields
This part is ours. None of the three pages describes an approval record with these three fields.
An approval should be written as a record, not a flag. At minimum:
- Approver: the authenticated identity of the person or service that gave the answer, not the client that happened to be attached.
- Time: when the answer was given, in a form that can be compared with policy changes.
- Arguments: the exact tool name and arguments the answer applies to, so that a replayed hook can compare what it is about to run with what was approved.
With these three, a restart can replay the decision and refuse to reuse it for a different call. An auditor can read the same record without reconstructing intent from logs. In our design, adding fields to a memo is a small change. The hard part is the first one: an approver field is only meaningful if steering is authenticated, and the Pi Durable page describes no identity for steering. The record would need that to exist underneath it.
The same shape applies to vendor-side approvals. If Custom Rules can require approval, a buyer should ask where the answer is stored and which fields it carries. If a managed OS can send email and push to GitHub, a buyer should ask where the approval for a given send is recorded, since the page describes none.
Do this now
Pick one agent workflow in your own stack that already has a human approval. Find where the answer is stored. Write down what that storage holds: the value only, or also who, when and for which arguments. If it is the value only, add the three fields before the next time anyone says the workflow is audited. Then ask each vendor you use the same three questions, and file the answers next to the contract.
This analysis synthesizes Pi Durable (Earendil, October 2026), Introducing dots (OpenAI, September 2026), and Cloudflare OS: your company’s agent workspace, managed for you (Cloudflare Blog, October 2026).
Victorino Group helps engineering teams design approval records that name the approver, the time and the arguments before agents run unattended. Let’s talk.
All articles on The Thinking Wire are written with the assistance of Anthropic's Opus LLM. Each piece goes through multi-agent research to verify facts and surface contradictions, followed by human review and approval before publication. If you find any inaccurate information or wish to contact our editorial team, please reach out at editorial@victorinollc.com . About The Thinking Wire →
If this resonates, let's talk
We help companies implement AI without losing control.
Schedule a Conversation