When you ask an agent to prepare release notes, you're probably picturing a short draft of what changed. Without a more specific brief, it may add an unmeasured speed claim, pull in a roadmap item, or offer to publish.
A task brief lets you spell out what the draft should contain, which actions are allowed, and how you'll check it. We'll build one using fictional release notes; the sample answer illustrates the requirements, not an agent run.
Start with something you can review
Before writing the brief, choose a task whose facts you understand well enough to check. Then imagine reviewing the finished work and complete this sentence: ‘When this is done, I will open or read ___ and check ___.’
If either blank is difficult to fill, narrow the job until you can describe the review. For example, ‘improve our documentation’ leaves plenty of decisions open, while ‘draft release notes from these three changelog entries for my review’ identifies the inputs and deliverable.
Copy this task brief
Copy the template below and fill in the brackets for your task. You can remove fields that genuinely do not apply, but keep permissions, uncertainty, and the stopping point explicit.
TASK
Goal: [Who needs what, and why?]
Inputs: [Exact files, records, or pasted material to use.]
Output: [Format, length, and destination.]
Allowed actions: [What the agent may read or change.]
Not allowed: [Actions needing separate approval.]
Uncertainty: [What to flag, omit, or ask about.]
Stop when: [Finished, blocked, or at a stated limit.]
Acceptance checks: [Observable conditions for approval.]
Handoff: [Deliverable, evidence, and unresolved questions.]
As you fill it in, replace vague requests like ‘make it good’ with checks you can make by reading the result: ‘include all three changes, cite their IDs, and make no unsupported performance claims.’
Use the brief for release notes
To try the template, paste these fictional inputs into an ordinary chat without connecting a repository, customer data, or publishing tools.
C1: Fixed keyboard focus escaping the settings dialog
to the page behind it.
C2: Saved filters can now be exported as CSV.
C3: Reduced repeated reads in the settings loader.
No timing measurements are recorded.
The completed brief keeps the work in chat and defines the requirements for these three entries:
Goal: Draft release notes for an internal reviewer.
Inputs: Use only changelog entries C1, C2, and C3 above.
Output: Return a draft in chat, not a saved or published
file. Use exactly three bullets, at most 150 words
in total, plus a separate Reviewer notes section.
Allowed actions: Read the supplied text and draft a reply.
Not allowed: Browse, run code, change files, contact anyone,
or publish. Do not add roadmap items.
Uncertainty: Do not invent benefits, measurements, or dates.
Describe C3 without a performance claim;
flag the missing measurements in Reviewer notes.
Stop when: Return one draft and its notes, then stop.
If any C1-C3 entry is missing or unreadable,
stop and ask for it instead of drafting.
Acceptance checks: One bullet per entry; each cites its ID.
Preserve each entry's meaning.
No speed claim, extra change, or date.
Handoff: The three bullets and Reviewer notes. Do not
claim any action beyond producing this reply.
Because the draft must cover all three changes, a missing changelog entry blocks the work. Missing timing measurements still allow a factual description of C3, so the brief tells the agent to describe that change and flag the gap without inventing a benefit.
Check the draft against the brief
With those boundaries in place, an acceptable draft could look like this:
- Fixed keyboard focus escaping the settings dialog
to the page behind it. [C1]
- Added CSV export for saved filters. [C2]
- Reduced repeated reads in the settings loader. [C3]
Reviewer notes
C3 has no timing measurements, so this draft makes
no claim about speed improvements.
When reviewing the response, follow each citation back to its entry and check that the bullet preserves the source's meaning. The wording can vary, but an added claim such as ‘settings now load twice as fast’ would fail because the inputs contain no measurements to support it. Leaving C3 out would also fail, even if the other two bullets were accurate.
Match the brief to the tools
Because a written brief cannot enforce access restrictions, you'll need to match its boundaries to the app's actual permissions. For this exercise, use a mode with tools disabled. For file-based work, restrict access through the app's controls and keep sending or publishing disabled until needed and approved. If the app cannot enforce the boundary you need, keep sensitive material out of the task.
If a task involves writing files, the brief should also explain what happens when a tool fails. You might allow one retry after a temporary error, then require a blocker report. If the outcome of an action is uncertain, check whether it already happened before retrying; repeating a send or write can create duplicates.
Review what actually happened
Even with a clear brief, an agent can misunderstand or ignore an instruction, or run into a tool it cannot use. Your review therefore needs to cover both what it produced and what it claims to have done. If a later task asks for a saved file, open it to confirm that it exists and contains the expected work; a message saying ‘saved’ does not establish either.
Keeping the brief with your review notes makes it easier to spot whether a failure came from a missing input, an unclear rule, a permission problem, or incorrect execution. You can then change the relevant part for the next attempt, without treating one satisfactory result as proof that the model is reliable across other tasks.
Source and disclosure
Adapted from AI Agent Task Brief: A Template for Clear Delegation.
AI assisted the drafting and editing of this article. The changelog entries and sample answer are fictional, and the sample illustrates the acceptance checks rather than reporting an agent run.
Top comments (0)