Where this comes from
Primary sources
- Tools specification · Model Context Protocol (accessed 09/20/2026)
Thread
Who approves what
The same question asked at every level: which part of this does a person still decide? The answer moves from reading each result to setting the limits a run happens inside.
The organizing sentenceA person never leaves; what they hold changes from the answer, to the action, to the rules the actions run under.
A proposal crosses a boundary before it becomes an action.
Keep these three decisions separate, whether the system is a workflow, one agent, or a team.
Propose
- 1Task + evidence
- 2Model drafts an action
- 3Exact proposed payload
A model can suggest what to do without having authority to do it.
BoundaryTool selection is not permission.
Authorize
- 1Payload + scope + version
- 2Policy and human review
- 3Bounded approval
Approve a specific action and destination under current conditions.
BoundaryChanged content or expired consent needs a fresh check.
Execute and verify
- 1Recheck current state
- 2Run with an idempotency key
- 3Inspect receipt and outcome
Record what actually happened, including uncertain or partial results.
BoundaryRetrying after an ambiguous failure can duplicate the action.
A focused business & team operations example. Additional perspectives appear where they provide a useful contrast.
GUIDED WORKED EXAMPLE Fictional fixtures · scripted outputs · no live model or external actions
Who approves what: see it in practice.
Tracing how human decision authority changes as more work becomes automated.
What you’ll walk through
Follow authority as a task moves from advice to bounded action. Compare a one-time decision with standing permission and inspect when a changed situation exceeds either.
The task in this version
Compare manual orders with bounded replenishment.
What you’ll learn to check
An authority ladder, versioned approval records, an out-of-policy order, and an escalation decision.
The setting makes the example concrete. Carry the underlying pattern into your own work; adapt the sources, tools, and level of oversight to your task.
Business & team operationsAn authored case with its own evidence, changed condition, and decision.
Compare manual orders with bounded replenishment.
Authored case. Select any record below; nothing is sent to a model.FOLLOW THE EXAMPLE1 / 6
Interpret this honestlySample evidence, not your actual data.No real messages, tools, training, or hardware operations run.The sequence illustrates the concept; it is not a recorded agent trace.
THE VISIBLE WORKStarting evidence
Input record
AUTHORED TEACHING RECORD · NOT A LIVE RUN
Manual: approve each order. Recurring policy: up to five units under $100 from approved vendors.
What changed: Establish the facts supplied for this version of the task.
WHY THIS MATTERS
What this case assumes
Authority belongs to a defined person or policy and has a scope. A model's recommendation does not create that authority.
1 / 6
Apply this to your project
Describe your task to your own model and use Who approves what as a reference. Ask whether it fits, which alternatives meet the same automation needs, and how you would implement and check the result.
Higher autonomy changes where people intervene; it does not require removing them. An agent can pause before consequential actions. An always-on service can prepare drafts while leaving execution to a person.
Separate who proposes an action, who authorizes it, and what code executes it.
Match review to consequences
| Situation | Useful review boundary | Enforce outside the model |
|---|---|---|
| Drafting an answer | Before relying on or publishing it | Source and output checks |
| Changing a record | Before the exact mutation | Identity, scope, version, allowed fields |
| Running a tool loop | At sensitive actions or blockers | Tool allowlist, budgets, approval policy |
| Working after you leave | At exceptions and reserved actions | Durable authority, expiry, pause, audit trail |
These boundaries can coexist. Bounded read-only work can continue while a proposed write waits for review.
Make approval concrete
Show the action, destination, consequences, and relevant evidence. Bind approval to the reviewed payload and scope. If a change falls outside that authorization, require another review.
Recheck current state before execution. Record the outcome and handle duplicates. If a network failure leaves the outcome uncertain, reconcile it before repeating the action.
A model may ask for help or flag uncertainty. Mandatory review gates should also be enforced independently by the application.
Avoid the extremes
Approving everything becomes a reflex. Match review to consequences and provide enough context for a meaningful decision.
Preapproval is not unlimited authority. Bound actions, data, destinations, and duration. Provide a way to pause work and revoke access.
Tool calling does not mean executing whatever the model returns. Parse, validate, and authorize requests. A tool schema or protocol is not a substitute for business rules.
Exercise the boundary
The scheduling approval example includes optional implementation checks for changed payloads, stale state, expired approval, and duplicates. Its local receipt is a teaching simulation, not an authenticated approval service or a calendar action.
Last reviewed 09/20/2026. Pages unreviewed for 90 days are flagged for another pass.