Your team is ready to let an AI agent move from recommending an action to taking it. The demo looks convincing. Then the important question arrives: exactly what can the agent change without asking you?

That question is the real product specification. Once an agent can send, publish, buy, cancel, delete, or change access, a good prompt is no longer an adequate control. You need a delegation contract that limits its authority, places approval before consequential actions, and defines the evidence required to call the job complete.

Start with consequence, not task complexity

A difficult research task can be relatively safe if the output is only a draft. A simple button click can be high risk if it cancels a contract, submits a payment, or removes data. The cognitive difficulty of a task should not determine how much autonomy you grant.

I use a simpler rule: autonomy should increase with reversibility and observability, not with how impressive the model appears. Assess each delegated task on four dimensions:

• Impact: What could the action cost in money, access, customer trust, or operational disruption?
• Reversibility: Can a person restore the prior state quickly and completely?
• Reach: Does the action affect one draft, one account, a customer segment, or a public audience?
• Detectability: Would you know promptly if the action were wrong, incomplete, or duplicated?

Use those answers to choose the lowest autonomy level that still removes meaningful work:

Delegation mode	What the agent may do	Where it must stop
Advise	Read approved information, analyze it, and recommend an action	Before changing any external state
Prepare	Draft a message, fill a form, assemble a cart, or stage a proposed change	Before sending, submitting, publishing, or purchasing
Act within limits	Perform a predefined action using approved tools, targets, and constraints	When a limit is reached, context changes, or the result is uncertain
Commit	Perform an action with financial, contractual, public, access, deletion, or cancellation consequences	Immediately before the commitment unless that exact action was explicitly pre-authorized

Preparation is often the best first boundary. The agent can remove searching, comparison, data entry, and drafting while a person retains the final commitment. That is useful automation without pretending every click has the same consequence.

External systems also impose boundaries of their own. An agent can prepare a trip successfully and still be unable to complete the hotel booking because the business does not accept that route. Treat this as a normal handoff condition. It is not a reason to broaden permissions, conceal the automation, or improvise around the business’s controls.

Split the job where decisions and consequences change

A single instruction that combines research, judgment, preparation, and execution hides several different decisions inside one run. It also removes the moment when you could correct a bad assumption before it becomes an external action. Asking the agent to work through smaller, reviewable steps creates those control points.

Do not insert human review after every model response. That produces approval fatigue without reducing the important risk. Put checkpoints where one of three things changes: the decision owner, the information being relied on, or the consequence of proceeding.

A hotel-booking workflow, for example, can be separated into a clear sequence:

1. Search only the approved dates, location, and requirements.
2. Return a shortlist with the trade-offs that matter to the traveler.
3. Let the traveler select an option or authorize a stated selection rule.
4. Prepare the checkout using the selected room and approved traveler information.
5. Present the property, dates, room, final total, and cancellation conditions together.
6. Request approval for that exact booking.
7. Submit it once.
8. Retrieve the confirmation from the place where the booking should exist.

The approval belongs between preparation and submission, not at the beginning of the search. At the beginning, the final option and terms do not yet exist. A person cannot meaningfully approve an unknown transaction.

The same pattern applies to publishing a campaign, changing a customer record, renewing a vendor, or sending an external message: investigate, propose, select, stage, approve, execute, verify. Some low-consequence workflows can combine stages. The decision and commitment boundaries should remain explicit even when the interface makes the flow feel continuous.

Write a five-part delegation contract

A prompt describes what you want. A delegation contract also defines what the agent is allowed to do when the path becomes ambiguous. It should cover five controls before the agent receives an action-capable tool.

1. Outcome boundary: State the result, the intended recipient or destination, and what is outside the assignment. “Prepare a renewal recommendation” is different from “renew the contract.”
2. Access boundary: Name the accounts, tools, data, and credentials the agent may use. Limit access by purpose and duration where the system supports it. Access to one account should not silently imply access to related accounts.
3. Decision boundary: Separate choices the agent may make from choices reserved for a person. Define prohibited substitutions, audiences, categories, or changes instead of relying on the model to infer what feels important.
4. Approval boundary: Identify the exact action that requires approval and the facts the approver must see. Include applicable spend, volume, audience, date, or permission limits. A budget ceiling constrains a transaction; it does not automatically constitute consent to spend.
5. Completion boundary: Define the state that proves success, how partial completion will be reported, and when the agent must stop. “The submission was attempted” is not the same as “the destination accepted and recorded it.”

These controls should appear in the product’s permissions, workflow configuration, and approval interface where possible. A paragraph in a system prompt can guide behavior, but it is a weak place to enforce a payment ceiling or prevent access to an unrelated account. The available tools should make prohibited actions unavailable, not merely discouraged.

A reusable delegation brief

Before connecting the agent to an external system, have the product owner complete these lines:

• Objective: Produce or change [specific outcome] for [specific target].
• The agent may: Use [named tools and data] to perform [allowed actions].
• The agent may not: Perform [prohibited actions], use other accounts, change the target, or substitute materially different terms.
• The agent must ask before: [send, publish, purchase, cancel, delete, disclose, grant access, or other consequential action].
• The approval request must show: [target, final terms, total cost, audience, data disclosed, and material changes].
• The task is complete only when: [observable state and required evidence].
• Stop and return control when: Information is missing, a limit is exceeded, the approved terms change, the destination refuses the action, or success cannot be verified.

If the owner cannot fill in those lines without phrases such as “use judgment” or “do whatever is necessary,” the job is not ready for action-level delegation. Keep the agent in advise or prepare mode until the ambiguous decisions have owners.

Put approval before commitment and verification after it

Make approval specific enough to mean something

An approval should authorize one identifiable action, not express general confidence in the agent. “Continue” or “looks good” is too vague when the next step can create a charge, contact a customer, publish material, alter access, or cancel a service.

Show the approver the information that would change a reasonable decision:

• The action and its target
• The final amount and currency, including whether a charge repeats
• The audience, quantity, or scope of the action
• The terms that control cancellation, renewal, access, or disclosure
• Any material difference from the option previously selected
• Whether this is a first attempt or a retry

Permissions and approvals perform different jobs. Permission is the ceiling: it defines what the system can technically do. Approval activates a particular action below that ceiling. A specific approval should not override a system limit, and a broad permission should not be treated as approval for every action it enables.

Approval should expire when its material context changes. A different recipient, higher total, broader audience, altered cancellation condition, or new permission request needs a fresh decision. The agent should not reinterpret an earlier “yes” to cover the new state.

Verify the result where it is supposed to exist

An agent saying “done” is evidence about its own process, not proof of the external outcome. The final check should happen in the system where the result is meant to land: the merchant account, sent-message folder, publishing system, calendar, access-control list, or other destination of record.

Require a compact completion record containing:

• The action actually performed
• The destination and a usable identifier
• The resulting state, not just the submitted request
• A confirmation, receipt, recorded change, or equivalent evidence
• Any incomplete step, warning, or exception

This is especially important after a timeout or ambiguous response. Before retrying a payment, message, cancellation, or submission, check whether the first attempt already landed. Blind retries can turn uncertainty into duplicate external actions.

Failure behavior deserves the same design attention as success. The agent should return a clear status such as blocked by destination, missing information, outside authority, partially completed, or outcome unverified. It should not silently change the target, select a materially different option, or claim completion because it exhausted the available steps.

Roll out autonomy one rung at a time

Start with a task that is frequent, bounded, reversible, and easy to verify. Avoid beginning with the workflow that offers the largest theoretical saving if it also has the widest permissions and weakest evidence.

1. Run the workflow in advise or prepare mode.
2. Record where people correct the agent, request missing context, or reject its proposed action.
3. Tighten the task definition and add explicit exception paths.
4. Enable one action type with narrow access and an exact approval gate.
5. Verify every external result at its destination.
6. Expand authority only after the existing boundary behaves predictably, including when the task fails.

Measure control quality, not just raw completion. A system can make its completion rate look better by skipping approvals, concealing uncertainty, or treating partial work as success. A more useful operating view includes:

• Verified completion rate
• Human correction rate before commitment
• Unplanned handoff rate and its causes
• Approval requests that contained no material decision
• Unverified or incorrectly reported completions
• Duplicate-action incidents after retries
• Actions attempted outside the stated boundary

There is no sensible target that makes an out-of-boundary action acceptable. Treat that metric as a control failure to investigate, not as ordinary model error to average away. For the other measures, establish a baseline for the specific workflow and use it to decide whether more autonomy will remove work or merely move risk downstream.

Key takeaways

• Choose autonomy based on impact, reversibility, reach, and detectability – not task complexity.
• Separate investigation, selection, preparation, commitment, and verification so approval occurs at the consequential edge.
• Constrain both what the agent can access and what it is authorized to decide.
• Treat a budget or permission as a ceiling, not as blanket consent.
• Invalidate approval when the target, amount, terms, audience, or permissions materially change.
• Call the task complete only when the intended state is verified at the destination.

Before your next agent pilot, make its owner finish this sentence: “The agent may do ___, must ask before ___, and is finished only when ___.” If any blank stays vague, keep the workflow in preparation mode. The next step is not a broader prompt. It is a sharper boundary.

References

• Nate Jones’s Substack – Five controls to set before you let an AI agent buy, pay, or cancel anything for you
• AiPop – Don’t Ask AI to Do Everything

---