How to Write a Task an AI Agent Can't Misunderstand
A task an AI agent cannot misunderstand names five things, not just the goal. A complete task is one that states the outcome you want, the context to read first, the constraints not to cross, the definition of done, and where the result goes. Skip any one of those and the agent fills the gap with a guess.
The trap is that a one-line task feels efficient. "Improve the homepage" is fast to type, so it feels like delegation. But you have handed off a riddle. The agent still has to decide what "improve" means, what it may touch, and when to stop, and it will decide all of that without you in the room. The five parts move those decisions back to where they belong, which is with you, before the work starts. This article deepens how to delegate to an AI agent with concrete before/after rewrites.
What are the 5 parts of a complete task?
The five parts are goal, context, constraints, definition of done, and output location. Each answers a question the agent would otherwise answer on its own, and each fails in a specific way when you leave it out. Write all five and there is nothing left for the agent to invent.
Goal is the outcome you want, stated as a result rather than a list of steps. "Cut the checkout page load time" is a goal; "add lazy loading and compress the images" is a method you are guessing at. State the result and let the agent find the steps, because it can see the code and you cannot.
Context is why the task matters and which files or links to read first. One sentence of purpose plus two or three file paths saves the agent from reconstructing your intent from scratch. It is the difference between editing the right file and rebuilding something you already have.
Constraints are what the agent must not do: the budget, the guardrails, the files to leave alone. "Do not touch the payment code" and "do not spend anything without asking" are constraints, and they are cheaper to state than to repair. A constraint you skip becomes damage you clean up.
Definition of done is how the agent will know it is finished: the acceptance criteria. "Done when the page scores above 90 on Lighthouse mobile and nothing on it visibly changed" is testable. Without it, the agent stops when it feels done, which is rarely the moment you would call it done.
Output location is where the result goes and how the agent reports it. "Write the changes to the homepage file and summarize them in the session log" tells the agent where to put the work and where to tell you about it. Skip this and good work lands somewhere you never find it.
| Part | What it answers | Failure if you skip it |
|---|---|---|
| Goal | What outcome do I want? | Agent optimizes the wrong thing, confidently |
| Context | Why, and what do I read first? | Agent rebuilds what exists or edits the wrong file |
| Constraints | What must I not do? | Agent crosses a line you never drew |
| Definition of done | How do I know it is finished? | Agent stops too early or gold-plates forever |
| Output location | Where does the result go? | Good work lands somewhere you cannot find it |
Here are three tasks rewritten from vague into complete. The pattern is the same each time: the vague version names only the goal, while the complete version answers the other four questions before the agent has to.
1. Vague: "Improve the homepage." Complete: "Goal: raise the homepage mobile Lighthouse performance score above 90. Context: it is at 62; read index.html and style.css first. Constraints: do not change the copy or layout, do not add any paid service. Done when the score clears 90 and the page looks identical to a human. Output: edit the files and log what changed in the session log."
2. Vague: "Research our competitors." Complete: "Goal: a one-page comparison of the three closest competitors on price, features, and audience. Context: we sell to solo founders; start from the links in research/leads.md. Constraints: only public pages, no sign-ups, no purchases, ignore enterprise tiers. Done when the page cites a source URL for every claim. Output: save it to research/competitors.md."
3. Vague: "Fix the signup bug." Complete: "Goal: users on mobile can complete signup without the form clearing. Context: reproduces on iOS Safari; the handler lives in signup.js. Constraints: do not change the database schema, do not touch the desktop flow. Done when a mobile submission succeeds and you have added a test that would have caught it. Output: commit the fix and note the root cause in the log."
What does a vague task actually cost you?
A vague task costs you a full round-trip, and usually more. The agent does not stall on ambiguity; it fills the gap with a plausible guess and does the wrong thing confidently. Then you review it, discover it optimized for something you never wanted, explain what you meant, and wait for the redo. That is two cycles of work to reach where one complete task would have landed you.
The confidence is the expensive part. A human contractor who is unsure will often ask; an agent that is unsure will frequently proceed, because a guess that reads well is indistinguishable from understanding until you inspect the result. So the cost is not just the wasted work but the review time to catch it, and some wrong guesses ship because they looked fine at a glance.
Compounded over a week, the tax is real. Ten quick tasks that each need one clarifying round are ten extra reviews, ten re-explanations, and ten redos you did not plan for. Two extra minutes writing the task saves the full round-trip that a guess would have cost you.
FAQ
How long should a task be?
As short as possible while still carrying all five parts. Clarity is completeness, not length. A three-line task that states the goal, the context, one constraint, the definition of done, and the output location beats a paragraph of prose that never says when the work is finished. Add words only where a part is still ambiguous, and cut any word that does not help the agent answer one of the five questions.
Can the agent just clarify the task itself?
It can and should ask when a part is missing, and a good agent contract tells it to. But pre-answering the five parts is cheaper than a clarification round-trip. Every question the agent has to ask is a stop, a wait for you, and a restart, and it only asks about gaps it notices. The gaps it does not notice become wrong guesses instead of questions. Writing the five parts up front removes both.
How is this different for research tasks?
The five parts still apply, but two of them shift. The definition of done becomes the deliverable and its sources: a comparison page where every claim cites a URL, not just a request to look into it. Constraints become scope and what to ignore: public pages only, skip enterprise tiers, no sign-ups. Goal, context, and output location work the same. Research fails most often on a missing done-criterion, so make the deliverable explicit.