# Who approves what _Thread · sourced_ 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. ## Guided worked example · Business & team operations Fictional scripted fixture, not a measured run. No model or external actions execute. **Overview:** 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. **Assumptions:** Authority belongs to a defined person or policy and has a scope. A model's recommendation does not create that authority. **Design choices:** Use standing permission for predictable work inside explicit limits and fresh review for material exceptions. Make the commitment visible to the approver. **Request:** Compare manual orders with bounded replenishment. **Starting evidence:** Manual: approve each order. Recurring policy: up to five units under $100 from approved vendors. **Action and control:** Identify authority from specific approval or bounded policy, not vague prior trust. **Stage records (authored, not executed):** ### Input record 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. ### Design note Use standing permission for predictable work inside explicit limits and fresh review for material exceptions. Make the commitment visible to the approver. What changed: Choose an approach before treating a proposed result as accepted. ### Proposed work Identify authority from specific approval or bounded policy, not vague prior trust. What changed: Turn the request and evidence into the next action or transformation. ### Result record · illustrative Four units at $80 from an approved vendor fit the fictional policy; six units require review. What changed: Inspect the result of the authored example; this is not an executed model run. ### Verification plan An authority ladder, versioned approval records, an out-of-policy order, and an escalation decision. If the result falls short: If the request changes or ownership is unclear, pause the affected commitment and identify the decision needed. Unrelated authorized preparation can continue. What changed: Separate what needs checking from what the illustration establishes. ### Adaptation handoff Use this for orders, reporting, configuration, or project work. Choose review points according to consequences and organizational responsibility rather than a fixed number of approval steps. What changed: Decide which assumptions, tools, and controls should change for your own task. **Sample result:** Four units at $80 from an approved vendor fit the fictional policy; six units require review. **Change something — Change the vendor after approval:** Recheck authorization; an approval tied to the old vendor does not cover arbitrary substitutions. **Decision:** Can prior approval silently expand to another vendor? **Answer:** No; reevaluate scope. **Why:** Approval must attach to a specific action or policy; a past approval cannot silently expand scope. **Review criteria:** An authority ladder, versioned approval records, an out-of-policy order, and an escalation decision. **Recovery:** If the request changes or ownership is unclear, pause the affected commitment and identify the decision needed. Unrelated authorized preparation can continue. **Adapt it:** Use this for orders, reporting, configuration, or project work. Choose review points according to consequences and organizational responsibility rather than a fixed number of approval steps. > A person never leaves; what they hold changes from the answer, to the action, to the rules the actions run under. 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](/gradient_ascent/recipes/assistant-team/#try-with-your-ai) 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. ## Sources 1. [Tools specification](https://modelcontextprotocol.io/specification/2025-11-25/server/tools) — Model Context Protocol (accessed 2026-09-20) ## Pages that carry it - [Deciding what to hand over](/gradient_ascent/techniques/delegating/) (sourced): Deciding which parts of a task to hand to a model and which to keep. - [Human approval](/gradient_ascent/techniques/human-in-the-loop/) (sourced): Pausing for a person to approve or correct. - [Function calling](/gradient_ascent/techniques/function-calling/) (sourced): Letting the model call functions that you define. - [The agent harness](/gradient_ascent/techniques/agent-harness/) (sourced): Everything around the model in an agent: the loop, tools, context handling, permissions, caps and sandbox. - [Always-on assistants](/gradient_ascent/techniques/agent-teammates/) (sourced): Agents that resume work across sessions, schedules, and events. - [Calibrating trust](/gradient_ascent/techniques/trust/) (sourced): Learning, from results over time, how much to rely on a model without checking. Last reviewed 2026-09-20.