Quick answer
Learning how to design a task for an AI agent comes down to writing a four-part contract first: split the job into single-action steps, define what finished looks like and when to stop, name the conditions that force a pause, and write what happens when something fails.
You gave the AI a job. It came back twenty seconds later and said it was done. And it wasn’t — three invoices were skipped, one vendor name was invented, and nothing in the output told you any of that had happened. Knowing how to design a task for an AI agent is what separates that experience from a workflow you can actually leave running.
This is a different skill from writing a good prompt. A prompt asks for an answer and you read it immediately. An agent takes several steps on its own, makes small decisions along the way, and hands you a finished thing — which means the errors happen where you aren’t looking. The fix isn’t a longer prompt. It’s a written specification for the job, and what follows is that specification in four parts, with the exact wording for each one:
- No code, no API keys, no JSON. Everything here is plain English pasted into an instructions box.
- Copy-paste prompts for each part, so you’re editing rather than starting from a blank page.
- The failure each part prevents, named — so you can tell which piece is missing when something goes wrong.
If you can write a clear brief for a new starter, you can do this.
Will this work for you?
Why AI Agents Fail at Office Tasks
AI agents fail at office tasks because they treat ambiguity as something to resolve rather than something to flag. Give a person an unclear instruction and they come back and ask. Give an agent the same instruction and it picks the most statistically plausible interpretation and keeps going — silently.
That single difference explains almost every agent failure you’ll meet at work. It’s also why delegating a task to a colleague and delegating one to an agent are not the same activity, even though they feel similar.
✕ Briefing an agent like a colleague
"Go through this week's invoices and route the big ones to the department heads for approval."
✓ Briefing an agent like an agent
"For each invoice, extract vendor, date and total. If total is above 1,000, mark HUMAN REVIEW. If the vendor is not on the approved list, stop and output UNKNOWN VENDOR. Never guess a vendor code."
Prompts answer, agents act
Your colleague fills the gaps in the first version with judgment — they know “big” means over a thousand because that’s the policy, and they’d ask you if they weren’t sure. The agent fills the same gaps with probability. Sometimes probability is right. When it isn’t, you find out at the worst possible moment.
The four failures below account for most of what goes wrong, and each one maps to a missing piece of the specification:
- Confident completion. The agent reports success but skipped steps or fabricated the data it couldn’t find — the same underlying behaviour behind AI hallucination in everyday use.
- The endless loop. It searches, re-reads, searches again, and never decides it has enough, because nothing told it what “enough” looks like.
- The approval bottleneck. You made it check with you at every step, so it now takes longer than doing the job yourself.
- Drift. By step five it has forgotten the tone rule and the word limit you set at step one.
How to Design a Task for an AI Agent
A Completion Contract is a four-part written specification that turns a vague business task into one an agent can finish: you split the work into single actions, set the standard for what “done” means, decide the signals that force it to stop and ask you, and build a safety net for the moments when something is missing or broken.
Those four parts are the Completion Contract approach we teach at PromptPeakAI, and the order matters — each part closes a gap the previous one opens.
- Split — break the job into steps that each do exactly one thing.
- Standard — define what finished looks like, and when to stop trying.
- Signal — name the conditions that must reach a human.
- Safety Net — write what happens when the input is wrong or a step fails.
The Completion Contract: the four parts of a task specification an AI agent can actually finish.
If you already use the Logic System of Role, Goal, Context and Format for single prompts, think of the Completion Contract as its multi-step sibling. Logic System gets you one good answer. Working out how to design a task for an AI agent gets you a job done unattended.
Split the Work Into Single Actions
Splitting means cutting the job at every point where a decision happens, so each step does exactly one thing and hands a clean result to the next. Most people split too coarsely — three fat steps instead of six thin ones — and the fat steps are where drift lives.
Write the job out as you actually do it today
Not the tidy version. The real one, including the bit where you check the spreadsheet before you email anyone. Sentence per action, ten minutes, done. This is the input for everything that follows.
Cut it wherever a decision or a lookup happens
Every “if it’s X then Y” and every “check against the list” is a seam. Cut there. A step that contains a decision is a step that will make that decision badly.
Name what goes in and what comes out of each step
This is the part people skip, and it’s the one that pays. When each step declares its output format, the next step gets clean input instead of prose it has to re-interpret — the same principle behind specifying output format so AI results are immediately usable. Ask for a labelled list or a small table. You never need to touch JSON.
You are helping me break a recurring work task into steps that an AI agent can run one at a time. My task: [describe the job in 2–3 sentences, as you actually do it today] The tools involved: [e.g. Outlook, a shared spreadsheet, our vendor list] Break this into the smallest sensible steps. Cut the task wherever a decision or a lookup happens — never leave a decision buried inside a larger step. For each step, give me: - Step name (a verb and an object, e.g. "Extract invoice fields") - What it receives as input - What it produces as output, and in what shape (a labelled list, a small table, a single word) - The one decision it makes, if any Return this as a numbered list. If any step still contains two decisions, split it again and tell me you did.
You should now have five to eight steps, each with a named input, a named output, and at most one decision inside it.
Notice the extra piece in the diagram below: a check that runs before step one. If the source data is incomplete, you want to know that immediately, not after four steps of confident processing built on nothing. This is also how chaining prompts across multi-step work stays reliable at length.
One vague goal becomes three gated steps — with an input check that runs before any work begins.
Set the Standard for Done
The Standard is two sentences: what a finished result contains, and when the agent must stop trying. Without the second sentence, an agent with a search tool will keep searching, because more information always looks better than stopping.
Anthropic’s engineering team makes the same point in its guidance on building effective agents, published in December 2024: agents should carry explicit stopping conditions, such as a maximum number of attempts, specifically to keep the loop under control. That advice was written for developers, but the sentence you write is plain English.
✕ No standard
"Research each candidate thoroughly and give me a good summary of their fit."
✓ Standard set
"Produce a summary of exactly four bullets: years of experience, the two required certifications, one quoted line of evidence from the CV, and a fit rating of strong, borderline or no. Search a maximum of two sources. If evidence is missing for any bullet, write NOT FOUND rather than inferring it."
The table below is the pattern I use to convert loose instructions into stop rules. The middle column is what actually happens today, and it’s usually the sentence that changes people’s minds.
| Loose instruction | What the agent does | Stop rule that fixes it |
|---|---|---|
| Summarise the feedback | Writes until it feels finished | Exactly five bullets, 20 words each |
| Check this against policy | Invents a plausible policy line | Quote the policy or write NOT FOUND |
| Find the best option | Searches indefinitely | Compare three options, then decide |
| Make it sound professional | Rewrites your voice away | Change wording only, keep all facts |
| Flag anything unusual | Flags everything or nothing | Flag only items above the threshold |
Add a completion standard to the task below so it cannot run on indefinitely or invent missing information. The task: [paste the step you want to bound] Write me: 1. A "done" definition: exactly what the finished output contains — number of items, length, and the fields it must include. 2. A stop rule: the maximum number of attempts, searches or revisions before it must produce its best available answer. 3. A missing-data rule: the exact words to output when a required piece of information cannot be found. Write all three as instructions I can paste directly into the agent. Keep each one to a single sentence. Do not add anything else.
You should now have three short sentences you can paste under any step: what done means, when to stop, and what to say when something is missing.
Put these where the agent will always read them — the instructions field of the workspace you’re building in, not the individual chat. In Claude Projects that’s the project instructions panel, and the same rules apply on every run without you re-pasting them.
The Claude Projects instructions panel with a set of written boundary and stop rules pasted in, showing the done definition and the missing-data rule.
Crop to the instructions panel only. Hide the sidebar, the account name, the email address, and any other project titles.
File: claude-project-instructions-stop-rules.png · Alt: "Stop rules and a done definition written into the Claude Projects instructions panel"Decide When It Must Ask You
A Signal is a condition that forces the agent to pause and hand the job back to you. Get these right and you keep speed on the routine 90% while keeping judgment on the 10% that could embarrass you. Get them wrong in either direction and the whole thing collapses — too few signals and it sends unvetted work to clients, too many and you’ve built yourself a slower version of doing it manually.
What most guides get wrong here
Nearly every article on this subject tells you to route on a confidence score: automate above 90%, escalate below 80%. Skip that advice. ChatGPT, Claude, Gemini and Copilot don’t expose a numeric confidence score to you, and an agent asked to report one will simply generate a number that looks reasonable. You’d be escalating on fiction.
Use conditions you can actually verify instead. These four cover most office work:
- Value thresholds. Anything over an amount, a headcount, or a date you name.
- Missing required fields. A field the step needs is absent — always a stop, never a guess.
- Named keywords. Words like legal, cancel, refund or complaint in the source text.
- External audience. Anything that leaves the building — a client email, a public post, an invoice.
Rule-based routing: verifiable conditions decide what the agent finishes and what reaches a person.
Microsoft’s own guidance for building agents in Copilot Studio says the same thing in its documentation on designing autonomous agent capabilities, updated in early 2026: keep a human in the loop for high-stakes actions, give the agent the narrowest permissions the job needs, and widen its remit gradually as it proves reliable. Start narrower than feels necessary. You can always loosen it next month.
Write the escalation rules for an AI agent that runs the task below without me watching. The task: [describe the task in two sentences] What would genuinely embarrass me if it went wrong: [e.g. an incorrect figure reaching a client] Give me four rules in plain IF/THEN form, one per line, using only conditions that can be checked objectively — an amount, a date, a missing field, a named keyword, or an external recipient. Do NOT use confidence scores, certainty percentages or any measure the tool cannot actually observe. For each rule, state exactly what the agent should output when it pauses, so I know why it stopped without reading the whole thread.
One more decision belongs here: what the agent is allowed to see at all. Before you connect an agent to a mailbox or a shared drive, apply the same judgment you’d use when deciding what is safe to share with AI at work.
Your own drafts, published material, anonymised sample records.
Client names, internal metrics, a folder rather than a whole drive.
Credentials, HR files, personal data, unreleased financials.
Build a Safety Net for Failures
The Safety Net is the instruction that tells the agent what to do when it cannot do the job. Left unwritten, the default behaviour is to produce something anyway — which is exactly the failure you can’t see from the outside.
Three lines cover the overwhelming majority of real failures. Write them once and reuse them across every agent you build.
| When this happens | What it looks like | The line that fixes it |
|---|---|---|
| Source data is incomplete | Confident output built on gaps | Check required fields first, else stop |
| A lookup returns nothing | An invented but plausible value | Write NOT FOUND, never infer a value |
| A step produces the wrong shape | The next step misreads it | Re-state the output format, then retry once |
| The task exceeds its limits | Silent truncation of the work | Return partial work and name what is missing |
Add failure handling to the agent task below. I need it to fail loudly rather than produce something that looks finished. The task: [paste your steps] Write me four instructions, one sentence each, covering: 1. What to check before starting, and what to output if that check fails. 2. What to write when a lookup or search returns nothing — the exact wording, not a paraphrase. 3. What to do if a step's output is not in the format the next step expects. 4. What to return if it cannot complete the whole task — including how to report which parts were done. Every failure message must name the step that failed and the reason. Do not let it continue past a failed check.
You should now have a complete contract: your steps, your done definition and stop rules, your four escalation rules, and your four failure instructions.
Paste the whole thing into the instructions field of wherever you’re building — the Configure panel if you’re building a Custom GPT, the project instructions if you’re in Claude. Then run it three times on real work you’ve already done by hand, and compare. Three runs is the minimum that tells you anything; one successful run tells you almost nothing.
The ChatGPT Custom GPT Configure panel with the Instructions text area filled with a completion contract, showing the numbered steps and the failure-handling lines.
Crop to the Configure panel only. Hide the account name, the profile picture, and any other GPT names in the sidebar.
File: chatgpt-custom-gpt-instructions-panel.png · Alt: "A completion contract pasted into the Instructions field of the ChatGPT Custom GPT builder"Four failure paths, and the visible output each one produces instead of a fabricated result.
What Task Design Still Cannot Fix
A well-written contract makes an agent reliable at the job you specified. It does nothing about whether that was the right job, and it cannot manufacture judgment the agent doesn’t have.
Four things stay yours no matter how good the contract is:
- Deciding what the task is for. An agent optimises the process you handed it. If the process was wrong, you now get wrong results faster.
- Anything with a relationship attached. Performance conversations, client apologies, bad news. The words matter more than the structure, and the structure is all an agent controls.
- Judging whether the output is actually right. The contract makes failure visible. It does not make correctness automatic — you still verify the substance.
- Accountability. If an agent sends a wrong figure to a client under your name, that is your figure and your name. No specification transfers that.
There’s a cost side too, and most guides won’t mention it. A four-step agent takes longer and consumes more of your usage allowance than one good prompt, because it is making four separate calls instead of one. For a task you do twice a year, that trade is not worth the setup hour. Build agents for the jobs you repeat weekly, and keep the rest as prompts.
Where to start this week
Before anything an agent produces goes out under your name, run the same verification pass you would on any AI output — the workflow in our guide to fact-checking AI research before you put your name on it applies directly here.
Start with one task you repeat weekly, write the four parts, and run it three times against work you’ve already finished so you can see where it diverges. The first contract takes an hour; the fourth takes ten minutes, because you’ll be reusing your own stop rules and failure lines. Save those in a personal AI workflow library — that’s where how to design a task for an AI agent stops being a question and becomes a habit.
Write your first Completion Contract this week
- Pick one task you repeat weekly and write out how you actually do it today. Cut it into steps, splitting wherever a decision or a lookup happens. Write three sentences: what done means, the attempt limit, and the exact missing-data wording. Name four escalation rules using amounts, missing fields, keywords or external recipients. Add the four failure lines, then paste the whole contract into your tool's instructions field. Run it three times against work you have already finished by hand, and compare.