Guide · AI employees
Write an AI Task Brief Someone Could Actually Work From
A practical brief for AI-assisted work, with an example covering the audience, approved facts, deliverables, and review decisions.
"Write some posts about our new service" leaves a lot of room for guessing. Which service? Who needs it? What can you promise? A useful AI brief answers the questions you'd expect from a capable colleague. It can be short, but it has to contain the decisions that shape the work.
Begin with the situation
Describe what prompted the request. Perhaps customers keep asking whether your installation service includes training. Perhaps a launch email earned replies that revealed confusion about the offer. That context tells the writer what needs explaining.
Then name one audience and one next action. An existing customer considering an add-on needs different information from someone who has never heard of the company. If both groups matter, write separate versions instead of asking a single paragraph to satisfy everyone.
Give facts somewhere to live
Attach the current offer description, the relevant product page, and any approved examples. Identify which source wins when they disagree. An old sales deck and a newer pricing page can send a writer in different directions unless you settle that conflict.
Keep factual inputs separate from style references. You might like the pacing of another company's email without wanting its claims, features, or pricing copied into yours. Say what the reference is for. Ask the writer to list missing facts rather than fill gaps with plausible details.
A brief you could send today
Here's a hypothetical brief for a business that installs scheduling software. It illustrates the level of detail, not an offer from DevLaunch.
"Draft an email to existing customers who already use our booking page. Explain that the optional training session covers staff setup and handling a rescheduled appointment. Use the attached service sheet as the source of truth. The goal is a reply requesting the training outline. Keep the body under 250 words. Do not include pricing because the quote depends on team size. Return one subject line, one preheader, the email, and any questions you couldn't resolve. Save a draft for review."
Notice what the brief settles: audience, facts, purpose, length, output, and permission. It still leaves room for the writer to choose an opening and organize the explanation. You don't need to dictate every sentence to get a useful result.
Define what you'll review
"Make it sound better" is difficult feedback to act on. Give the writer a few standards ahead of time. The recipient should understand who the service is for, what the session covers, and how to request details. Every factual claim should be traceable to the service sheet.
If the first version gets the audience wrong, fix that before polishing individual words. A friendly sentence aimed at the wrong person is still the wrong sentence. Review the work in the same order a reader encounters it: relevance, explanation, evidence, and next step.
Keep the brief with the finished work
Store the approved brief beside the final draft and the source material used to write it. Later, someone may need to explain why a price was omitted or where a feature claim came from. The brief should answer those questions without a search through a long chat history.
When the request changes, revise the brief explicitly. A new audience, offer, or destination is a new decision, even if the text change looks small. Keeping that record makes the next assignment easier and gives your team a useful starting point for recurring work.