What to Give AI Before You Ask

Generic output is almost always a context problem, not a prompt problem.

A model with nothing specific to work from produces the average of what has been written on the subject. That is not a flaw to be worked around with better phrasing — it is the correct behaviour given no information.

The fix is a context file: one document, written once, pasted at the start of any task. An afternoon of work that improves everything afterwards, and the single highest-return thing available in this subject.

---

The six sections

In order of how much each one changes the output.

1. Customer language

The most valuable section by a wide margin, and the one most people cannot fill in.

What goes in it: the exact words customers use about their problem, your product, and their objections. Verbatim, not paraphrased — the paraphrase is where the specificity dies.

Where to get it:

• Support tickets and email replies. The largest source and the least read
• Sales call notes — particularly the objections
• Reviews, including the ones about competitors
• Survey free-text answers
• The questions you get asked twice a week

If you cannot fill this section, that is the finding. A business that has not written down how its customers describe their problem has a bigger gap than an AI workflow gap — and filling it improves the writing you do by hand too. Extracting it at volume.

What it changes: everything. A model writing with real customer phrasing produces work that sounds like it was written by somebody who has spoken to them, because in a sense it was.

2. What you actually do

Specific, concrete, and unflattering where necessary.

• What the product is and is not
• What it costs and what that includes
• Who it suits and who it does not
• What it will not do

The "does not" items matter more than the features, because they are what keeps generated copy from overclaiming. A model with no limits stated will state no limits.

3. Positioning

Not a mission statement. The actual claim.

• What makes you different, in one sentence you could defend
• Who the realistic alternatives are, including doing nothing
• Why somebody chooses you over each

One sentence you could defend is the constraint that makes this useful. Anything longer is a paragraph of aspiration.

4. Voice specification

Examples, exclusions, structural rules. Kept in the context file rather than retyped per task. How to build it.

5. Standing constraints

The rules that apply to everything you publish.

• Claims you will not make
• Figures you have decided not to state and why
• Terminology you use consistently — and the variants you have banned
• Compliance or disclosure requirements that apply to you

The terminology item is worth its own note. Naming things consistently matters for both readers and machine retrieval, and drift is what happens without a list. If your book is The Email Deliverability Playbook, that string appears everywhere — not "the Playbook", not "the deliverability book".

6. Verified facts

A running list of claims you have already checked, with their primary source and the date.

On a site covering a coherent subject the same twenty or so facts recur constantly. Checking each once rather than per-article is the largest available saving in the one stage that resists scaling. And pasting them in means the model has the real figures rather than reaching for plausible ones. Why the register pays.

---

What not to put in it

Four things that add length without adding information.

Your mission statement. It describes an aspiration, not a fact about the work.

Adjective lists. "Innovative, customer-focused, reliable." Every business claims these, so they narrow nothing.

Anything you are unsure about. A wrong fact in the context file propagates into everything generated from it, which is worse than an absent one.

Everything. A context file long enough to feel comprehensive stops being pasted. Keep it to what changes output, and split it if a task needs only part.

---

Practical assembly

Two to three hours, once.

1. Open your support inbox and pull fifty customer messages. Extract the recurring questions in the customers' own words
2. Write what the product is and is not, including the limits
3. Write the positioning sentence. Rewrite it until you could defend it
4. Assemble the voice specification — three to five examples, the never-do list, three structural rules
5. List your standing constraints and your consistent terminology
6. Start the verified facts list with the ten claims you make most often, each with its primary source

Then use it. The file improves through use rather than through more drafting — a gap becomes obvious the first time a task falls into it.

---

Keeping it current

Three habits, none of them onerous.

Add customer language continuously. Every time a customer phrases something well, paste it in. Two minutes, and it is the section that compounds.

Add a verified fact every time you check one. With the source and the date.

Review quarterly for things that stopped being true. Prices, features, positioning, and anything dated. A stale context file is worse than none, because it produces confident wrong output at volume — the same failure mode as a stale automation, and just as silent. Why silent failures are the expensive ones.

---

Frequently asked questions

Why is my AI output so generic?
Because it was given nothing specific to work from. A model with no context produces the average of what has been written, which is the correct behaviour given no information. The fix is supplied material — customer language, product specifics, real examples — not better phrasing.

What is a context file?
One document containing what a model needs to write as you: customer language verbatim, what you actually do and do not do, your positioning claim, your voice specification, standing constraints, and facts you have already verified. Written once, pasted at the start of any task.

What is the most important thing to include?
Customer language, verbatim rather than paraphrased. It is what makes output sound like it was written by somebody who has spoken to your customers. If you cannot fill that section, the gap is bigger than an AI workflow problem and filling it improves your hand-written work too.

How long should a context file be?
Short enough that you keep pasting it. A file long enough to feel comprehensive stops being used, so include only what changes the output and split it if a particular task needs one part.

Should I include my mission statement?
No. It describes an aspiration rather than a fact about the work, and aspiration statements narrow nothing — which means they occupy space without changing what gets written. The same applies to adjective lists every business could claim.

How do I keep a context file current?
Add customer language whenever a customer phrases something well, add each fact as you verify it with its source and date, and review quarterly for anything that stopped being true. A stale context file produces confident wrong output at volume, which is worse than having none.