Brief AI like a new hire.
Picture a new hire on their second day. You ask them to "draft a reply to the Henderson complaint," and they come back with something polite and slightly wrong. They had no way of knowing that Henderson has been a client for nine years or that this is the third complaint this quarter. Nobody would blame the new hire for that. Most people blame the AI when the same thing happens to them.
The gap is context.
When someone types a one-line request into an AI tool and gets a bland answer back, the usual conclusion is that the tool isn't very good. Sometimes that's true. More often the tool did a reasonable job with what it was given, which was almost nothing. It had no idea who would read the answer or what the person asking would count as done.
A capable person who joined your team yesterday is in the same position. They can write, summarize and reason perfectly well. What they lack is everything you carry around in your head about this client, this report, this board, this town council. The model starts every conversation that way unless you tell it otherwise.
You already know how to do this.
Anyone who has managed people has given a good handoff and a bad one, and has seen the difference in what came back. The good handoff explained why the work mattered, who would read it, what to avoid and what a finished version looked like. The bad one was a sentence in a hallway.
Writing a good prompt is the same skill as handing off work well, and most managers learned it years ago.
That's useful news for the people in your organization who feel behind on AI. The office manager who trains every seasonal temp, or the program director who writes clear assignments for volunteers, already has the habit that matters most. They just haven't been told it transfers. Much of what gets sold as prompt technique is ordinary delegation with a new audience.
What a new hire needs to hear.
Think about what you'd say to a sharp new colleague before giving them a task you care about. It tends to fall into five parts.
First comes the background: what's going on, what has already happened and any documents they should look at. Then the goal, meaning the decision or action this piece of work is supposed to produce, which is often different from the task itself. A summary of a contract exists so someone can decide whether to sign it, and knowing that changes what goes in the summary.
The audience shapes tone, length and vocabulary more than anything else. A grant report for a foundation officer and the same facts for a school board read very differently. Constraints are the things that would make a technically good answer unusable: a word limit, a policy, a phrase legal won't allow, a deadline, a format the receiving system needs.
Last, and most often skipped, is what good looks like. An example of a past version you liked does more than any adjective. If you don't have one, describe the finished thing in plain terms: one page, three options, a recommendation at the top.
Treat the first answer as a draft.
A new hire's first draft is a chance to find out what you forgot to say. The same goes for a model. When the answer misses, the useful question is what it would have needed to know to get it right. Usually the answer is a fact you took for granted. Add it and ask again.
This is also where people learn the most about their own work. Writing down what good looks like for a monthly report forces a decision that may never have been made out loud. Say a clinic's operations lead sits down to brief a tool on the weekly staffing summary and realizes she can't say who reads it or why. Nobody had decided, and that gap would be worth closing even if no AI tool were involved.
It also helps to ask the model to ask you questions before it starts. A line like "before you draft anything, tell me what you'd need to know to do this well" turns a guess into a short interview. It catches the missing background before you've spent time reading a wrong draft.
Keep the briefs that work.
Once a brief produces a result you'd use, save it. A brief for the intake email, the board memo or the vendor comparison is a small asset, and the second time you use it most of the thinking is already done. Keep it somewhere the team can find it, with a note on when it was last checked against real output.
A five-part briefing template
Copy this into a note and fill it in before your next request. Not every task needs every part, but it's worth deciding to skip one rather than forgetting it.
- Context. What's going on, what has happened so far, and what material to read. Paste or attach the documents themselves.
- Goal. What this work is for: the decision, action or conversation it should make possible.
- Audience. Who will read or use the result, what they already know, and what tone they expect.
- Constraints. Length, format, deadlines, policies, words to avoid, and anything that must not be invented or assumed.
- What good looks like. A past example you liked, or a plain description of the finished thing. End with: "Before you start, ask me anything you'd need to know."
