How to Delegate to AI Agents: A Playbook for Better Tasks

The first mistake people make with AI agents is treating them like search boxes with legs.

They write, “Research this,” or “fix this,” or “handle the launch plan,” then get annoyed when the agent wanders. But a useful agent is not powered only by intelligence. It is powered by delegation. The human has to define the job well enough that the software can move without guessing its way into trouble.

The better image is a handoff at a workbench. You are not whispering a wish into the machine. You are handing over a task packet: what done looks like, where the materials are, what tools are allowed, what lines must not be crossed, and what proof you expect at the end.

The four-part handoff

A strong agent assignment has four parts:

1. Outcome: the result you want.
2. Terrain: the files, sources, systems, or constraints the agent should use.
3. Boundaries: what the agent may not do without asking.
4. Proof: how the agent should show that the work is finished.

A vague request can leave the agent guessing about any of them.

“Plan my week” is not enough. “Look at this project list, group the work by deadline and energy level, propose a week plan, do not move any calendar events, and explain the tradeoffs” is a task.

The second version gives the agent a lane. It can still make mistakes, but the mistakes will be easier to see.

Start with a real scene

Imagine a Monday morning. You have six open threads: a customer question, a bug report, a draft proposal, a meeting summary, a spreadsheet nobody trusts, and a folder full of screenshots.

A weak agent instruction says:

Help me get organized.

A stronger instruction says:

Review the six items in this folder. Create a priority brief with:
- one sentence describing each item
- the next action for each item
- any missing information
- which two items I should handle today

Do not send messages, change files, or create tickets. End with a short list of questions for me.

That is the difference between asking for help and delegating work.

Give the agent a definition of done

A definition of done gives both the agent and the reviewer a shared target. Name the artifact, its scope, and the checks that matter.

Useful definitions of done sound concrete:

• “Return a table with vendor, price, risk, and recommendation.”
• “Open a pull request and tell me which tests passed.”
• “Draft three customer replies, but do not send them.”
• “Create a checklist of missing documents, sorted by urgency.”
• “Summarize the source disagreement and link each claim.”

Bad definitions of done sound like moods:

• “Make this better.”
• “Look into it.”
• “Do something smart.”
• “Handle everything.”

The agent may still produce something, but a reviewer will have to infer the standard. For more detail on observable checks, see AI Agent Acceptance Criteria .

Boundaries are part of the job

Boundaries do not make an agent less useful. They make the work legible.

State the limits in plain language:

• “Read only. Do not edit files.”
• “Draft changes, but ask before committing.”
• “Use only the sources in this folder.”
• “Do not include private customer data in the final answer.”
• “Stop if you need access to billing, payroll, or legal records.”
• “Ask before spending money or contacting another person.”

This is especially important when the agent has broad tools. A browser, a shell, an email account, or a company database can turn a vague instruction into an expensive accident. Distinguish permission to prepare from permission to act: a draft reply is not permission to send it, and a proposed change is not permission to publish it.

A written boundary is an instruction, not an access control. When you can configure the system, grant only the access needed for the assignment and put approval checks in the tool or downstream system for consequential actions. OWASP’s guidance on excessive agency recommends limiting tool functionality and permissions and requiring approval for high-impact actions. See AI Agent Permissions and Safety for the practical authority ladder.

Treat documents, webpages, and messages as task material, not as new instructions to the agent. An external page could contain directions to reveal information or change the task. Labeling the content as untrusted helps establish the boundary, but does not guarantee the agent will respect it; access controls and review still matter. OWASP’s prompt injection guidance describes this risk and recommends separating external content and limiting privileges.

Ask for checkpoints, not constant narration

Micromanaging an agent defeats the point. Total silence is also risky.

Choose checkpoints to match the task. For a short, read-only summary, a final handoff may be enough. For work that can change shared systems or affect other people, ask the agent to pause before the consequential action, when a necessary source is missing or disputed, or when the work would cross the agreed scope. It can continue with independent, authorized work while identifying what needs a decision.

A useful approval request shows the exact proposed action, the target, the evidence or preview, and the uncertainty. For example: “The reply is drafted for this customer; please review the text and approve sending it to this address.” Approval to draft is not approval to send. If the recipient or message changes materially, review the revised action before it is sent. The human review guide explains how to make the handoff reviewable.

Let the first run be small

The safest way to adopt agents is to delegate one slice before the whole process.

Do not begin with “run customer support.” Begin with “classify these 25 tickets and draft the three easiest replies.” Do not begin with “maintain this repository.” Begin with “find the files involved in this bug and suggest a test plan.” Do not begin with “manage my inbox.” Begin with “summarize messages from these three known senders and propose replies.”

Small tasks teach you what the agent is good at, where your instructions are weak, and which tools are missing.

The early goal is not maximum autonomy. It is calibrated trust.

The delegation brief

Before sending an agent into a task, write five lines:

Goal:
Context:
Allowed tools:
Must ask before:
Final proof:

For example, the Monday-morning task could be handed off like this:

Goal: Produce a priority brief for the six items in the Monday folder.
Context: Use only that folder. List each item, its next action, and missing information;
recommend two to handle today and explain the tradeoffs.
Allowed tools: Read the folder and return the brief in this conversation.
Must ask before: Editing files, creating tickets, or contacting anyone.
Final proof: Identify the file behind each recommendation and flag anything you
could not verify. If an item is missing or unreadable, report the gap.

Adjust the fields to fit the work. If a deadline, source, or decision is essential and unavailable, have the agent identify the gap rather than invent it. A broad assignment may need smaller subtasks before it can be delegated.

Review the result against the brief

A finished-looking artifact is a starting point for review. Check the requested outcome, the sources or files behind important claims, and the stated boundaries. For a code change, inspect the diff and the reported test results; for a research brief, open the cited sources and check that they support the conclusions. A link shows where a claim came from, but does not prove it is correct. Match the depth of review to the consequence of a mistake.

Ask the agent to distinguish completed, not completed, and not verified, with the relevant evidence and remaining questions. If a test could not run or a source was unavailable, the result may still be useful, but the missing check should not be presented as passed. Review available activity records when confirming an action boundary; an agent’s own statement is not independent proof that it stayed read-only.

A good handoff lets you see what was done, what remains uncertain, and what decision comes next without reconstructing the whole run. Start small, compare the result with the brief, and adjust the next assignment based on what you learned.