How to write instructions for AI agents (with a definition of done)

Good instructions for AI agents look less like a clever prompt and more like a brief you would give a capable new hire on their second day: what result you want, where to find the material, what not to do, how you will judge it finished, when to come back to you, and what to hand you at the end. When agents underperform on real business work, the cause is usually a missing piece of that brief rather than the model.

This article gives you a template, three worked examples and the most common gaps. It is part of our series on delegating work to AI agents, which covers choosing tasks and setting autonomy levels.

How to write instructions for AI agents: the six-part template

Write the outcome first and the report format last. If you can’t write the outcome in one sentence, the task is probably two tasks.

Defining done so the agent knows when to stop

“Done” is the part people skip, and it is the part that matters most. Without it an agent will either stop too early (“I’ve drafted the first three”) or keep going past where you wanted (“I also updated the prices”). A good definition of done is a short list of statements you could tick off by looking at the result.

• Checkable, not aspirational. “Every invoice over 14 days has a queued reminder or a skip reason” rather than “overdue invoices are handled”.
• Says where the output lives. “Saved as a sheet in the Prospects folder” or “queued for my approval in this thread”.
• Includes the paperwork. “CRM note added to each contact” if you want the record kept, because the agent can’t guess that you care.
• Says what is out of scope. “Do not update prices or send anything” prevents helpful overreach.

Stop conditions: telling the agent when to ask

Agents are built to be helpful, which means that when something doesn’t fit, they tend to make a reasonable guess. Stop conditions turn that guess into a question. Keep a standard set you paste into every brief, then add task-specific ones.

• Data is missing, or two sources disagree.
• An amount is over a threshold (pick one: A$1,000, A$5,000 — whatever is material to you).
• The person is tagged as a complaint, dispute, payment plan or VIP.
• The message mentions a refund, a lawyer, a tribunal, an ombudsman or a regulator.
• The instruction seems to conflict with an earlier rule.
• Anything would be sent, paid, published or deleted outside the approval flow.

Stop conditions are also where approvals come from. Every “ask me first” becomes an approval request, so it pays to make those requests quick to answer — see designing approval gates.

Three worked examples: bad brief, good brief

Prospect research

Bad: “Find me some leads in Brisbane.”

Good: “Outcome: a list of 25 independent physiotherapy clinics in Brisbane’s northern suburbs that could use after-hours call answering. Inputs: Google Maps, clinic websites, our CRM to exclude existing contacts. Constraints: independents only, no franchises; do not contact anyone. Done: a sheet with name, suburb, website, phone, number of practitioners if listed, whether they show after-hours hours, and a one-line reason each is a fit; existing CRM contacts excluded. Stop if: fewer than 15 qualify — tell me and suggest how to widen. Report: the sheet link plus three lines on patterns you noticed.”

Payment reminders

Bad: “Chase the overdue invoices.”

Good: “Outcome: clients more than 14 days overdue get a friendly reminder this week. Inputs: overdue list in Xero; last three emails with each client. Constraints: skip anyone tagged payment plan; no mention of fees; my usual sign-off. Done: a draft reminder for each eligible invoice queued for my approval, and a skip reason for each ineligible one. Stop if: the client replied in the last 7 days, the amount is over A$5,000, or there is any sign of a dispute. Report: one message: who, how much, who was skipped and why.”

A recurring internal job

Bad: “Keep the inbox tidy.”

Good: “Every weekday at 7am. Outcome: the shared inbox only contains things a person needs to act on. Inputs: the info@ inbox. Constraints: never delete; archive only; never reply. Done: supplier invoices filed to Accounts/Inbox with the supplier name in the file name; newsletters and receipts archived; everything else left in place and listed. Stop if: a message looks like a complaint or a legal notice — flag it at the top. Report: add a one-line count to the morning exception report.”

That last line matters. Recurring jobs should report into one daily message rather than pinging you separately; we design that message in the daily exception report.

Turning a customer request into an internal brief

A lot of delegation starts with a customer email: “Can you send through a quote for the three units on Elm St, and can someone come out before the 20th?” The fastest pattern is to forward it to the agent with one line — “brief this” — and ask it to return the six-part brief for you to correct. You are much quicker at fixing a draft brief than writing one from scratch, and the agent learns your corrections.

Ask for the brief to separate facts from assumptions: “Customer said three units (fact); assuming standard clean, not end-of-lease (assumption — please confirm).” Assumptions are where jobs go wrong.

Checklists without bureaucracy

Some readers worry this turns every task into paperwork. It doesn’t have to. You write the brief once for a recurring task and then refer to it by name: “Run the overdue reminders brief.” For one-off tasks, three lines usually suffice: outcome, done, stop if. Keep the full template for anything new, outward-facing or involving money.

The rule of thumb: the more expensive a mistake, the longer the brief. A request for a summary of a PDF needs one line. A brief to email 40 clients about a price change needs all six parts and an approval gate.

Keeping instructions current

Instructions decay. You change a policy, take on a new service area or decide you no longer offer weekend work, and the brief still says the old thing. Three habits help:

1. When you correct the agent, say “update the brief” and check the written rule changed.
2. When a policy changes, ask the agent to list every recurring brief the change affects before you announce it.
3. In your weekly review, read one brief end to end. It takes two minutes and catches drift.

If you are briefing a coding agent rather than an operations agent, the structure is similar but the definition of done includes tests and deployment; see how to brief an AI coding agent. And when one brief spans several specialists, the orchestrator does the splitting — the Sessions page shows how a single request becomes several owned tasks.