How to write an instruction that holds
A prompt that works in testing drifts by run four hundred. What separates a chat prompt from a standing instruction an unattended worker can run on.
The hardest part of an AI worker is not the model and not the wiring. It is the instruction, and specifically the fact that it has to work on run four hundred, on an input nobody imagined, with nobody watching.
A prompt you write in a chat window is a different object from a standing instruction, and most disappointment with unattended agents comes from writing the first and deploying it as the second.
Chat prompt vs standing instruction
| A chat prompt | A standing instruction | |
|---|---|---|
| Lifespan | One exchange | Hundreds of runs |
| Ambiguity | You resolve it live | It resolves itself, differently each time |
| Unusual input | You notice and rephrase | Nobody notices |
| Success | You judge it as it arrives | Judged later, in aggregate, or never |
| Missing information | You supply it | It guesses, plausibly |
| Length | As short as you like | Long enough to be unambiguous |
The middle rows are where drift comes from. Every ambiguity you leave is a decision the model makes fresh on each run, and the same ambiguity resolves differently on a Tuesday with an odd input than it did in testing.
The five parts
A standing instruction that survives has five components. Missing any one of them produces a specific failure you can predict.
1. The job, in one sentence
If you cannot state what the worker does without "and", it is two workers. This is the same test that keeps a fleet legible, and it applies inside the instruction too: a worker that knows exactly what it is for makes better decisions in cases you did not enumerate.
2. A definition of done
What does a finished run look like? "Every new thread is either classified or flagged for a person" is a definition of done. "Keep on top of the inbox" is not.
The tell for a bad one is the word appropriate. If your success criterion needs "handle it appropriately", you have moved the judgement into the model and kept none of it yourself.
3. The edge cases you already know
Not every edge case, which is impossible, but the ones you have already hit. Every surprise a run produces is a candidate line for the instruction, which is why the first two weeks of receipts are the most valuable input you will get.
4. What to do when unsure
This is the one most often missing and the one that causes the most damage. A model with no stated fallback will pick the helpful-looking option, every time.
State it explicitly: leave it in drafts, flag it, skip it, do nothing. "When in doubt, do nothing and note why" is a legitimate and underused instruction.
5. What it must never do
Worth writing, and worth understanding what it buys you. It is a strong default, not a guarantee. Anything whose violation you would have to explain to a customer belongs in a control, not a sentence, which is why the app firewall, contact rules and redaction exist. Instructions decide what a worker should do; controls decide what it can do at all.
Worked: turning a prompt into an instruction
Start with what people actually write first:
Triage my support inbox and draft replies.
Now the same job as a standing instruction:
Job: Triage the support inbox each hour and prepare replies for review. Done when: every thread received since the last run is either categorised (billing, bug, how-to, other) with a draft reply prepared, or flagged for a person with a one-line reason. Drafts only. Never send. Leave every reply in drafts. Known cases: threads mentioning refunds go to a person, not a draft. Threads in a language other than English are flagged, not translated. A reply to an existing thread continues that thread rather than starting a new one. When unsure: flag for a person with the reason. Do not guess a category. Never: promise a delivery date, quote a price, or state a policy that is not in the help centre.
Roughly six times longer, and every added line removes a decision the model would otherwise make differently on different days. That is the whole trade: length in exchange for variance.
Where the lines come from
You do not write the good version first, and trying to is a waste of an afternoon. The path that works:
| Stage | What you do | What it produces |
|---|---|---|
| Day 1 | Write the job, done-when, and the fallback | A worker safe to run read-only |
| Week 1 | Read every receipt | The first real edge cases |
| Week 2 | Add the cases you hit, tighten "done when" | An instruction that matches reality |
| Ongoing | Add a line each time something surprises you | Slow convergence |
The instruction is a record of everything that has surprised you, which is why it cannot be written in advance and why starting a worker at Read is such a cheap way to learn.
This is also exactly what you are buying from a kit publisher: a kit ships with that convergence already done, so you inherit the edge cases somebody else paid for in surprises. Support Inbox Triager is that instruction, written and tested, reaching email and tasks on a schedule.
Instruction, memory, or context?
Three places a fact can live, and putting one in the wrong place is a common cause of drift:
- Instruction: rules true for every run. The categories. The fallback.
- [Memory](/glossary/worker-memory): facts about your situation that persist but change occasionally. This customer is on a bespoke SLA.
- Context: what this run reads from your apps. Today's threads.
Anything that changes every run belongs in context, read fresh. Putting it in the instruction guarantees a worker reasoning from a stale copy of something it could simply have looked up.
The failure mode: the instruction that grew
The opposite failure is real and less discussed. An instruction accumulating a line per surprise becomes, after a year, four hundred lines of conditionals that nobody dares edit, where half the rules contradict each other and none of the authors are still around.
Two disciplines keep it survivable. Prefer **general rules over specific patches**: "flag anything mentioning money" beats twelve rules about refunds, chargebacks and invoices. And when a rule turns out to describe a different job, split the worker rather than adding a branch.
If your instruction has grown an "if this is actually about X" clause, X is a second worker.
The reasonable objection
"Models are good enough now. Write what you want in plain language and let it figure out the rest."
They are much better, and this genuinely works for a chat session, where you are present to catch the miss. Unattended is a different problem: the question is not whether a model can infer your intent but whether it infers the same intent on four hundred structurally different inputs with nobody checking.
A vague instruction is not wrong, it is high-variance. Specificity is not distrust of the model, it is a decision about where variance is acceptable.
When not to over-specify
- Tone and phrasing. "Match our voice, lead with the answer" beats a style guide. This is what models are genuinely good at.
- Judgement between permitted options. If any of three categories is defensible, let it choose; that is the job.
- Before you have data. Written in advance, most edge cases are imagined. Ship narrow, read receipts, then specify.
- When the answer is a control. If a rule must never be violated, an instruction is the wrong instrument entirely.
FAQ
How is a worker instruction different from a prompt?
A prompt is written for one exchange with you present to catch mistakes. A standing instruction runs hundreds of times unattended, so every ambiguity it leaves becomes a decision the model makes fresh each run, resolving differently on different inputs.
How long should an AI worker's instruction be?
Long enough that a competent stranger could follow it without asking questions. In practice that is several times longer than the prompt you would type in chat, because each added line removes a decision the model would otherwise make inconsistently.
What is the most commonly missing piece?
What to do when unsure. Without a stated fallback a model picks the helpful-looking option every time. "Flag for a person with the reason" or "do nothing and note why" are legitimate and underused instructions.
Should safety rules go in the instruction?
Write them, but do not rely on them. An instruction is a strong default the model weighs against everything else; anything whose violation you would have to explain to a customer belongs in a control such as the app firewall or contact rules, which are enforced outside the model.
How do I know what edge cases to include?
From receipts. Run the worker read-only for a week and read what it actually did; every surprise is a candidate line. Edge cases imagined in advance are mostly wrong, which is why kits are valuable: they ship with somebody else's convergence already done.