Twelve reasons your AI gives generic answers, and what to do about each one

First, the thing that is almost always true

A model is answering from what it was given. When the answer is generic, the input was generic. That sounds glib, so here is the useful version: the input includes the instructions, the reference material, the examples and the structure of the request, and a gap in any one of them gets filled with the average of everything the model has ever read.

The average of everything ever written about plumbing is a brochure about plumbing. That is what generic means. It is not a failure to try harder. It is the correct output for an underspecified question.

1. It does not know anything about your business

The most common cause by a distance. The system was given a role and a task but no facts, so it is writing about a category of business rather than yours.

You can tell because the output would be true of any competitor. Swap your name for theirs and nothing breaks.

• Symptom: the copy describes the industry, not the company. Nothing in it could be checked against reality.
• Cause: no source material. The system is working from the request alone.
• Fix: give it the facts before you ask for the writing. Who you serve, what you actually do, what you refuse, what goes wrong, how you differ from the shop down the road. This is what a context sheet is for.

2. The instruction says what to avoid instead of what to do

Prohibitions are much weaker than descriptions. "Do not be generic", "avoid marketing speak" and "no fluff" all name the failure without naming the target, which leaves the system guessing at what you actually want.

Worse, a long list of prohibitions tends to produce cautious, hedged writing, because the system is optimising for not tripping a rule rather than for being useful.

• Symptom: the output is inoffensive and says nothing. It reads like it is trying not to be wrong.
• Cause: an instruction made of negatives.
• Fix: describe the thing you want. Not "avoid jargon" but "write the way you would explain it to a customer standing at the counter". One positive description beats five prohibitions.

3. There are no examples, or the examples are all the same

Examples are the strongest signal you can give. They out-weigh instructions, which is why one example of the wrong thing will quietly undo a paragraph of correct guidance.

A single example is worse than none in one specific way: the system copies its length, its structure and its rhythm, not just its quality. If you show one gold-standard answer, you get that answer's shape forever.

• Symptom: every output has an identical structure, or matches one sample suspiciously closely.
• Cause: one example, or several examples that are all built the same way.
• Fix: give three or four deliberately varied examples. Different lengths, different openings, different shapes. Label them as illustrations of quality rather than templates.

4. Nobody defined who the reader is

Writing changes completely depending on who is reading it. Without a reader, a system defaults to the safest possible audience, which is nobody in particular.

This is the difference between "our team of experts delivers tailored solutions" and "if your dishwasher is backing up into the sink, that is usually the drain hose, and it is a ten minute job".

5. It was never told what the output is for

A system that does not know where the text is going cannot make the decisions that matter about length, format and tone. A page heading, an SMS reply and a quote follow-up email are three different jobs, and asking for "some copy" gets you the average of all three.

• Symptom: output is the wrong length for where you need to put it, and needs restructuring every time.
• Cause: no stated destination or purpose.
• Fix: say where it goes and what it has to achieve. "This is the first text message after a missed call. It has to get a reply." is a complete brief.

6. Everything is stuffed into one instruction

When a single request has to handle every case, the instruction fills up with conditionals, and the system spends its attention reconciling them instead of doing the work. This is the most common shape of a prompt that grew over six months.

The tell is a set of rules that contradict each other in edge cases nobody has noticed, because each was added in response to one bad output.

• Symptom: quality is inconsistent and gets worse as the instructions get longer.
• Cause: one instruction doing five jobs, grown by accretion.
• Fix: split it. Separate instructions for separate jobs, each short. Where the cases genuinely differ, route to the right one in code rather than describing all of them at once.

7. The reference material is there but unusable

Plenty of systems are given documents and still produce generic output, because the documents are the wrong ones, are out of date, or are so long that the relevant part is a needle in a stack of policy PDFs.

Retrieval quality is invisible from the outside. The output looks like a model problem and is actually a search problem.

• Symptom: answers are vague on exactly the topics your documents cover well.
• Cause: the right passage is not being found, or is being found alongside twenty irrelevant ones.
• Fix: look at what is actually being retrieved for a bad answer before you touch anything else. Nine times in ten the fix is in the source material or the search, not the instruction.

8. It is being asked to do research it cannot do

If the answer depends on information the system does not have and cannot reach, it will produce something plausible rather than admit the gap. Plausible and generic are close relatives.

This is where invented specifics come from: hours you do not keep, coverage areas you do not serve, guarantees you do not offer.

9. The tone was described with adjectives

Professional, friendly, approachable, authoritative. These words mean almost nothing operationally, and every business believes they describe it.

Tone is carried by concrete choices: sentence length, whether contractions are used, whether the reader is addressed directly, what is left out. Those are describable. Adjectives are not.

• Symptom: tone is bland and identical across everything, no matter which adjectives you change.
• Cause: tone specified as a list of qualities rather than as behaviour.
• Fix: describe the mechanics. "Short sentences. Second person. No exclamation marks. Never open with a greeting. If a sentence could appear in any competitor's brochure, cut it."

10. Nobody said what a good answer looks like

Most systems are given a task and no standard. Without a definition of done, the model optimises for something that looks complete, which usually means covering everything at low resolution.

A standard is not a rubric with points. It is a sentence about what the reader should be able to do afterwards.

• Symptom: answers are complete and useless. Everything is covered, nothing is decided.
• Cause: no stated success condition.
• Fix: state it. "A good answer lets the customer decide whether to book without replying to ask another question." That single line reorganises everything downstream of it.

11. It is set up to hedge

A system asked to be careful, accurate and non-committal will produce writing that commits to nothing. Some of that is safety instructions doing their job in the wrong place, and some of it is a compliance requirement that got applied to everything rather than to the things that need it.

The result reads as generic because refusing to commit is what generic sounds like.

• Symptom: every sentence carries a qualifier. Nothing is stated plainly.
• Cause: caution instructions applied globally rather than to the specific topics that need them.
• Fix: scope the caution. Be specific about which topics require hedging and which do not, and let the rest be direct. In a regulated business this is a real design task, not an oversight.

12. The bar is a person having a good day

Worth saying plainly at the end, because it changes how you read the other eleven. People compare a system's output to the best thing a person on their team has ever written, not to the median.

The median is a rushed reply typed between two other jobs at 4:50pm. That is the honest comparison, and it changes which problems are worth fixing.

The order worth working through

If you are looking at generic output right now, work down this list rather than rewriting the instructions and hoping.

1. Look at one bad output and ask what facts would have been needed to write a good one. That names the missing input.
2. Check what the system actually received. Not what you think it received, what it received. This step alone resolves most cases.
3. Add the missing facts as source material rather than as instructions.
4. Replace prohibitions with one positive description of the target.
5. Add three or four varied examples, labelled as illustrations rather than templates.
6. Name the reader and the destination for the output.
7. Write the one-line standard for what a good answer does.
8. Only then touch the tone, and describe it as mechanics rather than adjectives.

Where this connects to the rest

The facts a system needs are the same facts a new employee needs on their first day, which is why we collect them the same way. That sheet is published in full in the context sheet.

The related problem, which is output that is technically correct and still does not sound like you, is a different fix and it is covered in the voice pass.

And if the system in question is a customer-facing chatbot, the failure mode has a specific shape worth knowing about before you launch: chatbots that get fired.