“Do you want to continue?” is not an approval flow.
It is a question without a target, identity, side effect, or expiry. AI SDK 6 was interesting to me because it put tool approval closer to ordinary application state. Once an agent can edit a file, create a ticket, send a message, or call an MCP server, that is the right place to put it.
I want a tool request to have an explicit lifecycle:
type ToolApprovalState =
| { status: "proposed"; toolName: string; input: unknown }
| { status: "needs-user"; explanation: string; risk: "low" | "medium" | "high" }
| { status: "approved"; approvedBy: string; approvedAt: string }
| { status: "denied"; deniedBy: string; reason?: string }
| { status: "expired"; expiredAt: string }
| { status: "executed"; resultId: string }
| { status: "failed"; error: string; retryable: boolean }
The names are less important than the shared vocabulary. If the client says pending, the server says approved, and the trace says blocked, nobody is debugging the same event.
MCP makes the boundary more visible because the tool may come from a server with its own trust model. The user is not approving a tool in the abstract. They are approving an action against a resource under an identity.
For a write, I want the approval to show something like:
action: create one issue
server: github-workspace
identity: jeremy
repository: jeremy-london/jeremylondon.com
writes: github.issue
rollback: close or edit the issue
The trace should retain the proposal, normalized arguments, policy decision, approval, execution result, and final answer on one timeline. That is how a reviewer finds the wrong step when the final chat message still sounds plausible.
The same applies to copy. “Continue” is vague. “Create one GitHub issue in this repository using your account” is a decision a person can make.
Tool approval became mainstream when it stopped looking like a modal and started looking like state: proposed, reviewed, approved, executed, expired, or rejected. That is the difference between asking for permission and building a system that knows what permission means.
Related posts

About Jeremy London
Engineering leader and builder in Denver. I write about AI platforms, agents, security, reliability, homelab infrastructure, and the parts of engineering work that have to survive production.