Give AI the Same Brief You Would a New Joiner
Think about what happens when a capable new consultant joins a project. They are bright, experienced, and eager to help. But it takes a few days or weeks before they become useful — because it takes time to understand what matters: who the client is, what has already been decided, where the project is heading, and what “good” looks like here.
So you brief them. You explain the background, point them to the decisions that have been made, flag the things still up in the air, and tell them what to watch out for. The better the brief, the sooner they start producing work you can rely on.
Artificial intelligence is no different. The quality of what it produces depends almost entirely on the quality of the brief it is working from. And yet most people give AI far less context than they would ever give a new colleague — then wonder why the output is generic, off-target, or altogether wrong.
This is the heart of what has come to be called context engineering. It is one of the most practical skills in AI-assisted work, and one of the easiest to overlook.
- AI needs a proper brief — just like a new joiner. Without context, it fills gaps with plausible-sounding guesses that can be confidently wrong.
- Context engineering is the skill of giving AI the right information, not everything. Relevance beats volume.
- A good context pack covers the goal, background, people, rules, risks, definitions, and sources — clearly separating facts from assumptions.
- More information is not better information. Outdated or contradictory context makes AI output worse, not safer.
- AI can help build a context pack from raw materials — but it must not invent context. Always ask it to separate facts from assumptions and show its sources.
Why weak context makes AI fail like a badly briefed joiner
Give a new joiner a login and a vague instruction to “have a look and see what you can do,” and you will wait a long time for anything useful. They will guess. Some guesses will be reasonable. Others will be confidently wrong — because they have no way of knowing what they do not know.
AI behaves in exactly this way. Unlike a person, it won’t stop and ask. It fills the gap with the most plausible-sounding answer it can generate. That answer often reads well, which makes it more dangerous, not less. You’ll get a polished paragraph referencing a decision that was never made, or a recommendation built on an assumption nobody checked.
When AI output disappoints, the instinct is to blame the prompt and try again with different words. Usually the prompt was fine. The real problem was upstream: the AI never had the information it needed to do the job well.
Context engineering is just good onboarding for AI
Context engineering is the deliberate work of giving AI the right information, in a form it can actually use, so that it produces relevant and reliable output. In mid-2025, Shopify CEO Tobi Lütke argued for it over “prompt engineering”:
“I really like the term ‘context engineering’ over prompt engineering. It describes the core skill better: the art of providing all the context for the task to be plausibly solvable by the LLM.”Tobi Lütke · CEO, Shopify
Andrej Karpathy, a founding member of OpenAI and former AI director at Tesla, added his own definition — which has become the most often quoted:
“Context engineering is the delicate art and science of filling the context window with just the right information for the next step.”Andrej Karpathy · Founding Member, OpenAI
The phrase “just the right information” is the whole point. Not everything. The right things. There are two common ways people get this wrong. The first is the document dump — “Everything you need is in the shared drive” — technically true, useless in practice. The second is the opposite: a one-line prompt asking for complex work with none of the background needed to do it well. Good context engineering sits between the two.
What a good AI brief actually contains
A useful brief for AI looks a lot like a useful brief for a person. For most non-trivial work, it covers:
- 1The goal
What we are trying to produce, and what decision it will support.
- 2The background
The client, the project, and how we got to where we are.
- 3The people and systems
Who the users are, what the work touches, what it connects to.
- 4The rules and constraints
Business rules, technical limits, standards, and anything non-negotiable.
- 5The risks and open questions
What we are unsure about, and what could go wrong.
- 6The definitions
Terms and acronyms that mean something specific in this context.
- 7The sources
Where this information came from, so it can be checked.
Pulled together, this is sometimes called a context pack. It is not bureaucracy for its own sake — it is the difference between AI guessing and AI working from the same understanding the team already shares.
Choose the right information, not all of it
The instinct to give AI “everything, just in case” is understandable but counterproductive. More context is not better context. Irrelevant, outdated, or contradictory information makes the output worse, not safer.
Relevance beats volume.
A clear, organised brief outperforms a pile of attachments.
Two architecture documents from different quarters that disagree will not tell the AI which one is current. You have to resolve that before handing it over.
Context is not a one-time setup. A brief that was accurate two months ago can quietly mislead today.
This is ordinary professional judgment — the same editing you would do before handing a summary to a colleague. AI simply makes the cost of skipping it more visible.
Mark what is fact, what is a decision, and what is an assumption
This is the single most important discipline in context engineering, and the one most often missed. When you brief a person, they naturally hold these distinctions in their head. They know the difference between “this is confirmed,” “we decided this in the last steering committee,” and “I think this is probably the case but I’m not certain.” AI does not make these distinctions unless you make them for it. Left to itself, it treats a casual assumption with the same confidence as a hard fact.
Every piece of context should be either sourced, validated, or clearly marked as an assumption. That rule is the safety net — it is what stops a tentative guess from hardening, three steps later, into something that looks like settled fact.
AI can help build the context, but it must not invent it
There is a useful twist here. AI is not only something you give context to — it is also a tool for building that context in the first place. Hand AI your workshop notes, meeting transcripts, or a stack of old requirements documents, and it can do a genuinely helpful first pass: extracting the goal, the background, the business rules, the risks, and the definitions into a structured brief. Work that used to take an afternoon of reading and note-taking can become a draft you refine in minutes.
But the same rule applies — and it matters more here than anywhere else: AI must not invent context. When it pulls a brief together, it should separate what it found in the source material from what it inferred. Asking it directly — “separate the facts from the assumptions, and show me your sources” — turns a risky shortcut into a safe one. The consultant still owns the final brief. AI just gets it most of the way there.
What briefing AI well asks of consultants and leaders
Context engineering raises the value of something consultants already do well: understand a situation deeply enough to explain it clearly. The skill of briefing AI well is, at its core, the skill of knowing your project well — what matters, what is settled, what is still uncertain, and what could go wrong.
For leaders, the real implication is that good context is worth investing in. The teams getting the most from AI are not the ones with the cleverest prompts. They are the ones who treat context as something to be built, maintained, and shared — a current, trustworthy brief that any person, or any AI, can work from.
AI does not remove the need for judgment. It moves that judgment slightly upstream — into deciding what the work needs to know, and being honest about what we are still not sure of. That was always the job. AI just makes it harder to skip.
Build AI capability into your team
If you are thinking about how to bring AI-assisted ways of working to your organisation — from context engineering to full AI Agents and AI-Powered Solutions — we would be glad to talk.
Get in touch with SaratogaContext engineering is the deliberate work of giving an AI system the right information, structured in a way it can use, so that it produces relevant and reliable output. In practice it means briefing AI the way you would brief a capable new colleague: the goal, the background, the rules, the risks, and what you are still unsure about.
Prompt engineering focuses on how you phrase a single instruction — the wording, structure, and format of a request. Context engineering is broader: it is about what the AI knows before it sees the prompt. The best-worded request will still produce poor output if the AI is missing the background, rules, and constraints the work depends on.
A context pack covers: the goal and what decision it will support; the background and how the project reached its current state; the people and systems involved; the rules and constraints that are non-negotiable; known risks and open questions; definitions of terms specific to this context; and the sources that can be checked. The key discipline is to clearly mark what is a confirmed fact, what is a team decision, and what is an assumption still to be validated.
Yes — but with an important caveat. AI can do a helpful first pass when given raw material: workshop notes, meeting transcripts, requirements documents. It can extract goals, background, rules, risks, and definitions into a structured brief. What it must not do is invent context that is not in the source material. Asking it to “separate the facts from the assumptions, and show me your sources” is the safeguard that keeps this approach safe.
