How to Brief AI Like a Capable Junior Colleague
Ask a new hire to "write a status update for the steering committee" and most managers would stop themselves halfway through the sentence. Which project? What's changed since the last update? What does the committee actually need to decide? A capable junior colleague would either already know these things or would come back with a question. Left to guess, they'd write something generic, technically accurate and useless to the people reading it.
Type that same six-word instruction into an AI tool and most professionals don't stop themselves at all. They send it, get back something fluent and hollow, and conclude the tool isn't quite ready for real work. The instruction was too thin for a person. It was never going to be enough for a model either. The difference is that a human would have asked for more. The model just fills the silence with something plausible-sounding and moves on.
The standard already exists, it just isn't being applied
Most professionals already know how to brief someone well. They do it whenever they hand a task to a colleague who wasn't in the room when the decision was made. They explain who the work is for, what it needs to achieve, and what would make it wrong. Nobody teaches this formally. It's absorbed through years of delegating and being delegated to, and it shows up automatically whenever a human is on the receiving end.
That instinct tends to switch off the moment the recipient is an AI tool. Part of the reason is understandable: a model that can draft a competent memo in seconds feels too capable to need hand-holding. Surely something this fluent can infer the rest. It can't, not reliably, and the fluency is precisely what disguises the gap. A vague brief given to a junior colleague usually produces something that visibly misses the mark, which prompts a conversation and a correction. A vague brief given to AI produces something that reads confidently enough to slip through unchallenged, right up until it lands in front of a client or a board looking competent and carrying the wrong emphasis entirely.
Go back to the steering committee update. Which project, what phase, which risks matter right now, what the committee needs to decide, what tone suits the room this week rather than a generic one. A project manager who already knows the answers to those questions can produce a genuinely useful update in a few minutes of preparation before ever opening the AI tool: naming the project and its phase, noting that the timeline slipped two weeks because of a vendor delay, flagging one technical risk and one budget risk, specifying that the committee wants concise language and clear next steps rather than narrative, and setting a tone that's straightforward rather than reassuring because the last update was criticised for softening a hard truth. None of that takes long to write down. What comes back afterwards needs five minutes of editing rather than thirty, not because the model got smarter overnight, but because the brief finally gave it something to work with.
Five questions, not a formula
This is where the analogy to briefing a junior colleague becomes genuinely practical rather than just a nice comparison. When people delegate well to another person, they tend to cover the same handful of things almost without noticing: who this is for, what it's meant to achieve, what can't be compromised, what shouldn't be included, and roughly what shape the finished thing should take. Those five questions, audience, purpose, constraints, exclusions and format, carry almost all the weight of a good brief, whether the recipient is a graduate two weeks into the job or a language model that has never met the client.
A marketing director who kept getting flat, generic campaign briefs from AI began working through a version of this before every substantial request. Who is the brief actually for. What is the campaign supposed to achieve, specifically, not in general. What constraints genuinely limit the work, a budget ceiling, a channel restriction, a decision that's already been made elsewhere. What should the brief deliberately leave out. What should the finished piece look like. Early on, this took the form of a short paragraph she wrote before typing anything into the tool. For a product launch, that meant specifying that the brief was for two external agency partners who needed the positioning quickly, that the goal was awareness among mid-market buyers rather than enterprise leads, that budget confined the scope to digital and events, and that the brief shouldn't reopen the brand messaging, which had already been signed off. The first draft that came back needed refining rather than rebuilding.
Three months on, this had become habitual enough that she wasn't consciously running through a checklist any more, just working through the same five questions in whatever order suited the task. Her team noticed before she did: briefs were arriving faster and needing less rework, and a direct report eventually asked what she was doing differently. There wasn't a clever prompt behind it. She had simply stopped treating her input as a casual question and started treating it as a professional instruction, in the same register she'd use with a person she was trusting to get something right the first time.
The real test came when the company announced a major repositioning and her team was given ten days for work that would normally take six weeks, with two other departments competing for the same review time and no room for the quality bar to slip. She used the same five-question discipline for every brief that sprint: new positioning language, audience segment, channel constraint, what had to be dropped from the old brand, and what decisions were already settled versus still open. The volume of work didn't shrink. The proportion of it that came back usable on the first pass did.
What a good brief doesn't require
None of this calls for a longer prompt or a cleverer one. A brief that's merely comprehensive can be just as unhelpful as one that's vague, because volume without direction still leaves the model guessing which parts matter. The five questions aren't a template to fill in mechanically every time. Some tasks need all five spelled out; a quick internal note might only need one or two, because the rest is obvious from context. The habit worth building isn't reciting a checklist. It's pausing long enough, before typing anything, to ask what a capable colleague would actually need to know to do this well, and then saying that.
It's also worth being honest about what this discipline doesn't fix. A well-briefed request produces work that's aligned with what was actually needed. It doesn't guarantee every fact in the output is correct, and treating a good brief as a substitute for checking the result is its own kind of overconfidence. What changes is the starting point. Instead of correcting tone, scope and emphasis on every draft, the professional is checking substance, which is a much shorter and more useful job.
The gap between a hollow AI draft and a genuinely usable one is rarely a matter of the model's capability. It's usually the gap between an instruction and a brief, and most people already know how to close it. They've been doing it for years with everyone they've ever delegated to. The only new step is remembering to do it here too.
Anthony Velland
Interested in going further?
If the five-question briefing habit in this article sounds like the missing piece in your own AI use, AI Without Guesswork builds input design into a complete, repeatable working method rather than a one-off trick.
Ad · Amazon affiliate link.
