Toolkit · Template 1 of 5 · v1.0
Agent Task Brief
One bounded piece of work, handed to an AI agent, with the edges written down: what it may touch, what it must leave alone, and what “done” looks like.
For people building small software products with AI coding agents, alone or in a small team, who want no scope creep and no ambiguity about the finish line. It also suits research and writing jobs.
- Agent: an AI tool that carries out a task in several steps of its own (writing code, searching, drafting), rather than only answering one chat message.
- Second reader: a different person or a different AI model from the maker, who checks the work against the requirement before it is called done. A second session of the same model does not count.
All examples are invented and illustrative. Using this template does not guarantee any result.
Copy the templateWorked exampleWhy these fieldsAll five templates
How to use it
- Fill in every field before you hand the brief to the agent. A blank field is a decision you have not made yet.
- If the brief needs an “and also”, it is two briefs. Split it.
- An empty “Out of scope”, “How to test it” or “Who checks it” field means the brief is not ready to send.
- Write “Definition of done” as something another person could observe, and put the test to run in “How to test it”.
- Note the template version at the top of each brief, and add “edited” if you cut or changed fields.
- Working alone? You are the maker of the brief and the checker of the result. Wait 24 hours and re-read the result cold against the definition of done, or ask any peer to read it. Neither removes the chance of a miss.
Copy the blank template
Plain text. Paste it into a document or notes app. Nothing on this page collects what you type. Free to copy, adapt and share.
Agent Task Brief (template v1.0) Task title: [One line, one deliverable.] Objective: [One short paragraph: the outcome you want, and why.] Scope: [Exactly what the agent may touch: which parts of the work, which systems. Say whether it may fix what it finds or only report it.] Out of scope: [What the agent must not touch or decide.] Risk tier: [Low, medium or high. Low: you read the result yourself. Medium: a second reader checks it. High: a second reader checks it and a named person approves it before it is used.] Inputs provided: [What the agent is given to work from.] Read first: [The files, notes or documents the agent must read before it starts.] Constraints: [The non-negotiables: style, safety, legal, brand.] Definition of done: [The observable condition that ends the task.] How to test it: [The exact test or steps that show the work is done, and the result to expect. Anyone should be able to run it.] Stop and ask if: [Situations where the agent must stop and ask instead of guessing, for example: the requirement conflicts with a constraint, or the fix needs something that is out of scope.] Who checks it: [A different person, or a different AI model, who reviews the result. Not the agent that did the work, and not another session of the same model.] Deliverable format: [What comes back, and in what shape.] Approval boundary: [What the agent may not do without a human step: publish, spend, send, delete, merge.]
Worked example
Example: a brief for a small shop’s checkout code. All names and numbers are invented and illustrative.
| Field | Example entry |
|---|---|
| Task title | Fix the checkout total when a discount code and a shipping fee are both applied |
| Objective | Make the checkout total correct when a discount code and a shipping fee are both applied. The change comes with tests that fail without it. |
| Scope | The checkout total function and its test file only. The agent may fix the function. A bug anywhere else is reported, not fixed. |
| Out of scope | No changes to the screens, the payment provider, or the discount and shipping rules themselves. |
| Risk tier | Medium. It changes what customers are charged, so a second reader checks it before it is used. |
| Inputs provided | Five sample orders: three with known-good totals and two with known-bad totals. |
| Read first | The function, its existing test file, and the written discount and shipping rules. |
| Constraints | No new libraries. Keep the existing test style. |
| Definition of done | The new tests pass, and the two known-bad orders fail them when the fix is taken out. |
| How to test it | Run the checkout test file: every test passes. Take the fix out and run it again: the two known-bad-order tests fail. |
| Stop and ask if | A failing test that points at a discount or shipping rule instead of the function itself. |
| Who checks it | A second person, or a different AI model that has only the requirement, not the maker’s notes. |
| Deliverable format | A change proposal plus a one-paragraph summary of what was tested and what was fixed. |
| Approval boundary | May not merge or release. Hands back the proposal for review. |
Keep filled-in briefs. A short archive of briefs and outcomes shows you which kinds of task the agent handles well and which need tighter scope.
Why these fields are here
The plain fields explain themselves. These are the ones people skip, and the reason each one is there.
- Scope
- Say who fixes what the agent finds. If it only reports, a person makes the fix, or you write a second brief. If it may fix, the fix stays inside this scope.
- Out of scope
- Agents fill gaps with plausible extra work. A written boundary turns “it also improved…” into a visible breach instead of a surprise.
- Risk tier
- A tier is only useful if it changes what happens next. This one sets who has to look.
- Read first
- It is quicker to name the three files that matter than to correct work built on a guess.
- Constraints
- Constraints are rules for how to do the work. Out of scope is what not to touch, and the approval boundary is what needs a person first.
- How to test it
- “It looks right” ends the discussion too early. A test someone else can run does not depend on the maker’s opinion.
- Stop and ask if
- An agent that never stops will always hand back something. A written stop condition turns a wrong assumption into a question.
- Who checks it
- A maker judges the work by the same assumptions it was made with. A different reader given only the requirement may see what the maker cannot.
- Approval boundary
- Some actions cannot be undone or reach other people. Naming them means the agent stops and asks.