Five layers you can change
Change the lowest layer that explains the feedback
- Whether to use ClaudeSome tasks should go back to a person entirely
- The workflowWho reviews, at which point, against what
- The product setupProject, knowledge, instructions, model
- The context suppliedDocuments, examples, audience, constraints
- The prompt wordingThe layer everyone reaches for first
Three kinds of feedback, and what each is good for
The first kind is your own reading of the output. It arrives instantly and it is the least reliable, because you know what you meant and will read it in charitably. The second is other people: the reviewer whose edits you can count, the colleague who says a draft “doesn’t sound like us”, the manager who sends it back. The third, and the one almost nobody collects, is the result in the world — did the email get replies, did the bid win, did the ticket close first time, did the reader do what the document existed to make them do.
These three often disagree, and when they do the later ones win. An output you were pleased with and a reviewer rewrote is not a good output. A document everyone admired that changed nobody’s behaviour has not done its job. The documentation makes the same point in its own register: before optimising anything, define what success looks like for your use case and have a way to test against it. Most people iterate against a feeling; the discipline is to iterate against a measure, even a rough one such as “how many lines did the reviewer change”.
| Signal | What it can tell you | What it cannot |
|---|---|---|
| Your own reaction | Obvious errors, wrong shape, wrong length | Whether it works for the actual reader |
| Reviewer edits | Where the house voice and standards really are | Whether the reader acted on it |
| Downstream result | Whether the output did its job | Which specific change caused the difference |
| Thumbs-down in the product | Sends the response to Anthropic as unhelpful | Anything back to you about this task |
| Repeat use over weeks | Which fixes were durable and worth saving | Much, if nobody wrote down what changed |
Turning vague feedback into a change you can make
Most feedback arrives unusable. “It’s not quite right”, “too corporate”, “this isn’t how we write”. None of that can be acted on, and the temptation is to guess. The move is to convert the reaction into two things: an example of the failure and an example of what was wanted. A reviewer who cannot articulate the house voice can always point at a document that has it, and that document is worth more than any adjective, because documented practice is to give three to five real, diverse examples rather than describing the target in the abstract.
Feedback made actionable
Unusable feedbacktext
"This doesn't really
sound like us. Can you
have another go and
make it warmer?"Converted to a changetext
Failing line:
"We regret to inform
you that your request
has been declined."
Wanted instead:
"We can't do this one,
and here's why."
Rule: contractions,
second person, say the
answer in sentence one.
Attach: three past
letters the team liked.Making an adjustment stick
An improvement that lives in one person’s scroll history is not an improvement, it is a rediscovery waiting to happen. Once a change proves itself, it has to move somewhere durable, and there is a natural ladder. A phrasing that reliably works goes into a saved prompt or template. Knowledge and conventions specific to a team’s work go into that team’s project instructions and knowledge — configuring those is 5.1, and keeping them current is 5.4. A rule that should hold across the whole organisation can go into organization instructions, which Owners on Team and Enterprise plans set within a 3,000-character limit, as covered in 6.3.
The ladder matters because each rung costs something. Organization instructions apply to every chat in the business, so a rule that suits one department will annoy five others and their character budget is finite. Project instructions are the right home for most team-level learning. Saved prompts are right for an individual’s recurring task. Putting a fix on the wrong rung is itself a common failure — and a change that helps one team and hinders the rest usually shows up as new complaints rather than as anybody reversing it.
Where should this improvement live?
- Just my recurring taskSaved promptA template you reuse and refine
- My team’s workProject setupInstructions and knowledge in the project — see 5.1
- Everyone, alwaysOrganization instructionsOwners only; 3,000 characters for the whole business
- It keeps failingChange the workflowOr give the task back to a person
When the answer is not another adjustment
Some loops should be closed rather than tightened. If the same failure survives three genuine rounds of adjustment, the feedback is telling you something about the task, not about your technique. The documentation acknowledges this in its own way, noting that not every failing result is best solved by prompt engineering — some are better addressed by a different choice of model, which for cost, speed and quality is 3.3. And some tasks simply belong to a person: work where the judgement is the point, where the facts are not available to Claude at all, or where the checking costs more than the drafting saved.
There is one more feedback channel worth knowing because the exam may mention it. Inside the product, the thumbs-down control sends a response to Anthropic as unhelpful, and the help documentation points users to it along with emailing support with suggestions. It is a signal to the people who build the model. It is not a support ticket about your document, and nothing comes back to you — so it complements, rather than replaces, adjusting your own approach.
Traps the wrong answers are built from
| Tempting but wrong | Do this instead |
|---|---|
| Answering every complaint with a prompt rewrite | Identify which layer the feedback is about — context, setup, workflow or fit. |
| Acting on “make it warmer” as if it were an instruction | Convert it into a failing example, a wanted example and a stated rule. |
| Judging improvement by whether colleagues liked the draft | Pick an outcome measure, however rough, and track the same one over time. |
| Leaving a proven fix in one person’s chat history | Promote it to a saved prompt, project instructions, or organisation-wide guidance. |
| Putting a team convention into organisation-wide instructions | Match the scope of the fix to the scope of the problem. |
| Adjusting indefinitely on a task that keeps failing | After three honest rounds, change the model, the workflow, or who does the task. |
You should now be able to
- Distinguish feedback about the output, from reviewers, and from the result in the world.
- Locate which layer a piece of feedback is really about before changing anything.
- Turn a vague reaction into a failing example, a target example and a rule.
- Choose the right home for a proven improvement, from saved prompt to organisation instructions.
- Recognise when to stop adjusting and change the task, the model or the owner.