# Deciding what to hand over _Topics at every level · sourced_ Deciding which parts of a task to hand to a model and which to keep. ## Guided worked example · Everyday life Fictional scripted fixture, not a measured run. No model or external actions execute. **Overview:** Follow a task being divided between an assistant and a person. Inspect what can proceed independently and what should return as a proposal or question. **Assumptions:** Capability and authority are separate. The assistant may be able to perform an action that the user only asked it to prepare. **Design choices:** Delegate coherent outcomes with clear boundaries and a way to recognize completion. Preauthorize routine reversible work where appropriate rather than requesting permission for every step. **Request:** Help organize the workshop, but let me control commitments. **Starting evidence:** Tasks: draft invitation, compare venues, reserve room, pay deposit. Only first two authorized. **Action and control:** Separate reversible preparation from external or financial commitments. **Stage records (authored, not executed):** ### Input record Tasks: draft invitation, compare venues, reserve room, pay deposit. Only first two authorized. What changed: Establish the facts supplied for this version of the task. ### Design note Delegate coherent outcomes with clear boundaries and a way to recognize completion. Preauthorize routine reversible work where appropriate rather than requesting permission for every step. What changed: Choose an approach before treating a proposed result as accepted. ### Proposed work Separate reversible preparation from external or financial commitments. What changed: Turn the request and evidence into the next action or transformation. ### Result record · illustrative Venue comparison and invitation draft prepared. Booking and payment remain pending. What changed: Inspect the result of the authored example; this is not an executed model run. ### Verification plan Delegation matrix, permitted drafts, withheld transaction, and a change-of-scope approval case. If the result falls short: When the task exceeds the agreed scope or needs missing judgment, return the specific decision with options. Avoid both silent expansion and unnecessary interruptions. What changed: Separate what needs checking from what the illustration establishes. ### Adaptation handoff Apply this to research, administration, or engineering work. Choose boundaries based on reversibility, shared resources, and what the user wants to retain. What changed: Decide which assumptions, tools, and controls should change for your own task. **Sample result:** Venue comparison and invitation draft prepared. Booking and payment remain pending. **Change something — Approve invitation wording only:** Approval covers text, not distribution, venue booking, or payment. **Decision:** Does wording approval authorize payment? **Answer:** No; actions and scopes are separate. **Why:** Distinguish ability from authority; reversible drafts and consequential commitments need different boundaries. **Review criteria:** Delegation matrix, permitted drafts, withheld transaction, and a change-of-scope approval case. **Recovery:** When the task exceeds the agreed scope or needs missing judgment, return the specific decision with options. Avoid both silent expansion and unnecessary interruptions. **Adapt it:** Apply this to research, administration, or engineering work. Choose boundaries based on reversibility, shared resources, and what the user wants to retain. ## Guided worked example · Engineering & technical work Fictional scripted fixture, not a measured run. No model or external actions execute. **Overview:** Follow a task being divided between an assistant and a person. Inspect what can proceed independently and what should return as a proposal or question. **Assumptions:** Capability and authority are separate. The assistant may be able to perform an action that the user only asked it to prepare. **Design choices:** Delegate coherent outcomes with clear boundaries and a way to recognize completion. Preauthorize routine reversible work where appropriate rather than requesting permission for every step. **Request:** Help prepare a test project while I retain control of instruments. **Starting evidence:** Authorized: read docs, draft project code, propose non-hardware checks. Not authorized: shared framework changes or instrument operation. **Action and control:** Allocate useful preparation tasks without granting execution authority over equipment. **Stage records (authored, not executed):** ### Input record Authorized: read docs, draft project code, propose non-hardware checks. Not authorized: shared framework changes or instrument operation. What changed: Establish the facts supplied for this version of the task. ### Design note Delegate coherent outcomes with clear boundaries and a way to recognize completion. Preauthorize routine reversible work where appropriate rather than requesting permission for every step. What changed: Choose an approach before treating a proposed result as accepted. ### Proposed work Allocate useful preparation tasks without granting execution authority over equipment. What changed: Turn the request and evidence into the next action or transformation. ### Result record · illustrative Draft code and review notes produced. Unknown settings and hardware validation remain with the engineer. What changed: Inspect the result of the authored example; this is not an executed model run. ### Verification plan Review allowed resources, write locations, prohibited actions, and escalation behavior. If the result falls short: When the task exceeds the agreed scope or needs missing judgment, return the specific decision with options. Avoid both silent expansion and unnecessary interruptions. What changed: Separate what needs checking from what the illustration establishes. ### Adaptation handoff Apply this to research, administration, or engineering work. Choose boundaries based on reversibility, shared resources, and what the user wants to retain. What changed: Decide which assumptions, tools, and controls should change for your own task. **Sample result:** Draft code and review notes produced. Unknown settings and hardware validation remain with the engineer. **Change something — Agent requests a live measurement to improve its draft:** Escalate the request; usefulness does not create instrument permission. **Decision:** Does a useful next step automatically fall within delegation? **Answer:** No; compare it with the authorized scope. **Why:** Delegation separates capability, task scope, and consequential authority. **Review criteria:** Review allowed resources, write locations, prohibited actions, and escalation behavior. **Recovery:** When the task exceeds the agreed scope or needs missing judgment, return the specific decision with options. Avoid both silent expansion and unnecessary interruptions. **Adapt it:** Apply this to research, administration, or engineering work. Choose boundaries based on reversibility, shared resources, and what the user wants to retain. ## Guided worked example · Business & team operations Fictional scripted fixture, not a measured run. No model or external actions execute. **Overview:** Follow a task being divided between an assistant and a person. Inspect what can proceed independently and what should return as a proposal or question. **Assumptions:** Capability and authority are separate. The assistant may be able to perform an action that the user only asked it to prepare. **Design choices:** Delegate coherent outcomes with clear boundaries and a way to recognize completion. Preauthorize routine reversible work where appropriate rather than requesting permission for every step. **Request:** Prepare a weekly update and proposed follow-ups, but do not assign work to people. **Starting evidence:** Assistant may summarize trackers and draft action suggestions. Project leads decide ownership and commitments. **Action and control:** Separate suggested follow-ups from changes to the official tracker or notifications. **Stage records (authored, not executed):** ### Input record Assistant may summarize trackers and draft action suggestions. Project leads decide ownership and commitments. What changed: Establish the facts supplied for this version of the task. ### Design note Delegate coherent outcomes with clear boundaries and a way to recognize completion. Preauthorize routine reversible work where appropriate rather than requesting permission for every step. What changed: Choose an approach before treating a proposed result as accepted. ### Proposed work Separate suggested follow-ups from changes to the official tracker or notifications. What changed: Turn the request and evidence into the next action or transformation. ### Result record · illustrative Draft proposes owner confirmation for two risks. No assignments or messages occur. What changed: Inspect the result of the authored example; this is not an executed model run. ### Verification plan Inspect source reads, proposed actions, tracker state, and the decision owner. If the result falls short: When the task exceeds the agreed scope or needs missing judgment, return the specific decision with options. Avoid both silent expansion and unnecessary interruptions. What changed: Separate what needs checking from what the illustration establishes. ### Adaptation handoff Apply this to research, administration, or engineering work. Choose boundaries based on reversibility, shared resources, and what the user wants to retain. What changed: Decide which assumptions, tools, and controls should change for your own task. **Sample result:** Draft proposes owner confirmation for two risks. No assignments or messages occur. **Change something — Agent writes the suggested owner into the live tracker:** That changes obligations outside the drafting scope; require explicit authority before the write. **Decision:** Does drafting a recommendation authorize assigning it? **Answer:** No; recommendation and commitment are different actions. **Why:** A useful assistant can prepare decisions without making them on others' behalf. **Review criteria:** Inspect source reads, proposed actions, tracker state, and the decision owner. **Recovery:** When the task exceeds the agreed scope or needs missing judgment, return the specific decision with options. Avoid both silent expansion and unnecessary interruptions. **Adapt it:** Apply this to research, administration, or engineering work. Choose boundaries based on reversibility, shared resources, and what the user wants to retain. Delegating is deciding which parts of a task to hand to a model and which to keep. It comes before [briefing](/gradient_ascent/techniques/briefing/), which assumes the handoff has already been settled, and it is a decision about the task rather than about the model: a system fully capable of drafting a refund email can still be the wrong thing to let send one unattended, if a wrong send is expensive and hard to undo. Four questions do most of the work. What would a wrong answer cost? How easily could you check the result? How reversible is the action once taken? Does the task need context only you have? None of the four asks how good the model is. Anthropic's prompting guide draws the same line. For teams who want a model to confirm before risky actions it publishes a sample prompt: text you add to your own, not a description of default behavior: "Consider the reversibility and potential impact of your actions. You are encouraged to take local, reversible actions like editing files or running tests, but for actions that are hard to reverse, affect shared systems, or could be destructive, ask the user before proceeding."[1] This page is sourced, not measured: the advice below is checked against primary sources, but no result file exists for any of it, so no number here is one this site took. ## Practical guidance Score the task, not the model. Each row is a question about the work in front of you, answered before you hand anything over. | Question | Hand it over | Keep it, or check before it acts | |---|---|---| | What does a wrong answer cost? | A rough draft, a first pass, something you were going to redo anyway | Money moves, a claim goes out, a diagnosis or an order is recorded | | How checkable is the result? | You can verify it in less time than doing it took: a date, a total, a citation | A judgment call, or a summary of more material than you will reread | | How reversible is the action? | A draft, a file, a search, a suggestion | A payment, a deletion, a message already sent, a filing already made | | Whose context does it need? | Everything relevant is in the material you can give it | It turns on a relationship, an unwritten exception, or something said in a room | Read the row that scores worst, not the average. A task on the right of even one row wants a person between the model and the action, not more trust but a checkpoint; a task on the left of all four is reasonable to hand over unattended. You'll know the score was right when a handed-over task keeps coming back cheap to check and cheap to redo. If one starts costing more to verify than it saved, that's not the model getting worse; it's the row you scored wrong, and the fix is re-scoring, not adding a step to catch the surprise afterward. Three things this site recommends never running unattended, regardless of score: anything that moves money or creates a legal obligation on your behalf, anything that communicates in your name outside your own team, and anything that deletes or overwrites the only copy of something. Each fails the same two rows: irreversible, and unverifiable after the fact. For everything else, widen deliberately: hand over the cheapest, most reversible slice first, watch what actually goes wrong for a few weeks, and widen only past what held up. Skip the framework for a single request you'd happily redo yourself; it earns its cost once a kind of task is going to repeat. ## Implementation details A builder makes the decision durable by encoding it as a permission rather than a habit: a tool the model may call freely, a tool that needs a person's approval first, and a tool the system never offers at all because nothing in the task needs it. The third category is the one usually skipped. OWASP's guidance for prompt injection puts both halves plainly: "Implement human-in-the-loop controls for privileged operations to prevent unauthorized actions," and "Restrict the model's access privileges to the minimum necessary for its intended operations."[2] An action the system was never given is one no instruction can talk it into. The check belongs in code, running whether or not the model would have drawn the boundary correctly by itself. The [safety](/gradient_ascent/techniques/safety/) page's example is one version: a permission check that refuses a refund call unless the customer's own message independently names the same amount, no matter what a retrieved note tried to talk the model into. The model may propose; only a call the person's own words support runs. Deciding what to hand over also decides who else gets to hold it. Anything sitting between you and the model (a workflow automation service, a browser extension, an agent framework's hosted tracing) receives the same material the model does and holds it under its own terms, not the model maker's. So the thing to check before routing a task through one is the whole route the material travels, not only the retention page of the company whose model answers. That check is on the [safety, privacy and governance](/gradient_ascent/techniques/safety/) page. Start narrow by default. Anthropic's own advice to agent builders is "finding the simplest solution possible, and only increasing complexity when needed"[3]: the Use it lane's "widen deliberately," stated as a design default rather than a habit somebody has to remember. Delegating to another agent is still delegating, and the four questions apply to the split as well as to the original task. Anthropic documents over-delegation as a behavior to prompt against rather than a hypothetical: under the heading "Watch for overuse", its prompting guide says "Claude Opus 5 also delegates to subagents more readily than prior models", and points to its own sample prompt for damping that down[1]. That is Anthropic describing its own model, and it is worth knowing before reading a run: a split you did not choose is still a delegation, and [lead agent and workers](/gradient_ascent/techniques/orchestrator-workers/) is where it gets designed on purpose. ## At each level - [Conventional software](/gradient_ascent/levels/0/): nothing is delegated; the code does the whole task by a fixed rule you wrote. - [Direct prompting](/gradient_ascent/levels/1/): you delegate the drafting and keep every decision, because nothing happens until you act on the reply. - [Added context](/gradient_ascent/levels/2/): you also delegate the search, so "how checkable" now depends on whether you can see what was retrieved. - [Workflows](/gradient_ascent/levels/3/): the chain is fixed, so you can delegate most of it and keep a checkpoint at exactly the step that scores worst on the table. - [Tool use](/gradient_ascent/levels/4/): the reversibility row stops being hypothetical, because now something outside the conversation actually changes. - [Agent loops](/gradient_ascent/levels/5/): you delegate a sequence you will not see, so score the table against everything the loop *might* do, not against the task you had in mind. - [Teams of Agents](/gradient_ascent/levels/6/): the split itself is delegated (a lead agent decides who does what), and that decision is now also made without you. - [Always-on agents](/gradient_ascent/levels/7/): the decision moves entirely into advance, as a standing policy, because there is no moment of handover left to think at. See [always-on assistants](/gradient_ascent/techniques/agent-teammates/). ## Practices - Score the task on the four questions before handing it over, and score the row that comes out worst rather than the average of the four. - Encode the boundary as a permission set in advance, not as a judgment the model makes about itself in the moment. - Give a system only the access its task needs. An action it cannot take is one nobody has to supervise. - Widen from the cheapest reversible slice, on evidence from real use, not from a plan made before anything ran. - Re-score the table when the use changes. Boundaries are usually drawn once, for the first narrow task, and then quietly inherited by riskier ones. ## Run it **What to monitor.** The distance between what a system is permitted to do and what it actually does. Permissions granted and never exercised are the ones to remove; actions attempted and refused are the ones to read, since each is either a boundary working or a boundary in the wrong place. **Cost at volume.** A permission boundary costs the same whatever the volume: a disallowed action is disallowed whether attempted once or ten thousand times. What grows with volume is the cost of one drawn too loosely, because the mistake now repeats at the rate of the traffic. **How it fails in production.** The boundary was drawn for a system's first, narrow job and never re-scored as the job widened. Nothing changed in the permissions; what changed is that the actions behind them stopped being cheap and reversible. **What to log.** Every action taken without asking, the permission that allowed it, and who set that permission and when. The last part is what makes the boundary reviewable by someone other than the person who drew it. ## Try it 1. **Use it.** Take a task you already hand to a model and score it on the four questions: cost of a wrong answer, checkability, reversibility, context only you have. Does how closely you actually watch it match the row that scored worst? 2. **Build it.** Find a tool or agent you use that has an auto-approve or autopilot setting. Turn it off for one session and write down every action it would otherwise have taken without asking. Score each on the four questions; the ones that fail a row are the ones to keep asking about. 3. **Either lane.** Pick one task you have never delegated at all. Score it on the four questions and see whether not delegating is the answer the table gives, or just the default you never revisited. ## Sources 1. [Prompting best practices](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices) — Anthropic (Claude Platform Docs) (accessed 2026-09-19) 2. [LLM01:2025 Prompt Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/) — OWASP Gen AI Security Project (accessed 2026-09-19) 3. [Building Effective AI Agents](https://www.anthropic.com/engineering/building-effective-agents) — Anthropic (accessed 2026-09-19) Last reviewed 2026-09-19.