A weak AI answer usually points at one missing piece in your request. Read the symptom, make one change, and rerun.
Don’t rewrite the whole prompt when an answer disappoints. Read the answer and find the missing piece: context, a clear task, a format, an example, the right level of ambition or a test for done. Make one change, rerun on the same input, and use the pre-send checklist before anything you’d hate to redo. When the same symptom survives two fixes, the prompt may not be the problem.
A weak AI answer usually tells you what was missing from the request, and many people skip past that and rewrite the whole prompt from scratch. The generic answer, the one that wanders off the question and the one in the wrong shape each point at a different gap. Each gap has a different, smaller fix.
At the end of the month a finance analyst pastes in the variance table and asks for a summary. What comes back is three tidy paragraphs that could describe any company’s quarter. She types “make it better” and gets a second version that is tidy in a different way. Nothing in either answer was wrong, exactly.
Neither one knew who would read it or what they needed to decide.
The useful question at that point is what this answer is missing, and which part of the request should have supplied it. Asked that way, answers sort into six causes: missing context, an unclear task, no format, no example, the wrong level of ambition, and no test for what done looks like. The table below matches what you see in the output to the cause and the smallest fix.
| What you see in the answer | What the request was missing | The smallest fix |
|---|---|---|
| Generic. Could have been written for any company or any project | Context and source material | Say who it’s for and what’s going on, and paste the facts it should use |
| Off target. Answers a different question, or covers everything at once | A clear task | One verb, one deliverable, one reader, and the decision it feeds |
| Wrong shape. An essay when you needed a table, or far too long | A format | Name the structure, the length and what comes first |
| Sounds like nobody. Stiff, or not how your team writes | An example | Paste one good example, with names and figures removed |
| Too thin or too much. Three bullets, or twelve options and a framework | The right level of ambition | Say how much work you want: how many options, how deep, what to leave out |
| Polished but unverified. You can’t tell whether it’s right | A test for done | Write two or three checks first, then ask it to test its own draft against them |
Future Factors working view, built from the failure patterns above. The vendor guidance behind each row is cited in the sections that follow.
This guide starts once you have a first answer in hand. For wording the opening request, see the 4-part prompt formula and reusable prompt patterns, and for why it matters, why prompting matters. For the back-and-forth afterward, see prompting like a conversation. This piece covers the moment between the two, when the answer is in front of you and something is off.
Read the answer before you rewrite the prompt.
Find the row that matches what you’re looking at, make that one change, and rerun the same input. If you change four things at once and the answer improves, you won’t know which one mattered.
A generic answer is a common complaint, and the cause is often missing context. Without a reader and a situation, a model writes for the average case, because the average case is all it has been told about. Anthropic’s prompting guide asks you to think of the model as a “brilliant but new employee who lacks context on your norms and workflows.”[1] Microsoft’s guide for Copilot makes the same point in its structure: it lists goal, context, source and expectations as the four parts of a prompt, and says a clear goal is the only required one.[3]
That last detail explains the symptom. A prompt with only a goal runs fine and returns something reasonable, so nothing signals that the other three parts were skipped. The result is a competent answer to a question nobody in your company would have asked in those words.
Two things get mixed up here. Context is the situation: who will read this, what changed, what they need to decide. Source is the material: the table, the policy, the thread. People often describe the material instead of pasting it (“the project is late because of legal”) and get a draft that is vague about what legal found. If a fact matters, put the fact in. If the document is sensitive, check your organization’s rules on which tools it may go into before you paste it.
The fix looks different by seat. An HR generalist writing about a policy change needs to supply the actual policy text and say which employees the message goes to. An operations manager writing a status note needs to supply what changed since last time. A finance analyst needs the table and a sentence about what the reader will do with the number. Here is the same fix on an ordinary work prompt.
| Version | Prompt | What it tends to produce |
|---|---|---|
| Before | Write an update email about the website project. | Three paragraphs of upbeat project language that fit any project, with no new date and no ask |
| After | Write a status update to our project sponsor, who reads these on her phone between meetings and only needs to know whether she has to decide anything. The website launch has moved from [old date] to [new date] because [reason]. Nothing else has changed. Tone: calm and direct, no apology paragraph. Under 120 words, with the new date in the first sentence. Use only the facts in this message. If you need something I haven’t given you, ask me instead of guessing. | A short note that leads with the date, says nothing has changed beyond it, and doesn’t invent a reason |
What changed: the reader, the situation, the facts and the length. Much of the lift comes from the first two. The right-hand column describes the pattern to expect, not a measured result.
Before a vendor meeting, an operations manager pastes in a proposal and types “review this and tell me what you think.” The answer comes back balanced and long, with a paragraph each on pricing, risk, structure and tone. It’s a reasonable answer to a request that never said what the review was for.
“Review,” “look at,” “help me with” and “what do you think of” aren’t tasks. They’re invitations, and the model has to pick a task for you. When it picks a different one than you had in mind, you get the symptom in the second row of the table: an answer to a different question, or to all of them at once.
A clear task has four parts: one verb, one deliverable, one reader, and the decision the output feeds. Anthropic’s guide offers a quick way to check this. Show your prompt to a colleague who has minimal context on the task and ask them to follow it; if they’d be confused, the model will be too.[1]
| Version | Prompt | What it tends to produce |
|---|---|---|
| Before | Review this vendor proposal and tell me what you think. | A balanced overview of pricing, risk and presentation, with no answer to the question you had |
| After | I need to decide today whether to shortlist this vendor. Compare the attached proposal with these three requirements: [requirement 1], [requirement 2], [requirement 3]. For each one, say met, partly met or not met, and quote the line of the proposal that shows it. Then give a one-sentence recommendation: shortlist, don’t shortlist, or ask a question first, and name the question. Leave out formatting and tone. | A three-line comparison with quotes you can check, and a recommendation you can accept or argue with |
What changed: a decision, a deliverable and a way to check. Asking for the quoted line is what lets you verify a row in seconds.
A bundled prompt (summarize this, recommend, then draft the reply) causes the same symptom, because each job gets a quick pass. Splitting it usually fixes that, and our piece on prompt patterns covers when.
Two symptoms live close together here. In one, the content is right and the shape is wrong: an essay when you wanted a table, or a page when you wanted five lines. In the other, the shape is fine and the voice is stiff, the kind of reply that opens with a paragraph of regret and closes with an offer to help further.
The first is a missing format. The model can’t see where the output is going, whether that’s a slide, a chat message or a form field. Say so. Anthropic’s guide advises being specific about the output format and constraints, and putting it in positive terms: say what you want the response to look like rather than listing what to avoid.[1] “Five bullet points, each under 15 words, lead with the number” gives the model something to build. “Don’t be wordy” gives it a thing to avoid and no target.
The second is a missing example. Describing a voice in adjectives (“warm but professional”) is about as reliable as describing a face in adjectives. Pasting one reply you were happy with shows the structure, the length and the register at once. Both Anthropic and OpenAI recommend examples, and both ask that they be varied: OpenAI says to show a diverse range of inputs with the desired outputs, and Anthropic says examples should cover enough ground that the model doesn’t pick up unintended patterns.[1][2] A single example tends to get imitated closely, down to its opening line. If every draft starts the same way, add a second example that differs.
| Version | Prompt | What it tends to produce |
|---|---|---|
| Before | Reply to this customer complaint. | A long, apologetic template reply that could be sent to anyone about anything |
| After | Draft a reply to the customer email below, written as a customer success lead at [company]. In the first sentence, name the specific problem they described. Then say what happens next and by when: [next step and date]. Offer one contact: [name]. Keep it under 100 words, in plain, specific language. Match the tone and length of this earlier reply (names removed): [paste a past reply you liked]. Customer email: [paste, with personal details removed]. | A short reply that names the problem, commits to a next step and sounds like your team |
What changed: a format, a length, an example and the facts. Swap in your own past reply; the example is doing most of the work on tone.
Some answers are too thin. You asked for analysis and got three bullets. Others bury you: you wanted one recommendation and got twelve options and a framework. Both come from the same gap, which is that the request never said how much work you wanted done.
Anthropic’s guide is direct about this. If you want “above and beyond” behavior, it says, request it explicitly rather than relying on the model to infer it from a vague prompt.[1] It also depends on the tool. OpenAI’s guide notes that its GPT models benefit from precise, explicit instructions, while its reasoning models can work from higher-level goals.[2] So the right amount of detail isn’t fixed, and it’s worth reading your own tool’s guide before you assume.
Ask for the amount of work you actually want, in the request, not in the follow-up.
Put a number or a boundary on it. Here are phrases you can drop into a prompt, grouped by which direction you need to move.
Fill the brackets with your own numbers, and start with a small change.
A polished answer is hard to judge, and the polish is the problem. A summary reads as confident whether it caught the exception in the clause or missed it, so the feeling of “this looks right” tells you very little. That sixth row in the table, polished but unverified, is the one I’d worry about most, because the earlier symptoms announce themselves and this one doesn’t.
The fix happens before you send the request. Write two or three checks that define done: every figure traces to the table, the date appears in the first sentence, no claim is included that I didn’t supply. Then put them in the prompt and ask the model to test its own draft against them and list anything that fails.
Write down what done looks like before you send, not after you read.
It’s a filter, though, not a verdict. The model is checking its own work against your list, and it can pass a draft that a careful reader would not. Microsoft’s guide says plainly to review and verify what Copilot returns and to cross-reference with trusted sources when needed.[3] The split below keeps the responsibilities clear.
| What AI does | What the human still owns | How it gets checked |
|---|---|---|
| Drafts the answer from the context, task and format you gave it | Deciding what done means: the checks, the audience and the stakes | You write the checks before sending and read the draft against them |
| Tests its own draft against your checks and lists what fails | Judging whether a passed check really passes, especially for names, figures and quotes | Spot-check the figures and quotes against the source yourself, not the model’s summary of it |
| Flags what it had to guess because the request left it out | Supplying the missing fact or choosing which guess is acceptable | The “ask me instead of guessing” line in the prompt makes guesses visible |
Future Factors working view. For deeper checking methods, see our guides on testing prompts and on why AI invents details.
Here is the block to paste at the end of a prompt, with your own checks filled in.
| Before you give me the final answer, check your draft against these and list any that fail: 1. Every figure comes from the text I gave you. 2. The new date is in the first sentence. 3. Nothing is included that I didn’t supply. If you had to guess any fact, list it separately instead of putting it in the draft. |
Replace the three checks with your own. Then read the draft against them yourself; a pass from the model is a filter, not a verdict.
For deeper methods, see our guides to testing prompts before you trust the output and why AI hallucinates.
Sometimes the symptom points at something no rewrite will fix. Before a third attempt at the same prompt, check these four situations.
| Situation | What to do instead |
|---|---|
| The facts live somewhere the tool can’t see: your internal numbers, last week’s decision | Paste the source in, or accept a general answer |
| The thread has drifted. Early instructions fade in a long conversation | Start a fresh thread with a short summary; see prompting like a conversation |
| The decision hasn’t been made. A draft of a message you haven’t thought through is a polished muddle | Decide your position first, even roughly |
| The task needs judgment the tool can’t supply, such as what to tell an upset client | Use AI to prepare, and keep the decision |
Future Factors working view.
A decision rule that works: if you’ve fixed the same symptom twice and it keeps coming back, stop rewriting. Change what you’re asking AI to do, or who does it.
When you can’t tell which cause fits, AI can help you work that out, as long as you treat what it says as a hypothesis. Its explanation of why an answer went wrong is a plausible guess, and the real test is whether the change improves the next run.
| Below is a prompt I sent, the answer I got, and what is wrong with it: [describe the symptom in a sentence]. Which of these gaps best explains the problem: missing context, an unclear task, no format, no example, the wrong level of ambition, or no test for what done looks like? Name one. Then list every place the answer had to guess because my prompt left something out. Then rewrite only that part of my prompt and show me the change. Use only what I’ve pasted. Do not rewrite the rest. Prompt: [paste] Answer: [paste] |
Run the rewrite on the same input as before. If the answer improves, keep the change. If not, the diagnosis was wrong, so try the next-closest row of the table.
Many of the fixes above take a minute once you know which one you need. The harder part is remembering them while you’re busy, so run the list below before you send anything you’d be annoyed to redo.
| Question | If the answer is no |
|---|---|
| 1. Does the prompt say who the output is for and what’s going on? | Add the reader and the situation |
| 2. Is there one verb, one deliverable and a decision it feeds? | Cut it to one job, or split it |
| 3. Have I named the format, the length and what comes first? | Add all three |
| 4. If the voice matters, is there an example I’m happy with? | Paste one, with details removed |
| 5. Have I said how much work I want? | Add a number or a boundary |
| 6. Have I written two or three checks for done, and told it to ask me when it would otherwise guess? | Write them, then paste them in |
A pre-send checklist, not a formula. Skip the questions that don’t apply to the task.
For a team, the shared vocabulary is a useful by-product. When a colleague says “that’s a context problem,” everyone knows what to change. Teams can start building that habit on their own with a shared document of rewrites. Expert-led workshops shorten the learning curve and bring the less enthusiastic people along, which is the gap our corporate workshops are built for, and our guide to training your team on AI covers where to start.
To tell whether the habit is working, look past how many people tried it. Use is whether people reach for the checklist. Persistence is whether they still do a month later without a reminder. Impact is whether the first answers need less editing, which you can see in the work itself.
A one-line log keeps the habit honest. Here is a filled-in row to copy.
| Prompt | Symptom | Row in the table | The one change | Better? |
|---|---|---|---|---|
| Weekly update email | Generic | Context | Added the reader and the new date | Yes, edited far less |
| Vendor proposal review | Off target | Task | Named the decision and three requirements | Yes, with quotes to check |
Future Factors working view. Two rows after a few weeks will show you which fix you reach for most.
Here’s what I’d do this week:
Fix the one closest to the symptom first, and rerun on the same input. Context and task problems are usually the cheapest to fix, so check those before format or examples, then stack the next fix on top, one at a time.
The principles appear in all three vendors’ own guidance, which we read on October 19, 2026: be explicit, give context, use examples, check the output. How much explicit detail a given model needs varies, and OpenAI’s guide says so for its own models. Treat the table as a starting point and test it on the tool you actually use.
Yes, with the diagnostic prompt in this guide and one limit: the model can spot gaps in the text, but it can’t reliably explain its own earlier output. Treat its suggestion as a hypothesis and test it on the same input.
That’s usually a source problem, not a wording problem. If the fact lives in your documents, paste the relevant passage and ask for answers drawn only from it. If it’s a public fact, verify it yourself. Our guide on techniques for fixing AI errors goes deeper.
That depends on your organization’s rules and on which tool you’re using. Use approved tools for confidential material, remove personal details where you can, and check with IT or security if the policy isn’t clear.
The vendor guidance in this guide was read on October 19, 2026: Anthropic’s prompting best practices page, OpenAI’s prompt engineering guide, and Microsoft’s support article on writing prompts for Microsoft 365 Copilot, which was last updated in September 2026. Vendor guides describe their own products, change often and sometimes vary by model, so check the current version for your tool. The symptom-to-fix table, the three rewrites, the ambition dial, the pre-send checklist and the diagnostic prompt are Future Factors working views based on our own judgment, not research-validated methods, and the “what it tends to produce” columns describe patterns to expect, not measured results. The scenes in this guide are illustrations, not client stories. We left out statistics and test results we could not confirm against a primary source.
Weekly tips. Real examples. Practical help for busy professionals.
We care about your data, check out our privacy policy.