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:
- Outcome: the result you want.
- Terrain: the files, sources, systems, or constraints the agent should use.
- Boundaries: what the agent may not do without asking.
- Proof: how the agent should show that the work is finished.
Most weak prompts are missing at least two of those.
“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
People can often infer when a job is complete. Agents need it stated.
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 you will have no fair way to judge it.
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 be powerful. It can also turn a vague instruction into an expensive accident.
Ask for checkpoints, not constant narration
Micromanaging an agent defeats the point. Total silence is also risky.
The middle path is checkpoints. Ask the agent to stop at natural gates:
- After it has inspected the material.
- Before it takes an irreversible action.
- When sources disagree.
- When the task appears larger than expected.
- Before it sends anything under your name.
A good checkpoint is not “Are you done yet?” It is “Here is what I found, here is the plan, here are the risks, approve or adjust.”
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:
If you cannot fill those in, the task is probably not ready for an agent. You may need to clarify the work for yourself first.
That is not a failure. One of the quiet benefits of agents is that they force better thinking. A person can survive vague work by improvising. An agent makes the vagueness visible.
What a good handoff feels like
A good agent handoff has a particular feel. The agent knows where to start. It knows what not to touch. It knows when to stop. It can show its work. You can review the result without reconstructing the entire journey from memory.
That is the shape of useful delegation.
Not magic. Not total control. A clear job, a bounded lane, and enough proof that you can decide what happens next.
