AI Agent Task Brief: A Template for Clear Delegation

What belongs in an AI agent task brief?

Start with the decisions only you can make. Who is the result for? Which information should count as evidence? Is the agent preparing a draft or sending it? What should happen when a date is missing? Leaving those decisions implicit asks the agent to choose your operating rules.

OpenAI Academy's Agent Requirements Doc separates the mission, inputs, permissions, output requirements, quality checks, and escalation points. Those are useful categories even when you use a different AI app. The template here is an original, smaller task-level version for work you want to review yourself.

For a one-off task, a few precise paragraphs are enough. For recurring work, save the brief as a text file you control. Give it a version number when you change a rule. You then have a record of what you asked for, rather than relying on an old conversation to explain it.

Copy this AI agent task brief template

Replace the square brackets before using it. Remove fields that do not apply. A plain text file is fine; the value is in the decisions, not the file format.

TASK: [A short name and version]

RESULT
Produce [specific artifact] for [reader/use].
It should help me decide or do [one concrete thing].

INPUTS
Use only [named files, records, or approved sources].
The reporting period or cutoff is [date/time, if relevant].
When sources conflict, [rule or person who decides].

OUTPUT
Create [file or reply] in [location], with [required sections].
Use [length, format, and tone].
Include source references I can check.

PERMISSIONS
You may read [scope] and create [scope].
Do not [specific actions outside this job].
Stop before [action that needs my approval].

DONE MEANS
- [A visible, pass/fail check]
- [A second check]
- [What evidence to return with the result]

GAPS AND STOPPING
If [missing input or conflict], [mark it or ask me].
Do not invent facts to finish the format.
After [bounded attempt], return the result or the blocker.
Do not expand the task to fix unrelated problems.

A written permission is not an access control. Set the app's actual tool permissions to match the brief. A report-drafting task does not need an email-sending connection. Start in a folder containing copies of the intended inputs, rather than granting access to your whole business workspace.

If your app cannot read files or create documents, use the same brief with pasted inputs and ask for the result in the conversation. State that change explicitly. Do not accept a claim that a file was saved when the app has no way to save it.

A worked example: the Friday client update

This example uses a fictional design business and a fictional client. It is a teaching example, not a claim about a customer or a measured result.

The loose request is: "Sort out this week's client updates." That could mean summarize notes, write drafts, change project records, or email clients. It also leaves the week and the source of truth undefined.

Here is a brief that resolves those choices. Imagine you have made an agent-practice folder with an inputs folder and an empty drafts folder inside it.

TASK: Harbor weekly update, version 1

RESULT
Prepare a client-ready draft for me to review. Explain progress,
the current blocker, and the next confirmed date.

INPUTS
Read inputs/harbor-notes.txt only. Cover September 21-25, 2026.
Use facts recorded in that file. Do not research the client online.

OUTPUT
Create drafts/harbor-update.txt. Keep it under 150 words.
Use three headings: Completed, Waiting on, Next step.
Below the draft, add a separate Evidence section with note IDs.
Keep that evidence section out of the client-facing draft.

PERMISSIONS
Read the named input and create the named draft.
Do not change the notes, contact anyone, or update a project board.
If the output file already exists, stop and ask before replacing it.

DONE MEANS
- Each factual sentence is supported by a note ID.
- Approved copy is not described as a completed website.
- A missing date is stated as unconfirmed, never guessed.
- Return the file path, checks performed, and any open question.

GAPS AND STOPPING
If notes conflict, flag the conflict for me to decide.
Make one draft and one check pass, then stop for my review.

Put these original sample notes in inputs/harbor-notes.txt:

H1 | 2026-09-22 | Harbor approved the homepage copy.
H2 | 2026-09-23 | The product photo is still missing.
H3 | 2026-09-24 | Layout review is booked for September 28.
H4 | 2026-09-24 | Website launch date has not been confirmed.

A suitable result would say the homepage copy is approved, the product photo is outstanding, and the layout review is September 28. It would keep the launch date unconfirmed. The Evidence section would map those statements to H1, H2, H3, and H4. Other wording can pass. Inventing a September 28 launch cannot.

How do you check the first result?

Open the actual output. Compare its claims with the four notes. Check that the source file was not changed and that the result stayed a draft. A final chat message saying "done" is a pointer to inspect the work, not the evidence itself.

Anthropic's agent design guidance emphasizes feedback from the working environment and explicit stopping conditions. For this small task, the practical version is straightforward: inspect the file, check the facts, and finish at the agreed review point.

• If a fact is wrong: name the unsupported sentence and the source that contradicts it.
• If the scope grew: make the permitted output and stopping point more explicit, and review the app's access settings.
• If the format is wrong: show one small example of the structure you want.
• If the input is incomplete: improve the input or accept a marked gap. Do not demand a complete-looking answer.

Change one part of the brief, then try again with the same notes. Save the failed output as a reminder of what the new instruction is supposed to fix. Our guide to testing an AI agent without coding expands this into a small repeatable test pack.

When should a brief become a workflow?

Reuse the brief manually until you understand the normal output and the common exceptions. If collecting the same files and running the same checks becomes the repetitive part, you have a concrete workflow to automate. You also have something to test after changing the model or adding a tool.

A longer prompt does not solve missing access, unavailable data, or a task you cannot evaluate. Keep those visible. You can delegate drafting and still own the decision about whether the result is usable.