AI Brief

What an AI Brief is

An AI brief is the context you give an AI tool before it starts, set out the way a new hire’s brief would be. It is the difference between telling a tool what to do and telling it what it needs to know to do it well.

The briefing article opens with the point the whole term rests on. Bad AI output is rarely a wording problem. It is a missing-context problem, and the fix looks exactly like the one you would reach for with a new hire: brief it, do not just instruct it.

This page covers the evidence behind that claim, what a brief contains, why a bare prompt fails, and how a team keeps the habit once the novelty of a tool has gone.

The New hire gets a brief, the AI usually gets a sentence

Nobody hands a new hire one line, such as “write the client update”, and expects a usable draft. They are told who reads it, roughly how long it should run, what last month’s version looked like and what the boss does not want to see. The article says none of that is generosity. It is the minimum a stranger to the task needs to do it without guessing.

A new hire given only the one line would produce exactly the generic, slightly wrong draft that a bare prompt produces from an AI tool. The prompt page makes the same point with the same example: a new hire given only that line would guess, and so would an AI tool.

The instinct with AI tools has been to fix this by rewording, with sharper verbs and cleverer phrasing. The article says that treats the problem as one of language, and that it is not.

What the study found

The article cites a study of 200 documented AI interactions across four tools. It found that when people assembled structured context before prompting, and not after a bad first attempt, first-pass acceptance rose from 32% to 55%. The average number of iteration cycles needed to reach a usable result fell from 3.8 to 2.0.

The figure the site’s definition uses is the third one. Incomplete context, not poor wording, was linked to 72% of the iteration cycles in that data. The article’s reading is that the wording was rarely the thing that needed fixing, and that the people who improved their results did so by changing what surrounded the request and not the request itself.

Two limits are worth stating. The study is 200 interactions, so it describes a pattern and does not guarantee a result for any one business. And the figures are about acceptance and iteration, not about accuracy, so a well-briefed answer still needs a person to check it. The human in the loop page covers that check.

Why wording was never the Real problem

The article explains why a bare prompt fails. It is not that the large language model cannot parse the sentence. It is that the sentence does not contain enough of the decision the requester already made in their own head before typing it. A person asking for the client update already knows which client, what tone that client expects, roughly how long the last one ran and what a rejected version looked like. None of that reaches the model unless it is written down.

A model with no access to what is inside someone’s head can only produce the statistically likely answer to the words it was given. That is what a generic or hallucinated answer looks like from outside. The article says it is not the model inventing nonsense at random but filling in, plausibly, exactly the part nobody specified.

This is also why rewording rarely fixes it alone. A sharper verb changes how the instruction reads, not what the model knows about the audience, the history or the standard the result will be judged against. Two people can type nearly the same sentence into the same tool and get very different results, because one has built the surrounding habits, such as custom instructions or a prompt library, and the other starts from a blank line every time.

The six things a brief covers

The article names six things that do most of the work, each with a direct new-hire equivalent.

Role. What job the AI is doing right now: drafting, summarising or analysing. The same as telling a new hire whether they are producing a first draft or a final one.

Goal. The actual deliverable, who reads it and roughly how long it should be. “Write something” and “write a three-paragraph update for a client who reads on their phone” produce different drafts even from the same person.

Context. What a new hire would need on day one that nobody thinks to say out loud: the audience, the history and the constraint everyone in the room already knows. The article says this is the section most prompts skip, because it feels obvious to the person who already has it.

Constraints. What to avoid, such as house style, tone or a client that dislikes being sold to. A constraint stated once is cheaper than the same mistake corrected on every draft.

Examples. One reference piece of good work, exactly like showing a new starter a strong past example. A description of quality is always vaguer than a real instance of it.

Success criteria. How the output will be judged, stated before the work starts and not decided afterwards when the draft exists. Deciding the bar after seeing the result is how a reasonable first draft gets rejected for a reason nobody mentioned.

What goes wrong when one is missing

The article says the pattern is usually recognisable. A role with no goal produces confident work aimed at the wrong reader. A goal with no constraints produces something usable that still needs a tone pass. Constraints with no example produce something that technically obeys every rule and still does not read right, because “no jargon” and “here is what it should sound like” are not the same instruction.

The small business article gives the shortest version of the same advice. It says the people who get usable first results are the ones who brief the tool like a new hire: with context, an example and a clear standard. It also says the tool does what it is told, so tell it who the output is for, what it should contain, what to leave out and what a good example looks like.

A worked example

This is an illustration, not a real client. A small business asks an assistant to “write the monthly client update”. The first draft is generic, too long and aimed at no one in particular. The person rewords the request twice and gets two more drafts that read slightly differently and are still wrong in the same way.

On the next attempt they write a brief. The role is a first draft for a manager to review. The goal is a short update on this month’s progress for a client who reads on a phone. The context is who the client is and what last month’s version said. The constraint is no jargon and no promises about dates. The example is last month’s update, which the client liked. The success criterion is that every figure matches the attached meeting notes. The task is identical. The result needs one edit, not three, and the manager has a standard to check it against.

Context Engineering and Prompt Engineering

The article says the distinction has picked up a name of its own, context engineering, which sits alongside prompt engineering and does not replace it. Prompt engineering is still real and useful, in the same way that phrasing an instruction to a new hire clearly still matters. A muddled sentence produces a muddled answer whatever surrounds it.

But a beautifully worded instruction with nothing else attached still leaves a stranger to the task guessing at the parts that were never said out loud, and a plainly worded one with the right material attached usually does not. If there is time to improve only one thing, the article’s answer is the context.

The standing half and the task half

A brief has two halves, and the article says they do different jobs. Custom instructions are the standing half: the rules that apply to every request, set once, such as tone, house style and what the business never wants. The brief is the task-specific half: what this particular deliverable needs that the standing rules cannot know in advance, such as who reads it this time or what last week’s version looked like.

A team that sets good custom instructions still needs to brief the one-off task properly. The two together mean a person only has to brief the part that is genuinely new each time, the way a well-run team’s onboarding covers house style once and never makes a returning employee re-explain it.

From a skill to a habit

Writing six lines into every request gets tedious, which is why a new hire’s induction is written down once and not repeated from memory every morning. The article says the same move works here. A prompt library of briefs that already cleared the bar, reused and not rewritten, turns the skill someone has to remember into a resource someone can open. The prompt library page says the same: a library of briefs that cleared the bar once turns the skill into a resource.

The site’s meaning follows: a small, reused set of briefs beats writing a fresh one from memory every time, and it keeps the standard when the tool changes.

The article draws a further distinction between an individual skill and a team habit. A person who has learned to write good prompts carries that to the next tool and the next job. The rest of the team does not automatically inherit it, and the same missing-context problem returns with the next hire, the next tool or the next task nobody has briefed properly. A team taught to assemble a brief, and given a shared starting set that already works, keeps the standard when the model changes, because the habit was never about one tool.

Training the team

The article points to the site’s courses for this reason. The courses on the art of prompting and on personalisation are built around the idea that the skill that survives a tool change is the briefing habit, not the phrasing that happened to work last month. The article adds that editorial and writing teams working from a fixed house style see this most clearly, which is why a bespoke session built around exactly that spends most of its time on the brief a document needs before anyone touches wording.

At team level the same logic applies before a training day. How to brief a team on AI covers the version that happens once, so people arrive with a real task. The site’s bespoke in-house training page covers building briefs around a team’s own work.

Mix-ups worth avoiding

Four confusions come up often enough to name. The first is treating a disappointing answer as proof the tool needs better wording, when the request was missing something a stranger would have needed. The second is writing a fresh brief from memory every time, when a reused set keeps the standard. The third is briefing without a success criterion, so the bar is decided after the draft exists. The fourth is treating a good brief as a guarantee of accuracy, when a person still has to check the result.

How we use it

The briefing article treats briefing as a habit and not a wording trick. Stop treating a disappointing answer as a wording problem, write the next request as a six-part brief and not a sentence, keep the ones that work, and notice whether the gap closes on the first attempt and not the third. See how to brief an AI tool like a new hire for the full argument, and the prompt page for the instruction itself. If nobody on your team briefs AI tools this way yet, a discovery call is a quick way to find out where the gap is.

Sources

• How to brief an AI tool like you would brief a new hire: the study, the six things, the new-hire comparison, the standing and task halves and the team habit.
• Which AI tasks should a small business start with first?: briefing with context, an example and a clear standard.
• Prompt, prompt engineering and prompt library: the four-part request, context engineering and a reused set of briefs.
• How to brief a team on AI: briefing the team once before training.