What You Need to Know
A poor output is a response that falls short of what the request needed. Diagnosing it means naming why a reasonable-looking request produced it, before changing anything. A Project's configuration is its instructions and knowledge.
An independent bookshop's owner keeps a Project for the weekly new-titles newsletter and asks for one-off shelf cards in ordinary chats.
The Routing Question
The most useful diagnostic is one question: did that happen once, or does it happen every time? A bland summary from one under-briefed request is a prompt problem, fixed by a better brief. The same wrong tone, format or assumption in every output from the same Project is a configuration problem. The tell is the word every. The Project's instructions or knowledge are producing the defect, so the correction belongs in the configuration once. Hand-correcting each output instead pays the same cost forever.
One bland shelf card needs a better brief. A stiff tone in every newsletter needs one fix in the Project's instructions.
A Cause List You Can Run in a Minute
Six causes cover nearly everything:
- context starvation
- instruction overload
- a configuration defect
- a degraded conversation
- stale or superseded material
- a feature or setting mismatch
Starvation is by far the most common. A request with no audience, no purpose and no source material can only produce generic output, because Claude cannot guess what was withheld. The Help Center advises giving as much context as possible, as if instructing someone with no background knowledge of the task. Supply what was missing. Asking more forcefully supplies nothing. The shelf card needed its audience, its purpose and the book's blurb.
Overload comes next. A request carrying a dozen requirements loses some of them. The documented remedy is structural: break complex requests into substeps, and group and prioritise so the important requirements cannot sink. Re-sending the same list with the missed items in capitals supplies nothing new. A newsletter brief that keeps dropping the opening hours gets split and prioritised.
When the Conversation Itself Is the Problem
A long chat accumulates superseded drafts, corrections that were later contradicted, and unrelated topics. Claude has to work with all of it. The chat eventually hits its length limit. Longer conversations that trigger automatic context management also consume more of your usage limit. The documented advice: chunk the content, summarise the important sections, or start a new conversation. Projects handle large recurring material through retrieval. The fix for a degraded chat is a fresh conversation carrying a verified summary of what still matters. A chat holding three newsletter drafts restarts from a summary.
The Failure Modes Anthropic Names
The Help Center's troubleshooting articles name this objective's symptoms. Incorrect or misleading responses include fabricated quotes that look right. Claude is not a singular source of truth, so scrutinise high-stakes claims and review cited sources, such as a newsletter's author quote. Hallucinated capability means working-looking links that fail, or a claim to have sent an email. Claude has no access to email or any software not explicitly integrated. The diagnosis is fabricated capability, not a delivery to chase.
A response that comes back too brief is a prompting problem: retool the prompt. Give Claude the previous prompt and response so it picks up where it left off. Error messages aren't quality defects. A capacity notice means wait and retry. A length-limit message means chunk, summarise or start fresh. Half the diagnosis is recognising which of these the symptom is, because each has a different fix.
The Escalation Reflex
The domain's favourite trap is reaching for the most capable model or a higher effort setting because the output disappointed. A vague brief fails at every tier, because the missing context is missing for every model. Escalation buys the same generic answer, more thoroughly, at more cost, and the shelf card stays bland. Feature and setting changes are legitimate when the task needs depth (the effort and extended thinking settings) or current outside information (web search or Research). Reach for them only after the brief is sound.
In the exam
Every item in this domain starts after something has gone wrong. Writing a good request is Domain 1's job; diagnosing a poor result is this domain's. Changing a configuration is Domain 5's work; recognising that it needs changing is yours. Candidates lose these marks by reaching for a fix before naming a cause.
Key Concept
Classify the symptom before reading the options: once or every time, and which named failure mode. The keyed answer fixes the cause. At least one distractor treats the symptom, usually by rewriting a prompt that was never the problem.
What the Sources Do Not Say
No official source says long chats get slower or that Claude confuses topics. The case for starting fresh rests on what is documented.
Exam Traps
Rewriting today’s prompt when the stem says every output has the same defect
A defect appearing in every output of the same kind comes from the setup, so the fix belongs in the Project’s instructions or knowledge once. Rewriting individual prompts, or hand-correcting each output, pays the same cost forever and leaves the cause in place.
Escalating to a more capable model or higher effort as the first response to a disappointing output
If the request never named its audience or attached its material, escalation returns the same generic answer more slowly and at more cost. Diagnose first: a starved brief is fixed by supplying context, and no tier of model can guess what was withheld.
Treating an error message as a quality defect and rewording the prompt
Capacity and length-limit messages have documented responses: retry after a short wait, or chunk, summarise and start a fresh conversation. Rewording the request answers a question the system never asked.
Chasing the delivery of an email Claude claims to have sent
Claude has no access to email or to any software that is not explicitly integrated, so a claimed send is a hallucinated capability, not a delivery failure. Checking outboxes or asking Claude to resend chases something that never happened.
Practice Scenario
The administrator of a small art gallery drafts loan-request letters to lenders inside a correspondence Project. For two months, every letter has come out in American spelling, and she has corrected each one by hand before posting. A more capable model gave the same spelling. She wants to stop the hand corrections and keep drafting inside the Project. What is the most appropriate next step?
Build Exercise
Diagnose Your Last Disappointment
What you'll learn
- How to route a symptom with the once-or-every-time question
- How to run a short cause list before touching the prompt
- How to recognise the failure modes Anthropic documents
- How to apply one fix and check that the symptom moved
- Find the last piece of Claude work that disappointed you, and resist rewriting anything until you have diagnosed it
Why: The domain’s core discipline is naming a cause before applying a fix; jumping straight to a rewrite is the reflex this exercise retrains.
You should see: The disappointing output and the request that produced it, side by side, untouched.
- Ask the routing question first: did that happen once, or does it happen every time you do this kind of work?
Why: One-off defects point at the request or the conversation; recurring defects point at the setup, and the two diagnoses lead to entirely different fixes.
You should see: A one-word routing decision written down: once, or every time.
- If it happened once, run the cause list: missing context, too many requirements at once, a conversation that had gone on too long, superseded material, or a task that needed a feature or setting no wording can supply
Why: A short list you can actually run beats an open-ended hunt; most one-off failures are context starvation, and the list stops you missing the rarer causes.
You should see: One named cause, with a sentence of evidence for why you chose it.
- If it happens every time, open the Project’s instructions and knowledge and look for the line, or the missing line, that produces the defect
Why: Recurring defects are manufactured by configuration; the evidence is in the instructions and knowledge, not in any single conversation.
You should see: The offending line identified, or a note that the standard producing the defect was never stated.
- Apply the one fix your diagnosis points at, re-run the same request, and note whether the symptom moved before touching anything else
Why: Changing one thing and re-testing is what turns a guess into a diagnosis; if the symptom moved, you found the cause, and if not, the cause list is still open.
You should see: A before-and-after pair of outputs and a one-line verdict on whether the fix worked.
Sources
- My prompt isn't giving me a helpful answer — Anthropic
- Claude is providing incorrect or misleading responses. What's going on? — Anthropic
- Claude is producing links that don't work and falsely claiming that it has sent emails or produced external documents — Anthropic
- Claude's response to my prompt is too brief — Anthropic
- Troubleshoot Claude error messages — Anthropic
- How do usage and length limits work? — Anthropic
- Change the model, effort, and thinking settings — Anthropic
- When should I use web search, extended thinking, and research? — Anthropic