field note / 2026-09-27 / 5 min read
Where the approval step belongs
Lessons from building agent tools, search, publishing, and retention workflows where a person needs to stay in control.
An approval button can look like a small UI detail. In the systems I worked on this year, it changed the architecture. Once a person must be able to inspect, refuse, or revise an action, the software needs to preserve what was requested, why it was requested, what evidence supports it, and what happened afterward.
That pattern showed up in projects that otherwise had little in common.
01 / note
Make the request understandable
Porto lets a remote AI agent request phone capabilities through MCP. The useful question for the person holding the phone is not merely whether an agent is connected. It is which capability this request needs, what it will return, and whether access should last for one invocation or a limited period. Phone-side scopes and approval are part of the tool interface itself.
A vague approval screen would have made the protocol work while leaving the person unable to make a real choice. That is a product failure as much as a security failure.
02 / note
Keep permission below the model
SACDEMS knowledge search has a different boundary. An administrator may ask a natural-language question that crosses public sources and private records. The model can help interpret the question, but it should not decide what the user is allowed to see. The server validates an allowlisted plan, and database functions enforce the signed-in user's scope.
This separation also makes failure more manageable. If the planner cannot produce a valid query, the application can fall back or return a bounded answer without weakening access rules.
03 / note
Keep evidence beside the draft
At Arvya, generated social posts and document artifacts had to remain tied to public-safe source material and explicit review. The point of a review step is not to make someone rubber-stamp fluent text. It is to give them the claim, its support, and a way to revise or reject it before publication or delivery.
Splay made that workflow a product surface: candidate posts, media, brand context, review decisions, scheduling, and publishing each have their own state. Churnary follows a similar idea for win-back messages. A risk signal can suggest a draft, but an owner should see the reason and approve the customer-facing action.
04 / note
Design for the day after approval
Approval is only one moment. A connection can disappear, a job can retry, a source can change, or a user can revoke access. Porto needed replay cursors and audit receipts; publishing workflows needed durable jobs and separate publish confirmation; search needed source links and scoped queries. These details let someone reconstruct what happened after the button was pressed.
I now think of the approval step as a contract between the system and its user. The system owes the person enough context to decide, a reliable record of the decision, and a safe path when something goes wrong.
The technical work does not end when an AI system produces an answer. For consequential actions, the product has to make human judgment possible and then honor it all the way through execution.