A manager asks an AI assistant to “prepare a supplier comparison.” The assistant produces an attractive table. One reader expects a shortlist, another wants every offer included, and a third assumes the prices have been checked against current quotations.
The output may look finished while the task remains undefined. Before improving the wording of the prompt, settle what a useful result must contain and what a reviewer must be able to verify.
A short AI task brief makes those expectations explicit. It is especially useful when work passes between a manager, a colleague and an assistant, or when the same task will be repeated. Its value is the agreement it creates about the work, not the number of instructions it contains.
Start with the business use of the output
My AI for Business workshop material introduces prompting through a clear task, relevant context, a defined output and reference material. It also treats prompting as iterative. The task brief below is a practical extension of those principles, not a separate standard or a guarantee of accurate output.
Start by completing this sentence: “The recipient needs this output so they can…”
“Compare suppliers” could mean selecting candidates for a demonstration, preparing questions for a negotiation or recommending a purchase. Those are different assignments. They require different evidence and different authority.
Describe one immediate use. If the purpose is to prepare a shortlist for a discussion, say that explicitly. Do not quietly turn a research assignment into permission to contact suppliers, commit funds or make the final choice.
Write five parts of the brief
The following structure is a lightweight working aid. Use more detail where the consequences justify it, and less for a low-risk, one-off task.
- Purpose and recipient. State who will use the result, for which decision or next step. Identify the question that the output must answer.
- Inputs and boundaries. Name the approved sources, versions and relevant period. State what is unavailable, excluded or not authorised for use. Access to a file does not automatically make it appropriate to include its contents in the deliverable.
- Deliverable. Specify the form and essential contents. A comparison table, a draft response and an approved recommendation are different outputs. Describe which one you want.
- Acceptance checks. Define observable conditions for accepting the work. Replace “make it accurate and comprehensive” with checks a person can perform, such as tracing every quoted price to an offer and listing the offers not received.
- Review and exceptions. Identify who accepts the result and what should happen if evidence is missing or conflicting. Specify whether the assistant should return a partial result, ask a focused question or stop that part of the task.
The fifth part prevents a common ambiguity: an assistant can finish processing the available material without completing the business assignment. “Processed all supplied files” and “ready for a purchase decision” should remain separate statuses.
An illustrative supplier-comparison brief
The example below is hypothetical. It demonstrates the structure, not a recommendation about a real supplier or purchasing decision.
Purpose: Prepare a comparison for the operations manager to decide which suppliers should attend a clarification call. Do not recommend a purchase yet.
Inputs: Use only the three quotations supplied for this request. Keep their dates and validity periods visible. Do not use remembered prices or fill missing terms from unrelated offers.
Deliverable: A comparison of scope, exclusions, stated price and currency, delivery timing, quotation validity and questions requiring clarification. Include a source reference beside each material fact.
Acceptance checks: Every received quotation is represented. Different currencies remain clearly labelled. Items with different scope are not treated as equivalent. Missing tax, delivery or support terms are marked “not stated,” rather than assumed to be included. No supplier is described as cheapest on a like-for-like basis unless that comparison is actually supported.
Review and exceptions: The operations manager reviews the comparison before it is circulated. Conflicting figures are listed with both sources. The assistant may prepare questions, but must not send them or contact a supplier.
A brief like this gives the reviewer specific reasons to accept, revise or reject the result. It also reduces the temptation to judge a response mainly by how polished it looks.
Check the task before adding more instructions
If the assistant repeatedly fails, inspect the failure rather than making the prompt longer by default.
A missing input calls for obtaining the input or narrowing the claim. An ambiguous business rule needs a decision from its owner. A calculation that must be exact may need a deterministic calculation step. A confusing output format may need a clearer example. These problems should not all be treated as wording problems.
For recurring work, record the failure and the change made to the brief. Keep the version that a reviewer accepted. If the purpose, sources or permitted actions change, review the brief again instead of assuming an earlier approval still applies.
This is also where task design connects to choosing the appropriate degree of automation. The question explored in AI Agent or Workflow? Match Autonomy to the Task becomes easier to answer once the task’s inputs, exceptions and permitted actions are visible.
Make “done” a reviewer decision
A useful completion note can be short: what was produced, which inputs were used, which checks passed and what remains unresolved. The reviewer then decides whether the result is suitable for its intended use.
Keep that review proportionate. A draft agenda and a high-consequence recommendation should not require identical evidence. Where the work affects people, money or important commitments, involve the relevant decision-maker and apply the organisation’s existing controls. A task brief does not replace them.
The approach is consistent with the NIST AI RMF Playbook’s MAP 1.1 guidance on documenting purpose, context, user expectations and requirements. NIST addresses AI-system context more broadly; the five-part brief here is an applied working method, not a NIST-prescribed template. See the NIST AI RMF Playbook: Map.
Try it on one recurring task
Choose a task whose output regularly comes back for clarification. Ask the person who uses it to write the acceptance checks before anyone rewrites the prompt. Then try the brief on an authorised example and compare the result with those checks.
The first benefit to look for is less ambiguity: fewer hidden assumptions, clearer exceptions and a shared understanding of what still needs human judgment. To assess business value beyond that, track the relevant outcome, as discussed in AI Value Measurement: Turn Time Saved into Business Results.
If you need to clarify where AI should assist, where people should decide and how to define an acceptable result, you can schedule a consultation.