How to brief an AI agent so it does useful work: goal, inputs, constraints, definition of done, review
A brief for an AI agent has five parts: goal, inputs, constraints, definition of done and a review step. Template, worked example and the mistakes that cause bad output.
On this page
A useful brief for an AI agent has five parts: the goal in one sentence, the inputs it may use, the constraints it must not cross, a definition of done it can check itself against, and a named person who reviews the result before anything ships. Leave out any one of the five and you get output that is confident, plausible and wrong in a way nobody notices until later. The brief takes ten minutes to write and saves hours of rework.
This post is the template we use at Atrix for every run of our own agent and for the coding agents our engineers drive, with a worked example and the failure modes we have hit.
Why agents without a brief produce poor output
An agent is a loop: read the task, pick a tool, act, read the result, repeat until it decides it is done. Every one of those decisions is made against the text you gave it. If the text does not say what "done" looks like, the agent decides for itself, and it decides early, because stopping is cheaper than continuing. If the text does not say what it may not touch, it touches whatever is nearest.
By mid-2026 the practitioner consensus has settled on the same point from several directions: teams that get value from agents brief them like a contractor and review the output like a pull request; teams that type a sentence into a chat box and accept what comes back get a stream of plausible work that has to be redone. The tooling improved; the need for a brief did not go away. If anything it increased, because agents now run longer and touch more.
A brief is not a prompt-engineering trick. It is the same document you would write for a new hire doing the task on their first day, shortened because the agent does not need the social context.
The five parts of a brief
| Part | What it answers | One-line test |
|---|---|---|
| Goal | What outcome, for whom, why now | Could a stranger tell when it is achieved? |
| Inputs | What it may read and rely on | Is every source named, with a location? |
| Constraints | What it must not do or change | Would a violation be obvious in review? |
| Definition of done | What the finished thing contains and passes | Can the agent check each item itself? |
| Review step | Who looks, at what, before anything ships | Is a person named, not a role? |
Goal: one sentence, with the outcome not the activity
"Write a requirements doc for booking reminders" is an activity. "Produce the requirements for booking reminders so that engineering can estimate it in Thursday's planning" is an outcome with a reader and a deadline. The second version tells the agent how much detail matters and who will judge it.
Inputs: name the sources, and say which wins
List the documents, issues, pages and data the agent may use, where each one lives, and what to do when they disagree. "The PRD in /pages/booking-reminders is the baseline; the Slack thread is background only; if they conflict, the PRD wins and flag the conflict." Without this, the agent blends sources and loses the thread.
Constraints: what not to touch, what not to assume
Three kinds matter. Scope: "do not propose changes to the calendar sync". Facts: "do not invent customer names, prices or dates; write 'unknown' instead". Actions: "read only; do not create issues or post updates". The last one maps directly to the scopes you grant the agent, which is why brief and permissions should be written together.
Definition of done: a checklist the agent can run itself
Not "a good doc" but "a doc with sections for goal, user stories, non-goals, open questions; every user story has acceptance criteria; no section is empty; under 1,200 words". The agent will check these before it stops, and your reviewer checks the same list, so the two of you are looking at the same thing.
Review step: a named person and a named artefact
"Moeid reviews the requirements page before any issues are created." A review step with a role ("the PM") instead of a name gets skipped. A review step without an artefact ("review the work") turns into a glance.
A brief template you can copy
Goal: <outcome, reader, deadline>
Inputs:
- <source 1, location, role: baseline | background>
- <source 2 ...>
If sources conflict: <which wins; flag the conflict>
Constraints:
- Scope: <what is out>
- Facts: do not invent <names, numbers, dates>; write "unknown"
- Actions: <read only | may create X | may not Y>
Definition of done:
- [ ] <section or output 1 present>
- [ ] <each item has ...>
- [ ] <length or format limit>
- [ ] open questions listed, not resolved by guessing
Review: <person> reviews <artefact> before <next action>.
Keep it under 200 words. A long brief is a sign the task is two tasks.
Worked example: a Develop run in Atrix
Our own AI agent takes a brief and returns three things from a Develop run: a requirements document, an architecture document and a set of planned issues, all for a person to approve before anything becomes real work. A run uses one of the plan's AI runs (100 a month on Builder, 500 on Studio); chatting with the agent does not. The brief we gave it last week, lightly edited:
Goal: Requirements, architecture and planned issues for "booking
reminders" so that we can plan the next cycle on Friday.
Inputs:
- Page "Booking reminders: notes" (baseline)
- Issues labelled "reminders" in the Calendar product (background)
If sources conflict, the page wins; list the conflict in open questions.
Constraints:
- Scope: email and in-app only; no SMS this cycle.
- Facts: do not invent delivery rates or customer quotes.
- Actions: this is a planning run; create planned issues only, no
status changes on existing issues.
Definition of done:
- [ ] Requirements with user stories and acceptance criteria
- [ ] Architecture naming the components touched and the ones not touched
- [ ] Planned issues sized small enough for one person in one cycle,
each linked to the requirement it implements
- [ ] Open questions listed
Review: Moeid approves the requirements page, then the planned issues,
before they enter the backlog.
What came back was eleven planned issues, two open questions (one of which was a real conflict between the notes page and an old issue), and an architecture doc that correctly left the sync layer alone. The requirements audit later compared the delivered issues against that frozen baseline and reported coverage; it checks requirements against the plan, not code, so the "architecture doc is honest" part was still ours to verify.
Where the agent fell short: it sized two issues too large, and it resolved one open question by guessing despite the constraint. Both were caught in review, which is the point of having one.
Mistakes that produce bad output
- Goal written as an activity. The agent does the activity and stops.
- No baseline named. It blends three sources and the result matches none of them.
- "Use your judgment" on facts. It invents a number. Say "unknown" is acceptable.
- Definition of done in the reviewer's head. The agent cannot check what it was not told.
- Review by role. Nobody owns it; it ships.
- A brief for two tasks. Split it. Two short runs beat one long one.
- Writing the brief after the run to justify the output. The brief is the contract; it comes first.
FAQ
What should an AI agent brief include?
Five things: a one-sentence goal with the outcome and reader, the inputs it may use and which one wins, the constraints on scope, facts and actions, a definition of done it can check itself, and a named reviewer with a named artefact. Under 200 words.
How is briefing an agent different from prompting a chatbot?
A chatbot answers once and you read it. An agent acts many times before you see anything, so the brief has to cover what it may touch and when to stop, not just what to say. Constraints and definition of done matter more than wording.
How detailed should the definition of done be?
Detailed enough that the agent can tick each item without asking you, and short enough that your reviewer will actually check it. Five to eight checklist lines is typical.
Should the agent be allowed to resolve open questions?
No. Ask it to list them. An agent that resolves ambiguity by guessing produces output that looks finished and is wrong in the details that matter most.
What is an agent run?
One execution of an agent against a brief, with a start, an end and an artefact to review. In Atrix a Develop run returns requirements, architecture and planned issues; see the glossary entry on agent runs and the definition of an AI agent.
Does a good brief remove the need for review?
No. A good brief makes review faster, because the reviewer checks the definition of done rather than reading everything cold. The review step is the part that catches the two or three things the agent got wrong anyway.
Next step
Take the next task you were going to hand an agent and write the five parts before you start it. If the definition of done is hard to write, the task is not ready for an agent yet. To see what a briefed run returns in practice, the AI agent page shows the requirements, architecture and planned issues a Develop run produces.