Context and Constraints
Context Is the Information Only You Have
The model has broad general knowledge and zero knowledge of your situation. Context is where you close that gap, and the useful test is simple: what would a capable freelancer need to know before starting this task? Usually it is the same short list. The background — what happened before this, why the task exists. The people — who is involved and what the relationship is like. The history — what has already been tried, and what went badly. The stakes — what happens if this is wrong. None of that is available anywhere else. Every minute you spend supplying it is worth roughly five minutes of rewriting the output afterwards.
- Background: how the situation arose and why the task matters now
- Relationships: who is involved and how much political care is required
- What has already been tried and rejected — this alone prevents a lot of wasted output
- Stakes: what happens if the answer is wrong, so effort lands in the right place
Constraints Are What Make an Answer Usable
Constraints are the boundaries the answer must respect, and they are the difference between a plausible answer and a usable one. Weak: "Suggest ideas for our team offsite." Strong: "Suggest ideas for a one-day team offsite. Constraints: eleven people, four of whom are remote and joining by video for part of it; budget under 2,000; one person uses a wheelchair; no alcohol-centred activities; must include one hour of actual planning work. Give six options, each with a one-line reason it fits these constraints." The second version cannot produce the useless suggestions the first one will, because you removed them in advance. Most people supply constraints only after seeing a bad answer. Supplying them first is the whole trick.
- Weak: "Suggest ideas for our team offsite"
- Strong: adds headcount, budget, accessibility, format and a required outcome
- Constraints eliminate whole categories of bad answers before they are generated
- Ask for a stated reason each option fits the constraints — it makes checking fast
Say What Is Out of Scope
One constraint deserves its own mention because people forget it constantly: what you do not want covered. AI outputs sprawl by default. Ask about a pricing change and you will get sections on market research, competitor analysis and communication strategy that you did not ask for and will delete. Naming the boundary is quick. "Only cover the internal finance impact — I already have the customer communications handled." "Assume the technology decision is fixed and do not revisit it." "No legal advice, we have counsel for that." Scope boundaries also do something subtler: they stop the answer from being diluted across five topics when you needed depth on one.
- Sprawl is the default; boundaries are cheap to state and rarely stated
- "Assume X is already decided" prevents the model reopening settled questions
- Narrow scope produces depth; broad scope produces a shallow tour
- If you keep deleting the same section from outputs, put it in the prompt as out of scope
Prefer slides, quizzes, and saved progress? Read this lesson in the library — free, no sign-up.